Lizenzfragen bei KI-generiertem Code

1. Warum Lizenzfragen bei KI-generiertem Code jetzt relevant werden

Je mehr Entwicklungsarbeit über Claude Code oder vergleichbare Assistenten läuft, desto größer wird der Anteil an ausgeliefertem Code, der zumindest teilweise von einem Sprachmodell vorgeschlagen wurde. Damit werden zwei praktische Rechtsfragen unausweichlich, die sich nicht mehr auf später verschieben lassen: Wem gehört der Code, den ein Modell vorschlägt, und welche Lizenzbedingungen aus den Trainingsdaten könnten unbemerkt daran haften. Für eine Agentur, die Code an Kunden liefert, ist das keine akademische Debatte, sondern hat direkte vertragliche Konsequenzen bei Gewährleistung, Exklusivität und Haftung.

Eine einzelne, feste Antwort gibt es bislang nicht. Die Bewertung unterscheidet sich je nach Rechtsraum, je nach Nutzungsbedingungen des eingesetzten Werkzeugs und danach, wie stark ein Entwickler den Vorschlag anschließend bearbeitet hat. Dieser Artikel liefert deshalb keine abschließende Rechtsauskunft, sondern einen pragmatischen, technisch orientierten Rahmen für den Alltag. Für verbindliche Aussagen zu einem konkreten Vertrag bleibt der Gang zu einer spezialisierten Anwaltskanzlei unverzichtbar.

2. Die aktuelle Rechtslage: Urheberrecht und KI-generierter Code

Das deutsche Urheberrecht verlangt nach § 2 UrhG eine persönliche geistige Schöpfung eines Menschen, damit ein Werk überhaupt Schutz genießt. Ein Ergebnis, das ein Modell vollständig autonom erzeugt hat, ohne dass ein Mensch schöpferisch mitgewirkt hat, erfüllt dieses Kriterium nach herrschender Auffassung nicht ohne Weiteres. Ähnliche Überlegungen finden sich auch außerhalb Deutschlands: Das US-amerikanische Copyright Office und mehrere Gerichte, etwa im Verfahren Thaler gegen das Copyright Office, haben rein KI-generierten Werken die Eintragung verweigert, während die zuständigen Stellen in der EU ihre Leitlinien noch weiterentwickeln.

Die praktische Konsequenz ist zweischneidig: Fehlt einem Codeschnipsel jede schutzfähige Schöpfungshöhe, kann daran auch niemand, weder die Agentur noch der Kunde, ein Exklusivrecht beanspruchen. Das ist kein automatischer Vorteil, denn ohne Schutz fehlt auch die Handhabe gegen eine Übernahme durch Dritte. Sobald ein Entwickler den Vorschlag jedoch inhaltlich bearbeitet, umstrukturiert oder sinnvoll ergänzt, rückt die menschliche Schöpfungsleistung wieder in den Vordergrund und ein schutzfähiges Werk kann entstehen. Das ist ein weiterer, nicht nur qualitativer Grund, KI-Vorschläge als Entwurf statt als fertiges Liefergut zu behandeln.

3. Trainingsdaten-Provenienz: Woher stammt der vorgeschlagene Code

Die zweite Unsicherheit betrifft die Herkunft der Trainingsdaten. Sprachmodelle werden auf riesigen Codekorpora trainiert, die sowohl freizügig lizenzierte als auch restriktiv lizenzierte Repositories umfassen. Laufende Verfahren gegen Anbieter KI-gestützter Codeassistenten argumentieren, dass manche Ausgaben urheberrechtlich geschützten oder Copyleft-lizenzierten Quellcode nahezu unverändert reproduzieren können. Daraus ergibt sich die offene Frage, ob Pflichten der ursprünglichen Lizenz, etwa eine Namensnennung oder eine Copyleft-Bedingung, an einem Vorschlag haften könnten, obwohl der Entwickler die Originaldatei nie direkt kopiert hat.

Für die meisten alltäglichen Codeschnipsel ist dieses Risiko gering, weil kurze, idiomatische Muster kaum als eigenständig schutzfähig gelten. Bei längeren, strukturell auffälligen oder algorithmisch ungewöhnlichen Blöcken steigt die Wahrscheinlichkeit einer engen Ähnlichkeit dagegen messbar. Empirische Untersuchungen zeigen für bestimmte Modelle eine nachweisbare Memorierungsrate bei häufig öffentlich wiederholten Codefragmenten. Das folgende Skript zeigt beispielhaft, wie sich auffällig lange, vom Modell vorgeschlagene Blöcke automatisiert markieren lassen, damit ein Mensch sie vor dem Merge gezielt gegenprüft.

# flag_long_ai_blocks.py: flag unusually long AI-suggested code blocks for manual review
# This is a lightweight heuristic, not a legal determination of originality.
import re
import sys

MIN_LINES_FOR_REVIEW = 25
SUSPICIOUS_PATTERNS = [
    r"Copyright \(c\)",
    r"GNU General Public License",
    r"Licensed under the Apache License",
]

def flag_block(diff_text: str) -> list[str]:
    """Return warnings for long or license-header-bearing added blocks."""
    warnings = []
    added_lines = [l for l in diff_text.splitlines() if l.startswith("+") and not l.startswith("+++")]

    if len(added_lines) >= MIN_LINES_FOR_REVIEW:
        warnings.append(f"Block with {len(added_lines)} added lines exceeds review threshold")

    block_text = "\n".join(added_lines)
    for pattern in SUSPICIOUS_PATTERNS:
        if re.search(pattern, block_text):
            warnings.append(f"Suspicious license header pattern found: {pattern}")

    return warnings

if __name__ == "__main__":
    diff = sys.stdin.read()
    for warning in flag_block(diff):
        print(f"[REVIEW NEEDED] {warning}")

4. KI-generierten Code wie jeden Drittanbieter-Beitrag behandeln

Angesichts der ungeklärten Rechtslage ist der pragmatischste Ansatz, jeden KI-generierten Vorschlag genauso zu behandeln wie einen aus Stack Overflow kopierten Schnipsel, einen Beitrag eines freien Mitarbeiters oder einen gemergten Pull Request eines externen Contributors: derselben Review-, Attributions- und Lizenzprüfung unterworfen, statt eine neue Sonderkategorie mit abgesenkten Maßstäben zu erfinden, nur weil die Quelle diesmal ein Sprachmodell statt ein Mensch ist.

Konkret bedeutet das: kein Merge ohne menschliche Prüfung, standardmäßige Lizenzscanner für jede neue Abhängigkeit unabhängig davon, wer oder was sie vorgeschlagen hat, eine Dokumentation der Herkunft, wo das vernünftig möglich ist, und derselbe Maßstab, den frühere Artikel zum kritischen Prüfen KI-generierten Codes bereits beschrieben haben: Würde ich diesen Beitrag von einem unbekannten Mitwirkenden ungeprüft übernehmen? Dieser Ansatz senkt das rechtliche Risiko, ohne dass das Team eine Rechtsfrage lösen müsste, an der sich Gesetzgeber und Gerichte selbst noch abarbeiten.

5. Praktische Diligence: Was ein Lizenz-Review konkret umfasst

Ein praktikabler Lizenz-Review-Workflow für KI-unterstützte Commits kombiniert automatisierte Werkzeuge, etwa Composer-Lizenzprüfung und einen npm-License-Checker, mit einer kurzen manuellen Checkliste, die als fester Bestandteil der bestehenden CI-Pipeline läuft statt als nachträglicher Zusatzschritt, der von der Erinnerung eines Reviewers abhängt.

Die wichtigsten Schritte: jede neue oder geänderte Abhängigkeit auf Lizenzfamilie prüfen, also freizügig, Copyleft oder unbekannt, auffällig lange oder strukturell eigenständige KI-Vorschläge für eine genauere Prüfung markieren, bei substanziell KI-generierten Dateien einen kurzen Vermerk im Änderungsprotokoll hinterlegen, und Commit-Metadaten wie einen Trailer nach dem Muster Assisted-by: Claude Code speichern, damit die Herkunft später rekonstruierbar bleibt, falls eine Frage auftaucht. Einmal automatisiert, verlangsamt das den Liefertakt kaum merklich.

#!/usr/bin/env bash
# license-scan.sh: run as part of CI before merging any AI-assisted change
set -euo pipefail

echo "[1/3] Scanning Composer dependencies for license family..."
bin/composer licenses --format=json > var/log/composer-licenses.json

echo "[2/3] Scanning npm dependencies for license family..."
bin/npm --prefix app/design/frontend/Mironsoft/default ls --all --json \
  | bin/npx license-checker --json --excludePrivatePackages > var/log/npm-licenses.json

echo "[3/3] Flagging copyleft licenses (GPL, AGPL, LGPL family)..."
grep -iE '"licenses":\s*"(A?L?GPL)' var/log/composer-licenses.json var/log/npm-licenses.json \
  && { echo "[WARN] Copyleft license detected, review before merge"; exit 1; } \
  || echo "[OK] No copyleft licenses detected"

6. Open-Source-Lizenzen und Copyleft-Risiken bei generiertem Code

Ein verwandtes, aber eigenständiges Risiko: KI-Assistenten schlagen zur Lösung eines Problems gelegentlich die Installation eines Pakets vor, und dieses Paket kann eine Copyleft-Lizenz wie GPL oder AGPL tragen, die mit einem kommerziellen, closed-source Magento-Projekt nicht vereinbar ist. Das Modell kennt die Lizenzrichtlinie eines konkreten Projekts nicht, sofern sie ihm nicht explizit mitgeteilt wird, und schlägt bereitwillig die technisch am besten passende Bibliothek vor, unabhängig von den lizenzrechtlichen Folgen.

Das ist kein rein theoretisches Risiko: Insbesondere AGPL-lizenzierte Pakete können Copyleft-Pflichten bereits bei reiner Netzwerknutzung auslösen, was viele Teams nicht auf dem Schirm haben. Die Gegenmaßnahme ist bei KI-vorgeschlagenen Paketen dieselbe wie bei jeder anderen Abhängigkeit: Lizenz vor der Installation prüfen, eine explizite Allow- und Denyliste pflegen, und niemals wegen der Bequemlichkeit einer Claude-Code-Sitzung dieselbe Governance überspringen, die eine manuell recherchierte Abhängigkeit durchlaufen würde.

{
  "package": "some-image-processing-lib",
  "suggested_by": "AI assistant during checkout performance session",
  "detected_license": "AGPL-3.0-only",
  "compatibility": "incompatible",
  "reason": "Network-use copyleft clause conflicts with closed-source commercial deployment",
  "recommendation": {
    "action": "reject",
    "alternative": "equivalent-lib-mit-license",
    "alternative_license": "MIT"
  },
  "reviewed_by": "human, before merge",
  "reviewed_at": "2026-07-10"
}

7. Vertragliche Absicherung: Anbieter-AGB und interne Richtlinien

Neben der Rechtsunsicherheit rund um das Eigentum am Output lohnt sich ein Blick auf die vertragliche Ebene. Die Nutzungsbedingungen von Anthropic für Claude regeln bestimmte Nutzungsrechte und enthalten, je nach Vertragsmodell, für Enterprise-Kunden teils Freistellungsklauseln. Die konkreten Bedingungen unterscheiden sich jedoch je nach Anbieter und ändern sich mit der Zeit, sodass man sich nicht auf den Stand von vor einem Jahr verlassen sollte, ohne aktuell nachzusehen.

Intern hilft eine kurze, schriftlich festgehaltene KI-Nutzungsrichtlinie: welche Werkzeuge sind freigegeben, wird gegenüber Kunden offengelegt, dass KI-Unterstützung eingesetzt wurde, und brauchen bestehende Kundenverträge eine ergänzende Klausel zu KI-generierten Liefergegenständen, da viele Rahmenverträge älter sind als diese Praxis und dazu schlicht schweigen. Ein schlankes Skript, das den Review-Workflow technisch erzwingt statt ihn nur zu empfehlen, macht aus der Richtlinie etwas Durchgesetztes statt nur Gewünschtes.

// package.json excerpt: enforce license and provenance checks before every commit
{
  "scripts": {
    "license:check": "license-checker --failOn 'GPL;AGPL;LGPL' --production",
    "provenance:check": "node scripts/check-ai-trailer.js",
    "precommit": "npm run license:check && npm run provenance:check"
  },
  "husky": {
    "hooks": {
      "pre-commit": "npm run precommit"
    }
  }
}

// scripts/check-ai-trailer.js: warn if an AI-assisted commit is missing provenance metadata
const { execSync } = require("child_process");

const message = execSync("git log -1 --pretty=%B").toString();
const touchesLargeDiff = parseInt(execSync("git diff --cached --stat | tail -1").toString(), 10) > 40;

if (touchesLargeDiff && !message.includes("Assisted-by:")) {
  console.warn("[WARN] Large diff without an Assisted-by trailer. Add provenance metadata if AI-generated.");
}

8. Wie sich die Rechtslage entwickelt und wie man informiert bleibt

Gerichte in den USA, in Deutschland und auf EU-Ebene arbeiten diese Fragen aktiv ab, und die bisherigen Ergebnisse sind zwischen den Rechtsräumen und teils sogar innerhalb desselben Rechtsraums uneinheitlich. Anzunehmen, dass der heutige Kenntnisstand in zwei Jahren noch unverändert gilt, wäre optimistisch. Mehrere anhängige Verfahren zu Trainingsdaten sowie aktualisierte Leitlinien von Copyright-Behörden könnten verschieben, was als akzeptable Praxis gilt.

Die pragmatische Reaktion darauf ist weder, auf endgültige Klarheit zu warten, die möglicherweise noch lange nicht kommt, noch jede KI-unterstützte Arbeit vorsorglich einzufrieren, sondern eine Gewohnheit der regelmäßigen Überprüfung zu etablieren: jährlich die offizielle Guidance der zuständigen Copyright-Behörden sichten, relevante Gerichtsentscheidungen zur Codegenerierung verfolgen, und die interne KI-Nutzungsrichtlinie überarbeiten, sobald ein bedeutsames Urteil vorliegt, statt die heutige Checkliste als dauerhaft feststehende Antwort zu behandeln.

#!/usr/bin/env bash
# ai-provenance-audit.sh: quarterly audit of AI-assisted commits for the review cycle
set -euo pipefail

SINCE="${1:-3 months ago}"

echo "Auditing AI-assisted commits since: $SINCE"
echo "---"

git log --since="$SINCE" --grep="Assisted-by:" --pretty=format:"%h %ad %s" --date=short \
  | while read -r hash date subject; do
      echo "[$date] $hash $subject"
    done

echo "---"
total=$(git log --since="$SINCE" --grep="Assisted-by:" --oneline | wc -l)
echo "Total AI-assisted commits in period: $total"
echo "Reminder: cross-check against current copyright-office guidance before next release."

9. Praktische Checkliste im Vergleich

Die folgende Gegenüberstellung zeigt, wie sich ein Team ohne systematische Lizenz-Diligence von einem Team mit etablierter Praxis unterscheidet. Der Unterschied liegt selten in zusätzlichem Spezialwissen, sondern darin, ob die in diesem Artikel beschriebenen Prüfpunkte tatsächlich als fester Bestandteil des Workflows verankert sind.

Der Mehraufwand der rechten Spalte ist überschaubar und entspricht im Kern derselben Software-Supply-Chain-Hygiene, die viele Teams für gewöhnliche Abhängigkeiten längst etabliert haben, nur konsequent auf KI-vorgeschlagenen Code und KI-vorgeschlagene Pakete ausgeweitet. Wer diese Prüfpunkte bereits für menschlich geschriebenen Code durchläuft, muss den Workflow lediglich erweitern, nicht neu erfinden.

10. Zusammenfassung

Lizenzfragen bei KI-generiertem Code sind derzeit nicht abschließend geklärt und unterscheiden sich je nach Rechtsraum. Das deutsche Urheberrecht verlangt eine persönliche geistige Schöpfung eines Menschen, weshalb rein autonom erzeugter Code möglicherweise gar keinen Urheberrechtsschutz genießt, während Trainingsdaten-Provenienz laufende Verfahren gegen KI-Anbieter zu einem eigenständigen Risikofeld gemacht haben: Manche Ausgaben könnten geschützten oder Copyleft-lizenzierten Code nahezu unverändert reproduzieren, ohne dass ein Entwickler die Quelle direkt kopiert hat.

Der pragmatische Umgang mit dieser Unsicherheit ist, KI-generierten Code wie jeden anderen Drittanbieter-Beitrag zu behandeln: derselben Review-, Lizenzscan- und Dokumentationspflicht unterworfen, statt eine abgesenkte Sonderkategorie zu erfinden. Da sich die Rechtslage laufend weiterentwickelt, ersetzt keine heutige Checkliste eine regelmäßige Überprüfung anhand aktueller Urteile und offizieller Leitlinien, und keine dieser Empfehlungen ersetzt eine verbindliche anwaltliche Beratung für den konkreten Einzelfall.

11. FAQ: Lizenzfragen bei KI-generiertem Code