KI-generierter Code hat Ihre Urheberrechts-Garantien unterschreibbar unmöglich gemacht, nur die Verträge wissen es noch nicht
Der Developer Certificate of Origin, Apaches Contributor-License-Agreement und jede IP-Garantie darüber hinaus setzen voraus, dass die Urheberschaft von Code feststellbar und beweisbar ist. KI-generierter Code hat diese Annahme widerlegt, und die Spaltung der Open-Source-Welt darüber ist nur das sichtbare Symptom.
Jeder Patch, der in den Linux-Kernel aufgenommen wird, und mit ihm Tausende Projekte, die dessen Prozess übernommen haben, trägt eine Signed-off-by-Zeile. Diese Zeile zertifiziert die erste Klausel des Developer Certificate of Origin: „Der Beitrag wurde ganz oder teilweise von mir erstellt, und ich habe das Recht, ihn unter der angegebenen Open-Source-Lizenz einzureichen.“ Apaches Individual Contributor License Agreement verspricht mit anderen Worten dasselbe: „Sie erklären, dass jeder Ihrer Beiträge Ihre eigene Schöpfung ist.“ Diese Sätze wurden formuliert, als ausschließlich Menschen als Autoren infrage kamen, und jedes Dokument, das darauf aufbaut, Procurement-Fragebögen, IP-Garantien gegenüber Kunden, die Offenlegungsanhänge bei einer Übernahme, erbt ihre zentrale Annahme: dass der Urheberrechtsstatus von Code etwas ist, das sein Autor kennen und sein Eigentümer beweisen kann. KI-generierter Code hat diese Annahme im Stillen widerlegt. Die Klauseln werden trotzdem täglich unterschrieben. Wörtlich genommen kann sie kaum noch jemand wahrheitsgemäß unterzeichnen.
Warum lässt sich das Urheberrecht an KI-generiertem Code nicht mehr überprüfen?
Folgen Sie dem Mechanismus. Die Systeme, die Code generieren, wurden mit öffentlichen Repositories unter jeder denkbaren Lizenz und jedem Urheberrechtsstatus trainiert, und nichts in ihrer Ausgabe hält fest, worauf ein bestimmter Vorschlag zurückgeht, es gibt kein Register zum Nachschlagen. Die Entwicklerin, die den Vorschlag übernommen hat, kann die Lizenz des Ergebnisses nicht belegen, und der Anbieter des Tools kann es auch nicht. Das ist kein Verifikationsproblem, das bessere Werkzeuge im nächsten Jahr lösen: Die Information wurde nie erfasst, sie lässt sich also auch nicht nachträglich beschaffen. Jede Klausel, die auf beweisbarer Urheberschaft aufbaut, vom Contributor-Sign-off bis zur IP-Garantie im Unternehmenskaufvertrag, ruht jetzt auf einer Tatsache, die niemand mehr kennen kann.
Die geschäftlichen Folgen zeigen sich lange bevor ein Gericht überhaupt involviert wäre. Due-Diligence-Fragebögen bei Beschaffung und Übernahmen fragen inzwischen direkt nach der Herkunft von Code. Kunden in regulierten Branchen wollen Zusicherungen, dass ausgelieferter Code frei von Lizenzkontamination ist. Garantie- und Freistellungsklauseln werden danach kalkuliert, was sich belegen lässt. In jedem Fall wurde das Vertragswerk für eine Welt geschrieben, in der eine kompetente Prüfung zumindest im Prinzip jede Zeile auf einen Autor und eine Lizenz zurückführen konnte. Die Prüfung können Sie weiterhin beauftragen, nur beantworten kann sie die Frage nicht mehr.
Open Source ist an der Beweislücke bereits gespalten
Am deutlichsten zeigt sich, wie ernst Entwicklerinnen und Entwickler das nehmen, in der Open-Source-Governance. Gentoos Council hat KI-generierte Beiträge 2024 verboten und nannte Urheberrecht als einen der Gründe. NetBSDs Commit-Richtlinien stufen KI-generierten Code standardmäßig als belastet ein und lassen ihn nur mit Zustimmung des Core-Teams zu. QEMU lehnt ihn ab, aus genau dem Grund, mit dem dieser Artikel begonnen hat: Beitragende können die Herkunft nicht ehrlich mit dem Sign-off zertifizieren, das jeder Patch verlangt. Bemerkenswert ist, welche Form eine mildere Richtlinie zwangsläufig annimmt. Eine Regel, die KI-generierten Code nur dort zulässt, wo Beitragende dessen Urheberrechtsstatus verifizieren können, klingt nach Kompromiss, ist aber, da diese Verifikation gar nicht existiert, ein vollständiges Verbot im Gewand einer Erlaubnis. Das sind community-geführte Projekte, deren einziges unersetzliches Kapital eine lückenlose Rechtekette ist, und sie verzichten lieber auf Beiträge, um sie zu behalten.
Die andere Hälfte des Ökosystems läuft in die entgegengesetzte Richtung, mit Personalbudget im Rücken. Im Earnings Call zum dritten Quartal 2024 sagte Sundar Pichai den Analysten, „mehr als ein Viertel des gesamten neuen Codes bei Google wird von KI generiert und anschließend von Ingenieuren geprüft und übernommen“, eine Aussage, über die damals breit berichtet wurde, und die größten Konzerne hinter der Linux Foundation verkaufen genau die Werkzeuge, die solche Zahlen treiben. Keines der beiden Lager kann allerdings zeigen, was in seinem Code tatsächlich steckt. Kein Detektor für maschinell geschriebenen Code hat bisher die Zuverlässigkeit erreicht, die eine Lizenzprüfung erfordern würde, also läuft die Durchsetzung über Selbstauskunft; der Linux-Kernel setzt eher auf Offenlegung als auf Verbot, aber eine Offenlegungspflicht erfasst nur jene Beitragenden, die sich freiwillig daran halten. Wie hoch der tatsächliche Anteil KI-unterstützter Patches auch sein mag, ein Ehrenwortsystem kann nur eine Untergrenze melden, nie eine Messung. Herkunftsprobleme sind zudem transitiv: Selbst ein striktes Projekt importiert Abhängigkeiten, die unter freizügigeren Richtlinien gepflegt werden, und kommerziell angestellte Beitragende warten große Teile der Infrastruktur, die jede Distribution ausliefert. Die KI-Richtlinie eines Projekts verrät seine Risikobereitschaft. Über sein Repository sagt sie fast nichts aus.
Warum kann eine Software-Stückliste die Garantie nicht ersetzen?
Der Reflex ist, auf die Software-Stückliste (SBOM) zu verweisen. Das hilft nicht, und das liegt an der Struktur der Standards selbst. Die Felder, die SPDX und CycloneDX definieren, beschreiben Komponenten: Namen, Versionen, Lieferanten, deklarierte Lizenzen, Abhängigkeitsbeziehungen. In keinem der beiden Formate gibt es ein Feld, das festhält, wie der Code in einer Komponente entstanden ist oder ob ihn ein Mensch geschrieben hat. SPDX 3.0 hat zwar ein KI-Profil ergänzt, aber es dient dazu, KI-Systeme zu beschreiben, die als eigenständige Produkte ausgeliefert werden, nicht dazu, die Urheberschaft von gewöhnlichem Quellcode zu dokumentieren. Ein SBOM inventarisiert, was Sie betreiben, es war nie dafür konzipiert, dessen Herkunft zu belegen. Es an die Stelle einer Herkunftsgarantie zu setzen, ist ein Kategorienfehler, und Due-Diligence-Prüfer fangen an, das zu bemerken.
Ist KI-generierter Code ein Urheberrechtsrisiko für Ihr Unternehmen?
Die Rechtslage ist ungeklärt, und auf ihre Klärung zu warten, ist keine Strategie, weil das Risiko vertraglich und reputationsbezogen ist, lange bevor es überhaupt juristisch wird. Sinnvoll ist, Lizenzhygiene von einer einmaligen Checkliste zu einer laufenden Risikobeurteilung pro Abhängigkeit zu machen. Kennen Sie die KI-Richtlinien der Upstream-Projekte, auf die Sie tatsächlich angewiesen sind, und behandeln Sie „keine Angabe“ als eigene Risikokategorie. Lassen Sie Garantie- und Freistellungsklauseln daran messen, was heute beweisbar ist, statt an dem, was früher als gegeben galt; eine uneingeschränkte Zusicherung „eigene Schöpfung“ ist ein Versprechen, das Ihre Entwicklerinnen und Entwickler für Sie nicht einhalten können. Treffen Sie die Entscheidung zur Risikobereitschaft bewusst, auf der Ebene, auf der Architektur entschieden wird: Genau das sollte eine ernsthafte Technologiestrategie-Prüfung standardmäßig aufdecken, und es gehört in dasselbe Gespräch wie KI-Reife vor dem Bauen. Wenn Ihre eigenen Teams Code mit KI generieren, gilt dieselbe Disziplin intern, ein weiteres Argument dafür, Menschen die Kontrolle über KI-Ausgaben behalten zu lassen, statt das Werkzeug wie einen Autor zu behandeln.
Jede dieser Projektrichtlinien ist im Kern eine Entscheidung über Risikobereitschaft, und Ihr Unternehmen steht vor derselben Wahl, eine Abhängigkeit und eine Unterschrift nach der anderen. Die Unternehmen, die gut durch diese Phase kommen, werden nicht diejenigen sein, die sich für das „saubere“ Lager entschieden haben. Es werden diejenigen sein, die bemerkt haben, dass es keine Möglichkeit zur Prüfung gibt, und das eingepreist haben.
Häufige Fragen
Kann Software erkennen, ob Code von einer KI geschrieben wurde?
Nicht zuverlässig. Kein Detektor für maschinell erzeugten Code hat bisher die Genauigkeit erreicht, die eine Lizenzprüfung erfordern würde; Klassifikatoren irren in beide Richtungen, und schon triviale Änderungen hebeln sie aus. Deshalb verlassen sich Open-Source-Projekte auf Selbstauskunft der Beitragenden statt auf Scans, und jeder genannte KI-Anteil sollte als Untergrenze gelesen werden, nicht als Messung.
Können Entwicklerinnen und Entwickler den Developer Certificate of Origin noch unterschreiben, wenn sie KI-Coding-Tools nutzen?
Das hängt vom Projekt ab. QEMUs Richtlinien kommen zu dem Schluss, dass Beitragende die Herkunft von KI-generiertem Code nicht ehrlich zertifizieren können, und lehnen entsprechende Patches ab, während der Linux-Kernel eher auf gekennzeichnete Offenlegung setzt. Prüfen Sie die Richtlinie jedes Projekts, bevor Sie beitragen, denn ein Sign-off ist eine rechtliche Aussage zur Herkunft, keine Formsache.
Was sollten wir Anbieter zur Herkunft von KI-Code fragen?
Fragen Sie nach ihrer Richtlinie für KI-unterstützte Entwicklung, danach, wie KI-Beiträge gekennzeichnet und geprüft werden, ob ihre IP-Garantien widerspiegeln, was tatsächlich beweisbar ist statt bloß angenommen wird, und wer im Falle einer Anfechtung der Herkunft ausgelieferten Codes für die Freistellung haftet.
Verwandte Artikel
- Epic gegen Google: Die App-Katalog-Klausel, die Google seinen Rivalen den Burggraben schenkt
- Speicherpreise haben gedreht: Verhandeln Sie den Liefervertrag neu, bevor der nächste Refresh ansteht
- Wie KI schlechte Chefs noch schlimmer macht: Die Ja-Sager-Maschine im Chefbüro
- Digital Business
Verfasst von einer KI-Redaktionspersona des proprietären Redaktionssystems von Abyshire und von unserem Team geprüft.