Kein Recht, dieses Projekt neu zu lizenzieren

• Mark Pilgrim, der ursprüngliche Autor von chardet, weist auf einen Verstoß gegen die LGPL-Lizenz des Projekts hin und fordert, die jüngste Umstellung auf die MIT-Lizenz in Version 7.0.0 zurückzunehmen
• Er stellt klar, dass es sich selbst dann um ein Derivat handelt, das unter direkter Einsicht in den Originalcode erstellt wurde, wenn die Maintainer von einer „vollständigen Neuschreibung“ sprechen, und dass deshalb die LGPL beibehalten werden muss
• Mehrere Entwickler diskutieren, ob eine KI-gestützte Neuschreibung tatsächlich eine „Clean-Room-Implementierung“ ist und ob ein LLM auf den Originalcode trainiert wurde
• Einige erwähnten API-Kompatibilität und die Möglichkeit von Fair Use, die Mehrheit äußerte jedoch Bedenken wegen möglicher Urheberrechtsverletzungen und der rechtlichen Unsicherheit bei KI-generiertem Code
• Die Debatte wird als wichtiger Präzedenzfall rund um die urheberrechtliche Verantwortung für KI-generierten Code, Abläufe bei Lizenzänderungen in Open-Source-Projekten und die Grenzen der Befugnisse von Maintainern angesehen

---

Mark Pilgrims Einwand

• Mark Pilgrim erklärt, dass er der ursprüngliche Autor von chardet ist und das Projekt unter der LGPL-Lizenz veröffentlicht wurde
  • Er weist darauf hin, dass die Behauptung der Maintainer, sie hätten in Version 7.0.0 das Recht zur Neulizenzierung, falsch sei
  • Code unter der LGPL müsse auch nach Änderungen unter derselben Lizenz veröffentlicht werden, und die Behauptung einer „vollständigen Neuschreibung“ habe keine rechtliche Grundlage
  • Er stellt klar, dass das „Hinzufügen eines Code-Generators“ keine neuen Rechte verleiht
• Pilgrim fordert, das Projekt auf die ursprüngliche LGPL-Lizenz zurückzusetzen

Erste Reaktionen der Community

• Ein Nutzer fragte, ob es einen Fork einer Version vor der KI-gestützten Neuschreibung gebe; ein anderer verwies auf einen Link zu Version 6.0.0
• Einige stimmten zu, dass „Mark rechtlich im Recht ist“, und erkannten einen möglichen LGPL-Verstoß an
• Andere erwähnten aus pragmatischer Sicht, dass eine „Neuschreibung mit KI ein unvermeidlicher Trade-off“ sei

Juristische Debatte: API, Urheberrecht, Fair Use

• Ein Nutzer verwies auf das Urteil Google LLC v. Oracle America, Inc. und merkte an, dass auch APIs urheberrechtlich geschützt seien
  • Eine Neuschreibung aus Gründen der API-Kompatibilität könne rechtswidrig sein, wenn die Voraussetzungen für Fair Use nicht erfüllt seien
• Darauf entgegnete ein anderer Nutzer, dass der Fall von Google als Fair Use anerkannt worden sei
• Die Diskussion weitete sich auf die Rechtmäßigkeit API-kompatibler Neuschreibungen und den urheberrechtlichen Status von KI-generiertem Code aus

Streit um KI-Code und Clean-Room-Implementierung

• Einige wiesen darauf hin, dass eine Clean-Room-Implementierung nicht vorliegt, wenn „die KI möglicherweise auf den Originalcode trainiert wurde“
  • Ob ein LLM auf den chardet-Code trainiert wurde, könnte entscheidend für die rechtliche Bewertung sein
• Andere argumentierten, dass es möglich sein könnte, „wenn die KI den Code nur auf Basis von Ein- und Ausgaben erzeugt hat“
  • Dagegen wurde eingewandt, dass „damit die Lizenz selbst bedeutungslos würde“
• Die unklare urheberrechtliche Verantwortung für KI-Code und die Schwierigkeit, die Einhaltung von Lizenzen zu überprüfen, rückten als zentrale Streitpunkte in den Vordergrund

Lizenzkompatibilität und GPL-Debatte

• Einige behaupteten, die MIT-Lizenz sei nicht mit der GPL kompatibel; ein anderer zitierte jedoch die offizielle Dokumentation der FSF und erklärte, dass MIT (Expat) GPL-kompatibel sei
• Allerdings bestand weitgehend Einigkeit darüber, dass eine Neulizenzierung von LGPL-Code unter MIT weiterhin einen Verstoß darstellt
• Ein weiterer Nutzer merkte an, dass man „nicht den Ruf und das Repository eines auf LGPL-Code basierenden Projekts behalten und zugleich die Verpflichtungen daraus abwerfen kann“

KI-Trainingsdaten und Vertrauensfrage

• Mehrere Nutzer stellten die Frage, ob man glauben könne, „dass Claude keinen LGPL-Code gelernt hat“
  • Die mangelnde Nachvollziehbarkeit von KI-Trainingsdaten wurde als rechtliches Risiko genannt
• Einige argumentierten, dass man den Einsatz von KI-Code grundsätzlich vermeiden sollte, wenn er die Möglichkeit von Plagiaten in sich trägt
  • Unter Verweis auf Forschung wurde eine Statistik genannt, wonach 2–5 % von KI-Code Kopien bestehenden Codes sein könnten

Projektidentität und Befugnisse der Maintainer

• Einige vertraten die Auffassung, dass eine neue Version unabhängig sein könnte, wenn sämtlicher früherer Code früherer Mitwirkender entfernt wurde
  • Dem wurde jedoch entgegengehalten, dass die weitere Nutzung von Name und Reputation unangemessen sei
• Es wurde auch die Ansicht geäußert, dass „das Urheberrecht Ausdrucksformen schützt, nicht Namen“
• Manche meinten, es liege womöglich kein Rechtsverstoß vor, wenn die Maintainer tatsächlich den gesamten bestehenden Code entfernt haben, allerdings wurde kein klarer Beleg dafür vorgelegt

Gesamtbild aus Sicht der Community

• Mehrere Nutzer betonten, dass sowohl die Beiträge von Mark Pilgrim als auch von Dan Blanchard Respekt verdienten und dass man die komplexen Fragen rund um KI, Urheberrecht und Open-Source-Governance anerkennen müsse
• Die Diskussion weitete sich auf Themen wie die rechtliche Verantwortung für KI-Codegenerierung, die Legitimität von Lizenzänderungen bei Projekten und die Grenzen der Befugnisse von Open-Source-Maintainern aus
• Einige schlugen auch vor, v7.0.0 zu forken und wieder unter die LGPL zu stellen

Zusammenfassung der Kernpunkte

• Rechtmäßigkeit des Wechsels von LGPL zu MIT: Nach Mehrheitsmeinung ohne Zustimmung des ursprünglichen Rechteinhabers nicht möglich
• Urheberrechtlicher Status einer KI-Neuschreibung: Könnte je nach Exposition gegenüber den Trainingsdaten als Derivat gelten
• Frage der Clean-Room-Implementierung: Es müsste nachgewiesen werden, dass die KI den Originalcode nicht referenziert hat
• Problem der Nutzung von Projektname und -ruf: Eine Weiterverbreitung unter demselben Namen ist rechtlich und ethisch umstritten
• Vertrauenswürdigkeit von KI-Code: Sorgen über Plagiatsrisiken und die Stabilität der Supply Chain

Dieser Fall gilt als ein repräsentatives Beispiel für die Fragen rund um Urheberrecht bei KI-generiertem Code und die Einhaltung von Open-Source-Lizenzen und könnte künftig Einfluss auf die Struktur der rechtlichen Verantwortung für KI-Entwicklungstools haben.

[GN⁺]

Hacker-News-Kommentare

• Ich denke, Pilgrim missversteht das Konzept des Clean Room beim Urheberrecht. Die Behauptung einer „vollständigen Neuschreibung“ ist nicht entscheidend. Rechtlich ist eine unabhängige Implementierung möglich. Clean Room ist nur ein prozedurales Mittel, um Prozesse zu vereinfachen; es ist keine rechtliche Anforderung, dem Originalcode nie ausgesetzt gewesen zu sein. Tatsächlich kannte auch Linux die interne Struktur von Unix, wurde aber unabhängig implementiert.

  • Unabhängig von der rechtlichen Auslegung ist es besorgniserregend, wenn KI GPL-Code automatisch neu schreiben und damit die Lizenz umgehen könnte, denn dann würde die Waffe der Open-Source-Community verloren gehen.
  • Auch die Behauptung, man könne anhand eines Tests auf strukturelle Ähnlichkeit entscheiden, ob es sich um ein abgeleitetes Werk handelt, ist falsch. Ebenso ist es falsch, allein wegen der Nutzung von Claude pauschal auf ein abgeleitetes Werk zu schließen. Der tatsächliche rechtliche Maßstab bleibt weiterhin ein unklarer Bereich.
  • Man muss in drei Fällen denken.
    1. Wenn der Code ähnlich ist, muss eine Clean-Room-Neuimplementierung nachgewiesen werden.
    2. Wenn er völlig anders ist, spielt Clean Room keine Rolle.
    3. Meist gibt es eine Mischung aus ähnlichen und unähnlichen Teilen, daher muss jeder Teil einzeln analysiert werden. Wenn auch nur einzelne Abschnitte kopiert wurden, müssen genau diese Teile neu geschrieben werden.
  • Die Funktion von chardet (Erkennung von Unicode-Kodierungen) ist im Wesentlichen festgelegt. Deshalb ist es selbstverständlich, dass eine neue Implementierung dieselben Tests besteht. Die niedrige Ähnlichkeit bei JPlag wirkt wie ein überzeugender Beleg dafür, dass es kein Plagiat ist.
  • Es überrascht mich, dass manche glauben, von KI erzeugter umgeschriebener Code sei urheberrechtlich geschützt.

• Die Behauptung „Wenn man die Codebasis kennt, ist schon das Umschreiben eine Urheberrechtsverletzung“ ist nicht vollständig stichhaltig. Internes Wissen betrifft den Patentbereich und hat mit dem Urheberrecht nichts zu tun. Wenn man aber den Originalcode danebenlegt und nur die Formulierungen austauscht, ist das natürlich ein Verstoß. Wenn eine KI den Originalcode sieht und ähnlichen Code erzeugt, könnte das faktisch als parallele Kopie angesehen werden. Wenn man den Originalcode dagegen nicht gesehen hat und alles komplett neu schreibt, ist es möglich. Rechtlich ist das aber schwer zu verteidigen, weshalb Unternehmen es als Risiko betrachten sollten.

  • Der Unterschied zwischen Patenten und Urheberrecht muss klar sein. Patente können unabhängig von einer eigenständigen Erfindung verletzt werden, beim Urheberrecht ist die Unabhängigkeit der Schöpfung entscheidend. Wenn man jedoch ein Werk schafft, das mit etwas identisch ist, das man bereits gesehen hat, wird es schwer, eine Jury zu überzeugen. Am Ende ist es bei Ähnlichkeit gut möglich, dass auf Grundlage der überwiegenden Wahrscheinlichkeit (preponderance of evidence) eine Verletzung angenommen wird.
  • Wenn man Mario Puzos The Godfather liest und dann einen Roman mit derselben Struktur schreibt, würde das als abgeleitetes Werk gelten. Wenn man das Original dagegen überhaupt nicht kennt, wird es als unabhängige Schöpfung anerkannt.
  • Wenn es eine Datei Claude.md gibt, ist es wahrscheinlich, dass der neue Maintainer Claude als Codegenerator verwendet hat, und das Modell dürfte mit dem Originalcode von chardet trainiert worden sein.
  • Es kam die Frage auf: „Wie anders muss neuer Code sein, um als neu anerkannt zu werden?“
  • Eine Neuschreibung ist ähnlich wie eine Übersetzung. Auch eine Übersetzung ist eine Urheberrechtsverletzung. Die Idee selbst ist nicht geschützt, wohl aber ihre Ausdrucksform. Wenn ein LLM den Originalcode im Trainingsprozess gesehen hat, ist das eine rechtliche Grauzone.

• Im Kern geht es um einen Verstoß gegen die LGPL. Wenn der neue Code auf dem Original basiert, gilt er als abgeleitetes Werk und muss daher unter der LGPL bleiben. Selbst wenn man von einer „vollständigen Neuschreibung“ spricht, kann es ein Lizenzverstoß sein, wenn man dem Originalcode ausgesetzt war.

  • Allein die Kenntnis des Originals macht daraus nicht automatisch ein abgeleitetes Werk. Clean Room ist nur ein Verfahrensmittel zur Prozessverteidigung, und die Beweislast liegt beim Kläger. Auch Linux oder GNU-Werkzeuge kannten Unix und waren dennoch legal.
  • Wenn Claude tatsächlich auf dem Originalcode trainiert wurde, folgt aus dieser Auslegung die interessante Schlussfolgerung, dass KI nur LGPL-abgeleitete Werke erzeugen könnte.
  • Entscheidend ist das Urheberrecht. Wenn der neue Code ein abgeleitetes Werk des Originals ist, muss er der LGPL folgen; wenn nicht, kann der neue Rechteinhaber die Lizenz frei festlegen.
  • Wenn man unter demselben Namen nur die Versionsnummer erhöht, könnte es faktisch wie dasselbe Projekt wirken.

• Ich habe während einer Beratung einen interessanten Fall gesehen. Ein Engineer eines SaaS-Unternehmens hat mit Claude Code in einer Woche das eigene App-Produkt per Reverse Engineering analysiert und ein API-kompatibles Backend gebaut. Es kam die Frage: „Wie schützt man sich, wenn ein Wettbewerber das genauso macht?“

  • Das ist einfach technologischer Fortschritt. Wenn der Code selbst der Kern des Geschäfts ist, besteht ohnehin schon ein Risiko. Statt sich vor Konkurrenz zu fürchten, ist es wichtiger, ein besseres Produkt zu bauen.
  • Wie im Fall von StrongDM Factory wird es real, externe Dienste zu kopieren und für Tests zu verwenden. Wir leben jetzt in einer Zeit, in der „Lasst uns Slack oder Drive neu implementieren“ nicht mehr unrealistisch klingt.
  • Wenn eine KI nur das Frontend gesehen und daraus das Backend neu implementiert hat, dann ist das legal. Eine API ist eine öffentliche Schnittstelle und daher nicht geschützt.
  • Patente lassen sich nicht nachträglich anmelden, und das Urheberrecht schützt keine Ideen. Wie bei den Reverse-Engineering-Fällen rund um IBM BIOS oder DOS ist eine unabhängige Implementierung legal.

• Ein Maintainer ist ein Treuhänder (trustee), kein Eigentümer. Er darf die Lizenz des Originalautors nicht eigenmächtig ändern. Wenn der Code wirklich komplett neu erstellt wurde, sollte man das Projekt unter einem neuen Namen starten. Aussagen wie „Dann friert eben die bestehende Version ein“ widersprechen dem Geist der Community.

• Schon in einem Kommentar von 2021 wurde erwähnt, dass „chardet auf LGPL basiert und daher nicht umgelizenziert werden kann“. Wenn man das wusste und trotzdem neu geschrieben hat, war das eine leichtsinnige Entscheidung und respektlos gegenüber dem Originalautor.

  • Umgekehrt gibt es auch die Ansicht, dass es die richtige Entscheidung war, um die Nutzbarkeit des Projekts zu maximieren.

• Wenn KI den Originalcode gesehen hat und dann schreibt, ist das keine Clean-Room-Implementierung. Wäre es zulässig, zwei KI-Teams einzusetzen, von denen eines die Spezifikation erstellt und das andere implementiert? Das würde dem Präzedenzfall aus der IBM-Zeit folgen, aber wenn das Modell bereits auf dem Original trainiert wurde, bleibt es problematisch.

  • Wenn chardet in den Trainingsdaten enthalten war, ist ein Clean Room in keiner Form möglich.
  • Wenn eine Spezifikation extrahiert und ein separates Modell daraus Code schreibt, wäre Clean Room theoretisch möglich. Allerdings müsste verifiziert werden, dass die Spezifikation keine ausdrucksbezogenen Elemente enthält.
  • Wenn das Original in den Trainingsdaten steckt, bleibt die Wahrscheinlichkeit eines Verstoßes hoch.
  • Es gab auch die Behauptung, die API-Struktur sei Teil des Urheberrechts, die aber später korrigiert wurde.
  • Der Fall IBM/Compaq ist nur oberflächlich ähnlich. Wenn das Original in den Trainingsdaten enthalten ist, wird der Vergleich selbst bedeutungslos.

• Wie in dem Witz „Ist es okay, wenn ich Wikipedia copy-paste und nur ein paar Wörter ändere?“ gilt letztlich: Absichtliche Umgehung funktioniert nicht. Wir leben in einer Zeit, in der es schwer ist, genug Vertrauen zu haben, um nicht sogar Abhängigkeitsversionen festzupinnen.

  • Techniker missverstehen das Recht oft als technisches Regelwerk. Aber das Recht legt Wert auf eine Gesamtwürdigung. Gerichte entscheiden nach dem Maßstab der „überwiegenden Wahrscheinlichkeit“, und bloß einzelne Wörter auszutauschen macht daraus kein neues Werk. Wenn das Original notwendig war, ist es gut möglich, dass es als abgeleitetes Werk bewertet wird. Wenn das Original in den Trainingsdaten enthalten ist, wird eine Urheberrechtsklage wohl unvermeidlich sein.

• Andererseits ist es interessant, dass Mark Pilgrim wieder aufgetaucht ist. Seine Wikipedia-Seite enthält die Episode seines „Verschwindens aus dem Internet“. Seine Python-Bücher sind nach wie vor empfehlenswert.

  • Bald wird vielleicht auch der GitHub-Account „a2mark“ auf Wikipedia erwähnt.

• Es gibt auch die Überraschung: „Wenn KI mit GPL-Code trainiert wurde, ist dann nicht jeder KI-Code GPL-kontaminiert (taint)?“

  • Es gibt Projekte wie ReactOS, die einen vollständigen Clean Room verlangen, aber das ist nur eine rechtliche Absicherung und keine Pflicht.
  • Um eine „Kontaminierung“ nachzuweisen, müsste tatsächlich die Abgeleitetheit bewiesen werden. Das Clean-Room-Verfahren in den USA ist nur eine Strategie zur Verkürzung von Prozessen.
  • Da das Urheberrecht ursprünglich ein Schutzinstrument für Kapital war, halten manche es für unwahrscheinlich, dass es in der Praxis so streng durchgesetzt wird.
  • Schon seit dem frühen Hype um LLMs gab es Leute, die vor genau diesen Problemen gewarnt haben.