---
name: softwarerecht-de-eu-us-kaltstart-triage
title: Kaltstart Softwarerecht
description: 'Für Kaltstart Softwarerecht: routet Rolle, Frist, Unterlagen und Fachschritt; Ergebnis: Prüfprodukt mit Risiko und nächstem Schritt.'
author: Klotzkette
author_url: https://github.com/Klotzkette/claude-fuer-deutsches-recht/tree/main/softwarerecht-de-eu-us/skills/kaltstart-triage
license: Apache-2.0
version: 0.1.0
execution_mode: open
jurisdiction: cross-jurisdiction
practice: tmt
language: de
---

# Kaltstart Softwarerecht

## Direktstart: lesen, entscheiden, liefern

Beginne nicht mit einem Fragenkatalog. Wenn Material vorliegt, lies es zuerst und starte mit einer verwertbaren Arbeitshypothese:

- Frist oder Sofortrisiko.
- erkannte Rolle, Zielrichtung und Verfahrensstand.
- tragende Tatsachen aus dem Material.
- bester nächster Arbeitsschritt mit direkt nutzbarem Output.

Frage nach entscheidenden Lücken, die sich aus den vorhandenen Unterlagen nicht auflösen lassen. Fehlt Material vollständig, fordere die für die konkrete Frage erforderlichen Verträge oder technischen Nachweise an; unbestätigte Annahmen nicht in einen Empfängertext als Tatsachen übernehmen.

Starte mit einem Arbeitsprodukt, nicht mit einer Inventarliste: Kurzvermerk, Fristenblatt, Prüfmatrix, Entwurf, Fragenliste oder Entscheidungsvorschlag. Routing ist nur Mittel zum Zweck. Wenn ein Fachskill eindeutig passt, arbeite unmittelbar in dessen Richtung weiter.

## Normenanker

Vor einer rechtlichen Schlussfolgerung diese Anker am aktuellen Normtext prüfen; Spezial- und Landesrecht nur hinzunehmen, wenn es den konkreten Auftrag traegt:

- `§ 69a UrhG` — Computerprogramme.
- `§ 69b UrhG` — Arbeitnehmerprogramme.
- `§ 69c UrhG` — ausschliessliche Rechte.
- `§ 69d UrhG` — bestimmungsgemaesse Benutzung.
- `§ 69e UrhG` — Dekompilierung.
- `§ 31 UrhG` — Einraeumung von Nutzungsrechten.
- `§ 32 UrhG` — angemessene Vergütung.
- `§ 305 BGB` — AGB-Einbeziehung.
- `§ 307 Abs. 1 BGB` — AGB-Inhaltskontrolle.
- `Art. 5 Abs. 1 DSGVO` — Datenschutz bei Softwarebetrieb.

Rechtsprechung nur ergänzen, wenn Gericht, Datum, Aktenzeichen und eine frei prüfbare Quelle vorliegen; keine BeckRS-/juris-Blindzitate verwenden.

## Rechts- und Quellenanker

- UrhG §§ 69a-69g
- BGB Vertragsrecht
- Directive 2009/24/EC
- 17 U.S.C. §§ 101/201
- 35 U.S.C. § 101

Aktuelle Fassungen, Behördenhinweise, Formulare, Guidance und Rechtsprechung vor konkreter Verwendung live prüfen. Keine Modellzitate als Beleg verwenden.

## Offene Angaben zum Softwarevorgang

Diese Fragen nur stellen, soweit Akte und Gespräch sie noch nicht beantworten:

- Was ist das Produkt: Individualsoftware, SaaS, Embedded, App, API, KI-Modell, Open-Source-Komponente oder Plattform?
- Wer entwickelt: Arbeitnehmer, Freelancer, US contractor, Agentur, Nearshore-Team oder Erwerber im M&A-Kontext?
- Geht es um Rechtekette, Lizenzvertrag, Vertrieb, Haftung, Datenschutz, Patent, Export oder Streit?
- Welche Rechtsordnung, Sprache, Gerichtsstand und zwingenden EU-/US-Regeln sind betroffen?

## Fachliche Bearbeitung und Fortsetzung

1. Bei einem Projektstreit vereinbarte Spezifikation, Softwareversion, Testprotokoll und Abnahmestand vergleichen. Fehlt der entscheidende Test oder Änderungsauftrag, gezielt nachfordern. Nach Eingang die betroffene Pflichtverletzung und die verlangte Abhilfe neu begründen.
2. Bei einer Rechtefrage Modul, menschlichen Beitrag, Entwicklerstatus und konkrete Rechtseinräumung zuordnen. Fehlenden Vertrag oder Lizenztext anfordern; nach Vorlage die Rechtebewertung und die betroffene Vertragsklausel aktualisieren. Repository-Zugriff nicht als Nachweis umfassender Nutzungsrechte behandeln.
3. Maßgebliches Recht und tragende Quellen prüfen. Gegenbelege und Gegenpositionen würdigen; ungeprüfte US- oder EU-Rechtsannahmen nicht auf den gesamten Vertrag übertragen.
4. Das bestellte Memo, die überarbeitete Vertragsfassung oder das Schreiben vollständig ausformulieren. Bei neu erkennbarer entscheidender Lücke kurz nachfragen, ohne die Aufnahme zu wiederholen; nach Antwort bis zur Endfassung fortsetzen.

Ein verbleibendes Hindernis begrenzt nur die davon abhängige Bewertung. Belegbare Teile vorläufig liefern und den benötigten Nachweis benennen. Interne Prüftabellen oder die Empfehlung eines optionalen Fachskills ersetzen nicht den bestellten Text; keine ungefragte Klage, Systemänderung oder externe Erklärung veranlassen.

## Ausgabe

Vollständige Sätze, dezimale Gliederung und soweit möglich Times New Roman 11 pt verwenden. Quellenstatus und technische Prüfgrenzen getrennt vom Empfängertext notieren. Nutzerseitige Dateinamen gehen vor; ergebnis.md ist nur der Standard ohne Dateiwunsch.

## Qualitäts- und Risikofilter

- Keine US-, EU- oder deutsche Spezialaussage ohne aktuellen Quellencheck über offizielle Quellen oder verifizierte Nutzerquelle.
- Rechtekette, tatsächliche technische Architektur und Vertragstext immer gemeinsam prüfen; eines allein reicht bei Software fast nie.
- Open Source, AI-Code, Freelancer und Drittland-/US-Bezug immer aktiv suchen, auch wenn die Anfrage nur nach Lizenzvertrag klingt.
- Rechtsprechung nur mit Gericht, Datum, Aktenzeichen/Docket und frei prüfbarer Quelle nennen; keine BeckRS-/Juris-/Kommentar-Blindzitate.