10. Juni 2026
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“:
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?
Um Risiken zu umgehen, müssen Unternehmen sich den Gefahren beim AI-assisted Coding bewusst sein:
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.
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.
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).
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.
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.
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
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.
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.
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.
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.
(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.
(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).
(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).
(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.
Eine OSS-Policy regelt Drittsoftware. Eine AI-Use-Policy regelt Drittoutput. Inhaltlich sollte sie mindestens definieren:
Kurzregeln, die in der Praxis wirken:
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.