Die Nutzung von KI-gestützten Coding-Tools (Code Completion, Chat-basierte Assistenten, Agenten, und anderen Tools) ist in der Softwareentwicklung in kurzer Zeit von „Experiment“ zu einem produktivitätsrelevanten Standard geworden. In Open-Source-lastigen Tech-Stacks verschiebt sich damit ein Risikoprofil: Nicht die OSS-Komponente an sich ist neu, sondern die zusätzliche Quelle „KI-generierter Code“ als potentiell intransparenter Drittinhalt – mit urheberrechtlichen, lizenzrechtlichen, geheimnisschutzrechtlichen und sicherheitsbezogenen Implikationen.
Wie bei klassischer OSS-Nutzung gilt: Es existiert kein rechtsfreier Raum; Nutzungs- und Compliance-Anforderungen müssen organisatorisch und technisch beherrscht werden. Eine belastbare OSS-Governance ist dafür die Ausgangsbasis.
Dass dies erforderlich ist, zeigen aktuelle Praxisfälle – im in kurzer Zeit nahezu berühmt gewordenen „Chardet-Fall“:
1. Aus der Praxis: Copyleft-Umgehung durch AI-rewrites
März 2026: Der langjährige Maintainer einer LGPL-lizenzierten Python-Bibliothek ließ die gesamte Codebasis mittels Claude Code in ca. fünf Tagen neu generieren und veröffentlichte das Ergebnis unter der permissiven MIT-Lizenz Die strukturelle Ähnlichkeit zur Vorgängerversion lag laut JPlag-Analyse bei unter 1,3 %. Der Originalautor widerspricht: Es handle sich um keine „Clean Room"-Implementierung, da der Maintainer jahrelangen Zugang zum LGPL-Code hatte und das LLM nachweislich auf Metadaten der LGPL-Version zugegriffen hat.
Die Free Software Foundation stellt klar: There is nothing 'clean' about a Large Language Model which has ingested the code it is being asked to reimplement Die Software Freedom Conservancy hat am 27. März 2026 eine formelle Analyse angekündigt.
In der Wissenschaft wird das Phänomen bereits als „Copyleft Laundering" bezeichnet – die systematische Umgehung von Copyleft-Pflichten durch KI-gestützte Reimplementierung.
Diese Episode verdeutlicht eindrucksvoll: Unternehmen, die OSS-Komponenten einsetzen, müssen nun nicht nur die eigene KI-Output-Provenienz, sondern auch die Provenienz upstream prüfen: Wurde eine Dependency möglicherweise durch einen AI-Rewrite relizenziert, dessen Rechtmäßigkeit ungeklärt ist?
2. Gefahren beim Coding mit AI im OSS-Kontext
Um Risiken zu umgehen, müssen Unternehmen sich den Gefahren beim AI-assisted Coding bewusst sein:
2.1 Intransparente Code-Provenienz („Unknown Origin Risk“)
KI-Output hat regelmäßig keine nachvollziehbare Herkunftskette. Entwickler erhalten Snippets, Patterns oder ganze Funktionen, ohne belastbar beurteilen zu können, ob diese (a) originär generiert, (b) an Open-Source-Code angelehnt oder (c) faktisch eine (teilweise) Reproduktion konkreter Drittcode-Passagen sind. Das ist im OSS-Kontext kritisch, weil Lizenzpflichten an konkrete Werkteile und deren Weitergabe/Integration anknüpfen.
2.2 Lizenz- und Copyleft-„Kontamination“ durch AI-Snippets
Auch kurze Snippets können lizenzrelevant sein (je nach Schutzfähigkeit/Schöpfungshöhe und konkreter Übernahme). Bei Copyleft-Lizenzen (GPL-Familie, teils AGPL) verschärft sich das Risiko, wenn KI Output erzeugt, der funktional oder textlich eng an copyleft-lizenzierten Code angelehnt ist und anschließend in proprietäre Komponenten eingecheckt wird.
2.3 Halluzinationen und Schein-Compliance
KI-Tools produzieren nicht nur Code, sondern auch „rechtliche“ Begleitbehauptungen (z. B. „das ist MIT“, „das ist frei verwendbar“, „kein Copyleft“). Das verleitet zu Schein-Compliance: Entwickler verlassen sich auf ungesicherte Aussagen, statt auf verifizierbare Lizenzinformationen (Repository, LICENSE-Datei, Header, SPDX).
2.4 Geheimnis- und Vertraulichkeitsabfluss über Prompts/Context
Assisted Programming arbeitet typischerweise mit Quellcode, Tickets, Logs, Architekturdiagrammen oder Kundendaten im Prompt-Kontext. Je nach Tool-Setup (Cloud-Backend, Telemetrie, Training/Retention) drohen Offenlegung und Kontrollverlust über Geschäftsgeheimnisse, sicherheitsrelevante Informationen oder personenbezogene Daten.
2.5 Security- und Supply-Chain-Risiken
KI kann unsichere Patterns vorschlagen (fehlende Input-Validation, unsichere Kryptographie, SSRF/SQLi), veraltete Dependencies empfehlen oder unbemerkt neue Drittkomponenten „hineinziehen“. Dazu kommt: Agenten können automatisiert Änderungen vornehmen, wodurch klassische Kontrollpunkte (Review, Dependency Governance) umgangen werden, wenn Prozesse nicht angepasst werden.
3. Rechtliche Probleme, die daraus erwachsen
3.1 Urheberrecht: unlizenzierte Übernahme und Bearbeitung
Wenn KI-Output urheberrechtlich relevante Übernahmen enthält und ohne passende Lizenz genutzt wird, entsteht ein klassisches Urheberrechtsrisiko: Nutzung ohne eingeräumte Rechte. Im Streitfall stehen Unterlassung, Beseitigung, Auskunft, Schadensersatz sowie Rückruf-/Stop-Szenarien im Raum – je nach Produktdistribution und Integrationsgrad.
Die urheberrechtliche Problematik wird durch ein Copyright-Vakuum verschärft: Am 2. März 2026 hat der U.S. Supreme Court die Revision in Thaler v. Perlmutter abgelehnt – rein KI-generierte Werke können nach US-Recht (weiterhin) keinen urheberrechtlichen Schutz beanspruchen.
Daraus entsteht derzeit ein Paradox: Wer KI-generierten Code unter MIT oder BSD lizenziert, hat möglicherweise kein Copyright, das er überhaupt lizenzieren könnte. Gleichzeitig kann Copyleft auf nicht-copyrightable Output nicht greifen.
Im EU-Recht fehlt bislang eine vergleichbare höchstrichterliche Klärung; nach h.M. setzt urheberrechtlicher Schutz auch hier eine persönliche geistige Schöpfung voraus, die bei rein maschinell generiertem Code regelmäßig fehlen dürfte
3.2 Open-Source-Lizenzrecht: Pflichtenkaskaden und Wegfall von Nutzungsrechten
Wird AI-generierter Code faktisch als OSS-abhängiges Derivat eingebracht, können OSS-Lizenzpflichten ausgelöst werden: Attribution, Lizenztextbeifügung, Source-Code-Angebot, Copyleft-Weiterlizenzierung, NOTICE-Dateien, Build-Skripte etc. Bei Copyleft kann das – wie aus der OSS-Compliance-Praxis bekannt (GGF LINK ZU VORVERÖFFENTLICHUNG) – zur Offenlegungspflicht führen.
3.3 Geheimnisschutz: Verlust der „Angemessenheit“ von Schutzmaßnahmen
Geschäftsgeheimnisse setzen angemessene Geheimhaltungsmaßnahmen voraus. Ein Prompting-Prozess, der Quellcode oder interne Architektur unkontrolliert in externe Systeme gibt, kann die rechtliche Position schwächen: Nicht nur faktische Offenlegung, sondern auch Argumentationsverlust, dass angemessene Schutzmaßnahmen etabliert waren.
3.4 Datenschutz und Vertraulichkeit: personenbezogene Daten und Kundengeheimnisse
Werden personenbezogene Daten (auch in Logs oder Testdaten) oder kundenbezogene Informationen in KI-Tools eingegeben, entstehen Risiken nach Datenschutzrecht und vertraglichen Vertraulichkeitsregimen (NDA, AVV/DPA, Branchenanforderungen). Kernpunkt ist regelmäßig: Rollenverteilung, Zweckbindung, Transfer, Lösch-/Retention-Regeln, Subprozessoren.
3.5 Vertrags- und Haftungsrisiko gegenüber Kunden und in der Lieferkette
In B2B-Projekten sind OSS-Compliance und Security immer häufiger Lieferkettenanforderungen (SBOM, Third-Party-Notices, Audit-Rechte, Zusicherungen). KI-induzierte Lizenzverletzungen oder Sicherheitsmängel schlagen damit nicht nur intern auf, sondern als Gewährleistungs-/Schadensersatzthema gegenüber Kunden, als Vertragsstrafe oder als Deal-Breaker in Audits/M&A.
4. Wie diese Probleme gelöst werden können (auch nach/während Coding)
4.1 Technische Verifikation statt Bauchgefühl
(a) Code-Scanning auf Lizenz- und Ähnlichkeitsindikatoren: Einsatz von SCA/OSS-Scannern (inkl. Snippet-/Similarity-Erkennung, soweit verfügbar), um AI-beigesteuerte Einfügungen auf potenzielle Lizenzherkunft zu prüfen.
(b) SBOM plus „AI-Provenance“: Ergänzung klassischer SBOM um interne Metadaten, ob/wo KI-Assistenz eingesetzt wurde (Repository/Modul-Ebene), um Audits und Incident Response zu ermöglichen. Ergänzend sollte die SBOM-Prüfung auch upstream-Relizenzierungen erfassen: Im chardet-Fall wurde die Default-Installation über PyPI automatisch auf die MIT-lizenzierte Version aktualisiert. Unternehmen, die Dependencies automatisch aktualisieren, könnten so unwissentlich Code mit ungeklärtem Lizenzstatus in ihre Produkte integriert haben.
(c) Policy-gesteuerte Dependency-Aufnahme: KI darf keine neuen Dependencies „still“ einführen; jede neue Library läuft durch denselben Freigabeprozess wie manuelle Vorschläge.
4.2 Juristische Leitplanken operationalisieren
(a) Klare Regeln, wann AI-Output wie Drittcode zu behandeln ist: Praktikabler Standard: Jeder nicht-triviale KI-Snippet wird wie externer Drittinhalt behandelt (Review, Scan, Attribution-Check).
(b) Copyleft-Risikopfade definieren: Technische Kopplungs- und Distributionsszenarien festlegen (Linking, SaaS/AGPL, Container-Distribution) und „No-Go“-Zonen (z. B. kein KI-Output in Kern-IP ohne Scan/Review).
(c) Vendor-Verträge und Tool-Toggles: Sicherstellen, dass (a) keine Trainingsnutzung/Retention ohne Freigabe erfolgt, (b) Subprozessoren/Transfer kontrolliert sind, (c) Audit- und Löschzusagen dokumentiert sind, (d) IP-Regelungen zum Output klar sind (keine überraschenden Rechteübertragungen an Provider).
4.3 Prozess: Review- und Freigabepunkte anpassen
(a) AI-spezifische PR-Checks: PR-Template-Feld „AI assisted?“ + automatisierte Checks (SCA, Secrets-Scan, License-Scan).
(b) Zwei-Stufen-Review bei sensiblen Modulen: Kernalgorithmen, Security-relevanter Code, Kryptographie, Lizenz-Exposure-Pfade.
(c) Incident Response Playbook: Vorgehen bei Verdacht auf unlizenzierte Übernahme (Quarantäne, Ersetzung, Attribution, Nachlizenzierung, Disclosure, Kundenkommunikation).
5. AI-Coding-Tools von Anfang an compliant handhaben (vor Coding)
5.1 1. Tool-Auswahl und Betriebsmodell
(a) Datenfluss kontrollieren: Bevorzugt Enterprise-/Self-Hosted-Optionen oder Konfigurationen mit deaktivierter Trainingsnutzung und definierter Retention.
(b) Mandantentrennung und Zugriff: SSO, rollenbasierte Rechte, Logging, Repository-Scopes; keine privaten Accounts für Unternehmenscode.
(c) Red-Flag-Verbote: Kein Prompting mit Kundenquellcode, Produktionslogs, Credentials, Security-Findings, unveröffentlichten Patentanmeldungen/Erfindungen.
5.2 Policy: „AI Use Policy“ als Annex zur OSS-Policy
Eine OSS-Policy regelt Drittsoftware. Eine AI-Use-Policy regelt Drittoutput. Inhaltlich sollte sie mindestens definieren:
- erlaubte Tools und Konfigurationen (inkl. Retention/Training off),
- erlaubte Input-Kategorien und verbotene Inhalte (Secrets, personenbezogene Daten, Kundenconfidential),
- Einstufung von KI-Output als „extern“ ab bestimmter Schwellengröße,
- Pflicht-Checks (Scan, Review, Attribution),
- Dokumentationspflicht (z. B. Commit-Tags oder PR-Flags),
- Eskalationswege (Legal/Compliance) bei Copyleft-/Provenienzverdacht.
- Regelungen zur Upstream-Contribution. Die AI Use Policy muss definieren, unter welchen Voraussetzungen AI-assistierter Code in Upstream-Projekte contributed werden darf, und ein Prüfverfahren für die jeweilige Contributor-Policy des Zielprojekts vorsehen. Zahlreiche FOSS-Projekte haben seit dem chardet-Vorfall explizite Anti-LLM-Policies eingeführt (u.a. Zig: „strict no-LLM policy"; FreeBSD: Ablehnung AI-generierten Codes; GNU Guix: „Standing up for human crafting"-Pledge, Mai 2026).
5.3 Engineering Controls: Guardrails im CI/CD
- Pre-Commit/CI: Secrets-Scan, License-Scan, Dependency-Allowlist, Notice-Generator, SBOM-Generierung.
- Repository-Hygiene: SPDX-Header-Standards, Third-Party-NOTICE, automatisierte Attribution.
- Agenten begrenzen: Keine autonomen Merge-Rechte; Agenten arbeiten über PRs mit Review und Checks.
5.4 Schulung mit konkreten Entwicklerregeln
Kurzregeln, die in der Praxis wirken:
- KI ersetzt keine Lizenzprüfung.
- Kein Copy-Paste größerer Blöcke ohne Herkunftscheck.
- Neue Dependencies nur über Freigabeprozess.
- Bei Copyleft/AGPL-Verdacht: stoppen, nicht „wegrefactoren“, sondern klären.
- Prompt-Inhalte sind potentiell Offenlegung: keine Geheimnisse, keine personenbezogenen Daten.
6. Fazit: AI-Coding ist beherrschbar – aber nur als Teil der OSS-Governance
Assisted Programming verschiebt die Compliance-Frage von „Welche OSS ist im Produkt?“ zu „Welche Drittinhalte sind in den Code gelangt – und kann ich das beweisen?“. Unternehmen, die AI-Coding-Tools wie eine weitere Supply-Chain-Quelle behandeln (Policy, technische Kontrollen, SBOM/Provenienz, Vertrags- und Datenschutzsetup), reduzieren nicht nur das Haftungsrisiko, sondern erhöhen Audit- und Transaktionssicherheit. Die Strukturen, die sich in der OSS-Compliance bewährt haben, sind dabei die naheliegende Blaupause.
Die Entwicklungen seit März 2026 bestätigen die Dringlichkeit derartiger Maßnahmen auf neue Weise: Die Frage verschiebt sich weiter – von „Welche Drittinhalte sind in den Code gelangt?" hin zu „Können wir beweisen, dass unsere gesamte Lieferkette – einschließlich upstream-Dependencies – lizenzrechtlich integer ist?". Der chardet-Fall zeigt, dass AI-Rewrites die ökonomische Grundlage von Copyleft-Lizenzen erodieren können und dass die rechtliche Einordnung von AI-generiertem Code – sowohl auf EU-Ebene (GEMA v. OpenAI, TDM-Schranke) als auch in den USA (Thaler v. Perlmutter, Urheberrechtsschutz) – noch Jahre dauern wird.
Wer jetzt eine belastbare OSS- und AI-Governance etabliert, sichert sich nicht nur gegen heutige, sondern auch gegen noch unbekannte regulatorische Anforderungen ab.
