KI-Rewrites als Lizenz-Hack: Ist das das Ende von Copyleft?

Ein Projekt, ein KI-Rewrite, und die Open-Source-Welt hält den Atem an

Stell dir vor, du nimmst ein Open-Source-Projekt, das unter der strengen LGPL-Lizenz steht, lässt den gesamten Code von einer KI komplett umschreiben – und veröffentlichst das Ergebnis plötzlich unter der freizügigen MIT-Lizenz. Klingt nach einem Loophole? Genau das ist letzte Woche passiert, und die Auswirkungen könnten die gesamte Open-Source-Landschaft verändern.

Das Python-Paket chardet – ein Zeichensatz-Detektor, der von tausenden Projekten als Abhängigkeit genutzt wird, unter anderem vom allgegenwärtigen requests-Modul – hat mit Version 7.0.0 einen radikalen Schritt gewagt. Die Maintainer haben Claude Code genutzt, um die gesamte Codebasis neu zu schreiben, und das Ergebnis unter der MIT-Lizenz veröffentlicht. Das Problem: Der ursprüngliche Code basierte auf Mozillas C++-Implementierung und war an die LGPL gebunden.

Was folgte, war ein Sturm in der Open-Source-Community – und eine juristische Debatte, die noch lange nicht beendet ist.

Warum das chardet-Projekt so brisant ist

Chardet ist kein Nischenprojekt. Es wird von Millionen von Python-Installationen als transitive Abhängigkeit geladen. Jedes Mal, wenn du pip install requests ausführst, landet chardet mit auf deiner Festplatte. Wenn sich die Lizenz eines solchen Pakets ändert, hat das Welleneffekte durch das gesamte Ökosystem.

Die LGPL (Lesser General Public License) erlaubt zwar die Nutzung in proprietärer Software, verlangt aber, dass Änderungen am LGPL-Code selbst unter derselben Lizenz veröffentlicht werden. Die MIT-Lizenz hingegen ist maximal freizügig: Du kannst den Code nehmen, in ein kommerzielles Produkt stecken und musst praktisch nichts zurückgeben.

Der Wechsel von LGPL zu MIT ist also nicht nur ein technisches Detail – es ist eine grundsätzliche Verschiebung der Spielregeln.

Das Clean-Room-Problem: Warum KI die Mauer durchbricht

In der traditionellen Software-Rechtsprechung gibt es ein bewährtes Konzept für legale Rewrites: die Clean-Room-Implementierung. Das funktioniert so:

• Team A analysiert den Originalcode und schreibt eine rein funktionale Spezifikation – was der Code tut, nicht wie
• Team B – das den Originalcode nie gesehen hat – implementiert die Funktionalität basierend auf dieser Spezifikation

Diese strikte Trennung stellt sicher, dass kein urheberrechtlich geschützter Code in die neue Implementierung einfließt. So hat beispielsweise Compaq den IBM-PC-BIOS-Code legal nachgebaut und damit die PC-Industrie revolutioniert.

Das Problem bei KI-Rewrites: Diese Mauer existiert nicht. Wenn du Claude Code den LGPL-geschützten Originalcode gibst und sagst „Schreib das neu”, dann hat die KI den Originalcode gesehen. Sie „kennt” die Struktur, die Algorithmen, die Logik. Das ist das genaue Gegenteil einer Clean-Room-Implementierung.

Der ursprüngliche Autor von chardet, bekannt als a2mark, sieht das als klaren GPL-Verstoß:

„Licensed code, when modified, must be released under the same LGPL license. Their claim that it is a ‘complete rewrite’ is irrelevant, since they had ample exposure to the originally licensed code.”

Und er hat einen Punkt. „Exposure” – also die Kenntnis des Originalcodes – ist in der Urheberrechtspraxis ein entscheidender Faktor. Dass zwischen dem menschlichen Entwickler und dem neuen Code eine KI als Vermittler steht, ändert daran möglicherweise nichts.

Der Supreme-Court-Plot-Twist: KI-Code hat kein Copyright

Als wäre die Situation nicht schon kompliziert genug, kam am 2. März 2026 eine Entscheidung des U.S. Supreme Court, die alles noch verworrener macht. Das Gericht lehnte es ab, einen Berufungsfall zu KI-generierten Urheberrechten zu verhandeln. Damit bleiben die Entscheidungen der unteren Gerichte bestehen, die im Wesentlichen sagen: KI-generierter Output kann nicht urheberrechtlich geschützt werden, weil ihm die „Human Authorship” fehlt.

Das erzeugt ein faszinierendes juristisches Paradox für die chardet-Maintainer:

Das Copyright-Vakuum

Wenn KI-generierter Code nicht urheberrechtlich geschützt werden kann, dann haben die Maintainer möglicherweise gar nicht das Recht, den Code unter irgendeiner Lizenz – ob MIT oder sonst was – zu veröffentlichen. Du kannst nur lizenzieren, was dir gehört. Und wenn der Code der KI „gehört” (oder niemandem), dann ist die MIT-Lizenz schlicht wirkungslos.

Die Derivat-Falle

Wenn der KI-Output als abgeleitetes Werk des LGPL-Originalcodes gilt, dann muss er unter der LGPL bleiben. Die „Umschreibung” wäre dann ein Lizenzverstoß – egal wie unterschiedlich der resultierende Code aussieht.

Das Eigentums-Vakuum

Wenn der Code tatsächlich ein „neues” Werk ist, das von einer Maschine erstellt wurde, könnte er technisch gesehen Public Domain sein – frei für jeden, ohne jede Lizenz. Das würde die MIT-Lizenz überflüssig machen und gleichzeitig das gesamte Konzept von Software-Lizenzen in Frage stellen.

Was das für die Open-Source-Welt bedeutet

Hier wird es richtig ernst. Wenn „KI-Rewriting” als gültige Methode akzeptiert wird, um Software-Lizenzen zu ändern, dann endet Copyleft, wie wir es kennen.

Stell dir das Szenario vor: Ein Unternehmen nimmt ein GPL-lizenziertes Projekt – sagen wir den Linux-Kernel, GCC oder eine beliebte WordPress-Erweiterung – und lässt eine KI den gesamten Code umschreiben. Drei Tage später steht der funktional identische Code unter MIT oder einer proprietären Lizenz. Die jahrzehntelange Arbeit der Open-Source-Community? Mit einem Prompt umgangen.

Das klingt dystopisch, aber es ist die logische Konsequenz, wenn KI-Rewrites als legitimer Weg akzeptiert werden.

Die Perspektive der Befürworter

Fairerweise muss man sagen: Nicht jeder sieht das so dramatisch. Einige argumentieren:

• Der umgeschriebene Code ist tatsächlich funktional anders – andere Variablennamen, andere Struktur, anderer Stil
• KI-Tools sind letztlich nur ein Werkzeug, wie ein Compiler oder IDE
• Copyleft-Lizenzen schützen den konkreten Ausdruck, nicht die darunterliegende Idee
• Wenn die Funktionalität dieselbe ist, aber der Code komplett anders – wo genau liegt die Grenze?

Diese Argumente sind nicht von der Hand zu weisen. Aber sie öffnen eine Büchse der Pandora, die schwer wieder zu schließen sein wird.

Was ich als Entwickler daraus mitnehme

Als jemand, der täglich mit Open-Source-Bibliotheken arbeitet und KI-Agenten aktiv in meinen Workflow integriert, trifft mich dieses Thema direkt. Hier sind meine Gedanken:

1. Lizenz-Hygiene wird wichtiger denn je

Wenn du Open-Source-Code in deinen Projekten verwendest – und das tun wir alle – solltest du genauer hinschauen, welche Lizenzen in deinem Dependency-Tree stecken. Tools wie license-checker oder fossa helfen dabei. Gerade bei Projekten, die kürzlich Major-Versions-Sprünge hatten, lohnt sich ein Blick auf die Lizenzhistorie.

2. KI-generierter Code braucht klare Richtlinien

Viele Unternehmen und Projekte haben noch keine klaren Richtlinien dafür, wie mit KI-generiertem Code umzugehen ist. Ist er urheberrechtlich geschützt? Wem „gehört” er? Darf er in GPL-Projekte einfließen? Diese Fragen müssen beantwortet werden, bevor nicht jedes zweite npm-Paket in einem Lizenz-Limbo schwebt.

3. Copyleft muss sich weiterentwickeln

Die GPLv3 wurde 2007 geschrieben – in einer Welt ohne LLMs, ohne KI-Coding-Assistenten, ohne die Möglichkeit, eine Codebasis per Prompt umzuschreiben. Wenn Copyleft überleben soll, braucht es eine GPLv4, die explizit KI-generierte Ableitungen adressiert. Organisationen wie die FSF (Free Software Foundation) und die OSI (Open Source Initiative) sind hier gefordert.

4. Das Problem betrifft nicht nur Code

Was für Code gilt, gilt potenziell auch für andere kreative Werke. Texte, Designs, Musik – überall dort, wo Copyleft- oder ähnliche Lizenzen gelten, könnte ein KI-Rewrite die Schutzmechanismen aushebeln. Das chardet-Projekt ist der Kanarienvogel in der Kohlenmine.

Wie geht es weiter?

Der chardet-Fall wird wahrscheinlich nicht vor Gericht landen – dafür ist das Projekt zu klein und die rechtliche Lage zu unklar. Aber er setzt einen Präzedenz in der Community, der schwer zu ignorieren ist.

Was wir in den kommenden Monaten erwarten können:

• Diskussionen in der Linux Foundation und bei der FSF über KI und Copyleft
• Neue Lizenz-Klauseln, die KI-Rewrites explizit adressieren (einige Projekte experimentieren bereits damit)
• Mehr Fälle wie chardet – je besser KI-Coding-Tools werden, desto einfacher wird es, Code umzuschreiben
• Gerichtliche Klärung – irgendwann wird ein Fall groß genug sein, um vor Gericht zu landen

Für uns als Entwickler heißt das vor allem: aufmerksam bleiben. Die Regeln des Spiels ändern sich gerade, und wer das ignoriert, könnte böse Überraschungen erleben.

Mein Fazit

KI-Tools wie Claude Code oder GitHub Copilot sind fantastische Werkzeuge, die unsere Produktivität massiv steigern. Aber sie werfen Fragen auf, für die unser Rechtssystem noch keine Antworten hat. Der chardet-Fall zeigt, dass die Grenze zwischen „Werkzeug nutzen” und „Lizenz umgehen” erschreckend dünn ist.

Als Webentwickler, der sowohl Open-Source-Software nutzt als auch KI-Agenten einsetzt, sage ich: Wir brauchen dringend klare Regeln. Nicht um Innovation zu bremsen, sondern um das Fundament zu schützen, auf dem wir alle bauen – die Open-Source-Community und das Vertrauen, das Copyleft-Lizenzen seit Jahrzehnten sichern.

Was denkst du? Ist ein KI-Rewrite ein legitimer Weg, Lizenzen zu ändern – oder ein Angriff auf die Grundfeste von Open Source? Ich bin gespannt auf die Diskussion.