Het chardet-project heeft laten zien dat AI open source kapot gaat maken, aldus Bruce Perens. En hij kan het weten, want hij schreef de definitie van open source destijds. Chardet is van licentie veranderd na een AI-herimplementatie, en de vraag is dus of dat kan.
Chardet is een Python-bibliotheek die van een tekst aangeeft in welke codering (zoals UTF-8, Cyrillisch of Oost-Aziatisch) deze opgemaakt is. Handig ding, wel even opletten want de licentie is de bekende LGPL. Dus wijzigingen aan de library zelf kun je alleen onder LGPL verspreiden. (En dat verhaal over statisch en dynamisch linken.)
Sinds versie 7 is de bibliotheek ineens onder de MIT licentie beschikbaar. Dat scheelt, want de enige eis is dan dat je de auteursvermelding en licentietekst niet weghaalt uit de broncode. En dat je de auteur, in dit geval ene Dan Blanchard, niet aansprakelijk kunt stellen, maar dat terzijde.
Zoals Perens uitlegt:
Blanchard says he was in the clear to change licenses because he used AI – Anthropic’s Claude is now listed as a project contributor – to make what amounts to a clean room implementation of chardet. That’s essentially a rewrite done without copying the original code – though it’s unclear whether Claude ingested chardet’s code during training and, if that occurred, whether Claude’s output cloned that training data.Probleem: hoewel Blanchard de code sinds 2012 onderhoudt, was hij niet de originele auteur. Dat was Mark Pilgrim, die rond die tijd van internet was gevallen maar nu ineens weer opdook met een boze ticket: No right to relicense this project.
Auteursrechtelijk klopt dat; zonder overdrachtsakte kan Blanchard code van Pilgrim niet onder een andere licentie plaatsen. Maar Blanchard stelt dus dat versie 7 een geheel nieuwe versie is, en roept daarbij dat zelfs een “clean room implementation” vormt.
Clean room reverse engineering is een oude techniek waar veel mythes omheen hangen. Kort gezegd: groep A analyseert iemands software en documenteert wat het moet doen. Groep B krijgt die documentatie en maakt software die dat doet. A’s analyse is legaal, en B kopieert de software niet dus handelt ook legaal.
Dit staat of valt met één cruciale aanname, namelijk dat B geen toegang heeft tot de software die A analyseert. Want als je wél kopieert, ga je nat. En toegang hebben en dan iets sterk vergelijkbaars maken levert op zijn minst een donkerbruin vermoeden van kopiëren op.
Clean room werkte om geheim gehouden software (zoals de IBM PC BIOS software) legaal te kunnen imiteren. Maar bij open source is het juridisch gezien absurd om van clean room te spreken. De broncode ligt letterlijk voor het oprapen. Dus hoe kun je dan met droge ogen beweren dat je een schone herimplementatie hebt gemaakt?
Oh ja, we deden het met AI. Blanchard zegt allereerst dat zijn nieuwe code vrijwel volledig anders is, wijzend op een software-plagiaattool die slechts 1,29% gelijkenis tussen de bronbestanden ziet. Dat komt dan weer omdat Blanchard aan de codegenerator van Anthropic’s Claude heeft gevraagd een nieuwe versie te maken:
For full transparency, here’s how the rewrite was conducted. I used the superpowers brainstorming skill to create a design documentspecifying the architecture and approach I wanted based on the following requirements I had for the rewrite […]Hij gebruikte daarbij nadrukkelijk de opdracht “kijk niet naar de LGPL code”, wat voor mij net zo nuttig is als “maak geen fouten” in je prompt. Zeker omdat het volgens mij een publiek geheim is dat LLM-codegeneratoren getraind zijn op Het Hele Internet en dus ook op alles op Github. Waaronder de originele chardet.
Clean room is dit dus zeker niet te noemen. Tegelijk wordt het inbreuk-argument wel weersproken door de feitelijke ongelijkheid tussen de broncodes. Er moet wel iets aantoonbaar overgenomen zijn om van inbreuk te mogen spreken.
Uiteindelijk is dat het punt van Perens: als je dus tegen een AI kunt zeggen “herschrijf deze code” en de gelijkenis is lager dan X procent, dan is iedere OSS licentie te omzeilen door de software gewoon even door zo’n LLM-room te halen.
Arnoud
Maar de vraag is nu wel of er auteursrechtelijke bescherming is voor deze door een AI tool herschreven software. Zo nee, dan is de herschreven software vrij van auteursrecht, en zijn dus ook de voorwaarden van de MIT licentie niet van toepassing.
Ik meen dat er al een rechtzaak is geweest over AI en copyright, en het resultaat was dat er geen auteursrecht kan rusten op AI gegenereerde dingen, omdat AI geen mens is en auteursrecht alleen voor mensen bedoeld is. (Zie ook de zaak van de foto van de aap)
De inbreuk op de onderliggende rechten van het LGPL origineel wordt daarmee niet gepasseerd. Of je de LGPL dan hebt aanvaard betwijfel ik, maar bij inbreuk moet je stoppen natuurlijk.
Als de code 100% door een AI geschreven zou zijn was het vrij van auteursrecht, maar in dit geval is er een menselijke co-auteur (Dan B.) die een deel van de code geschreven heeft. (of dat claimt)
Op het deel dat door een mens geschreven is zit wel auteursrecht en daarmee kan Dan B. nakoming van de licentie afdwingen.
Maar wat als de AI die de specs omzet in code aantoonbaar is getraind door hem alleen sourcecode met een MIT-achtige license te voeren? Misschien is hij zelfs helemaal airgapped zodat er geen enkele twijfel kan bestaan.
Je gaat natuurlijk nooit kunnen aantonen waar een AI niet op getraind is (een negatief bewijzen is eigenlijk altijd onmogelijk) dus zelfs als je kunt aantonen dat de AI is getraind op “alleen” MIT-achtige licenties zal dat nooit afdoende bewijs kunnen vormen.
Het is sowieso niet aan de model makers om te bewijzen dat het niet zo is, het is aan de klagers om te bewijzen dat het wel zo is.
En good luck met het reproduceren van niet boilerplate/generieke GPL code met een model dat alleen maar MIT/BSD code heeft gezien.
Dat wordt al helemaal moeilijk, omdat zowel BSD- en MIT-gelicentieerde code gebruikt wordt in GPL-software. De GPL code die je gebruikt is zelf dus – overigens geheel legaal – vervuild.
Hetzelfde argument geldt dan toch net zo goed voor alle andere, niet-open source software?
“hey Claude, create a complete specification of MS SQL Server 2027 and create a fully ABI-compatible implementation using Rust with tokio.”
Het verschil met gesloten software is dat je daar niet kunt spieken in de broncode. Een specificatie opstellen op basis van geobserveerd gedrag van de software is legaal, en die specificatie implementeren is dat ook. Maar zodra je bij een edge case even onder de motorkap kijkt hoe ze dat anticiperen, kom je in de gevarenzone.
Maar hier had de maker juist gezegd dat hij niet gespiekt had in de oude broncode. Als dat door de giecheltoets komt, waarom dit dan niet?
Het gaat er toch om of de AI-tool gespiekt heeft? Die heeft waarschijnlijk heel Github in de trainingsdata (want waarom zou je dat niet doen) en dus ook de originele chardet.
Even los daarvan.
Is de AI systeem dat zelfstandig programmeert en de maker is, waardoor er sowieso volgens mij geen auteursrechten op het product zouden moeten rusten, want we kennen computers geen rechten toe die een mensen heeft.
Of is het een tool die een mens gebruikt om te programmeren. Vergelijkbaar met een IDE met code completion, alleen dan geavanceerder. In de AI tool programmeer je niet in de uiteindelijke programmeertaal, maar de AI is een interpreter die gedetailleerd gewoon Engels interpreteert en omzet in de uiteindelijke programmeertaal.
In dat laatste geval is Blanchard als degene die de tool instrueerde de auteur van de software en is er zeer zeker geen sprake van clean room ongeacht waar de ai op is getraind.
Belangrijk is niet de programmeertaal die je gebruikt, maar dat de taal die je gebruikt maar specifiek genoeg beschrijft wat de computer moet doen en dat kan je ook doen in Nederlands of Engels en iteratief kan je specificatie toevoegen als blijkt dat je niet exact genoeg geweest bent en de AI een dobbelsteen heeft gegooid om te bepalen wat je bedoelt.
Zowel de programmeur als de AI die de nieuwe code hebben ontwikkeld hadden kennis van de oorspronkelijke, publieke code. Dat kan je niet even ‘uitzetten’. In mijn ogen is het daarom onontkoombaar dat de nieuwe code een afgeleid werk is. Het lijkt me dat de LGPL die op het oorspronkelijke werk van toepassing is daarom ook geldt voor de nieuwe, afgeleide code.
In mijn ogen is de mate van exacte code-gelijkheid geen goede maatstaf om te bepalen of iets wel of niet een afgeleid werk is. Twee versies van een film zullen ook nauwelijks pixel-gelijkheid hebben.
Voor video’s zijn er andere manieren om overeenkomst te bepalen dan alleen pixels vergelijken… Met scene overgangen detecteren en de lengtes van scenes bepalen kom je al een heel eind.
Bij code is het heel makkelijk om een regel-bij-regel vergelijking op ongeveer 0 overlap uit te laten komen door variabele en functienamen te veranderen, maar deze wijziging verandert niets aan aspecten als gebruikte bibliotheek aanroepen of structuur van procedure nesting. De truc wordt dan om de structuur van de twee versies te extraheren en de twee structuren te vergelijken.
En als je overlap vindt komt de vraag “Zou een andere programmeur dit ook zo gedaan hebben omdat het een logische oplossing is?” Ieder java programma begint met een package declaratie en een lijst van import statements, dat is inherent aan de taal en dus niet auteursrechtelijk te beschermen.
Hoewel gelijkheid inderdaad niet de maatstaf is, is het ook niet zo dat bekendheid of zelfs sommige inspiratie (hoe het niet te doen) meteen een afgeleid werk oplevert. Dit is niet zo in de literatuur, en ook niet in de software. Als je dan echter de bestaande test set gebruikt om je AI-herbouwing te maken, dan is die herbouwing wel een afgeleid werk van de test set (afhankelijk van hoe specifiek de test-set is – een test set die voor elke tool te gebruiken is zal minder een afgeleid werk geven dan een gedetaileerde collectie unit tests). Natuurlijk is het dan moeilijk om te bewijzen dat de test set gebruikt is.
Dat is zeker waar natuurlijk. De uitdaging is echter, gegeven zo’n specifieke gewenste functionaliteit, hoe implementeer je dat nou echt anders? Zeker als je de broncode hebt gezien. Dit project is al behoorlijk oud en beperkt in scope. Ik zou verwachten dat de code geëvolueerd is tot een efficiënte, logische implementatie. Het lijkt me moeilijk dat op een echt nieuwe manier te herimplementeren.
Evolutie leidt meestal tot een lokaal optimum dat zeker niet de meest efficiënte of logische implementatie hoeft te zijn. Het kan heel goed mogelijk zijn om, met nieuwe inzichten, een totaal andere opzet te bouwen, die nog een stuk efficiënter is. Natuurlijk is het bij de beperkte scope als van dit project niet heel erg waarschijnlijk, maar het is geen wet van meden en perzen dat evolutie tot een globaal optimum komt.
Iets heel anders: ik krijg, uit de antwoorden die ik krijg over een behoorlijk niche programmeertaal waar ik wel eens mee werk, dat de LLM’s niet alleen maar zijn getraind op open source materiaal (want dat is er niet veel), maar dat daar ook het nodige gesloten source spul tussen zit. Dat heeft natuurlijk ook implicaties voor de status van wat eruit kan komen — als sta ik zelf op het standpunt dat code uit een AI voor inbreuk gewoon aan dezelfde normen moet voldoen als code gemaakt door een mens: inspireren en ideeën opdoen prima, plat kopiëren van grote stukken wat minder, met die volgende opmerking, dat als, vanwege de structuur van een probleem, er maar een voor de hand liggende oplossing is, deze niet creatief is, en dus ook niet voor auteursrecht in aanmerking komt.
Zelf bij open source kan men nog steeds een clean room doen. Echter zal men daar dan gebruik moeten gaan maken van software/tools zoals Malus.
De website overtuigt mij niet dat de resultaten een grondige analyse doorstaan en de garantie die Malus biedt is minimaal.
De essentie van clean room is dat team B (de implementors) met de hand op het hart kunnen zweren geen toegang te hebben kunnen gehad tot de broncode. Hoe doe je dat bij broncode die met twee klikken via Github te downloaden is? We geloven je gewoon niet als jij zegt dat niet gedaan te hebben.
@MathFox
Het kan zijn dat het je niet overtuigd. Mogelijk zou een test kunnen uitwijzen dat het inderdaad zo werkt zoals ze beweren. Echter als de opzet is zoals ze beweren, dan is er zeker spraken van een clean room situatie.
@Arnoud Engelfriet
Met de huidige AI automation (de implementors) kan men een daadwerkelijk daarin een scheiding maken. De input van AI Team B en welke connectie ze zouden hebben gehad met het internet en/of training, kan het bewijs leveren die gevraagd wordt.
Als het daadwerkelijk zo werkt bij Malus, dan kan er zeker sprake zijn van een clean room.
Malus biedt een “niet goed, geld terug” garantie, effectief enkele tientjes. Geen vrijwaring voor claims of aanbod voor hulp als er een auteursrechtklacht binnenkomt. Dit terwijl je al snel een paar honderdjes kwijt bent om een IP advocaat een keer terug te laten blafbrieven. Wanneer het tot een rechtszaak komt moet je rekenen op tienduizenden euro’s advocaatkosten.
AI gaat open source niet definitief verwoesten, maar het dwingt wel tot een pijnlijke herdefinitie van wat “vrijheid” en “copyleft” betekenen.
Het juridische probleem dat Arnoud en Perens aankaarten, is de erosie van de Copyleft-bescherming (zoals in de GPL/LGPL). Het doel van die licenties is: “Als je mijn werk gebruikt, moet jouw verbeterde versie ook vrij blijven.”
Als een ontwikkelaar een LLM kan gebruiken om code te herformuleren totdat de plagiaatscanner op 1% uitkomt, omzeil je de geest van de licentie zonder de letter van de wet te breken (omdat auteursrecht alleen de specifieke expressie beschermt, niet de functie).
Zoals het artikel terecht stelt: een echte clean room vereist dat de programmeur de originele code nooit heeft gezien. Bij een LLM is dat onmogelijk te bewijzen. Sterker nog, het is vrijwel zeker dat Claude de originele chardet-code in zijn trainingsset had.
AI verwoest open source niet, maar het verwoest wel de huidige juridische handhaafbaarheid van open source. We gaan van een tijdperk waarin we vertrouwden op de wet (auteursrecht), naar een tijdperk waarin we moeten vertrouwen op verifieerbaarheid en cryptografie (bijv. bewijzen dat code door een mens is geschreven of via een legitieme keten tot stand is gekomen). Blanchard heeft juridisch misschien een punt (als de code echt onherkenbaar anders is), maar hij heeft de “sociale licentie” van zijn project onherstelbaar beschadigd.
Zoals Bruce Perens betoogt: als een AI de logica van een LGPL-library kan “begrijpen” en herschrijven in een andere vorm, vervalt de auteursrechtelijke claim op de specifieke tekst van de code. De LGPL beschermt de code, niet het algoritme. Als de AI de code herformuleert, is er technisch gezien geen sprake meer van “afgeleid werk” in de traditionele zin. De licentie wordt daarmee een papieren tijger.
Als eerste opmerking: Dat GTM’n (LLM’s) code sneller kunnen genereren dan programmeurs betekent dat de waarde van zowel programmeurs en code lager wordt. Dat zal commerciële softwareleveranciers harder raken dan de Open Source beweging.
Dat software die onder een Copyleft licentie is uitgebracht door een GTM voor enkele euro’s herschreven kan worden doet verder niets af aan de waarde van het bestaande pakket, dat komt met een team dat onderhoud en bugfixes doet. De herschreven versie heeft geen community achter zich en onderhoud zal vanuit de gebruiker/verkoper van het pakket moeten gebeuren. Wat dat betreft is de herschreven code Closed Source.
Er is geen fundamenteel verschil waar het gaat om de onderhoudskosten van een stuk code tussen code die door een mens of door een GTM geschreven is. Als je die code voor jezelf wilt houden, zul je ook in het onderhoud moeten voorzien.
Wat ik verwacht te gaan zien is een grotere kloof tussen de auteursrechtmaximalisten (we willen alles zelf in de hand hebben) en meer FLOSS-gezinden (samenwerking leidt tot een betere samenleving).
Als slotwoord: Wanneer het mogelijk is om een GTM FLOSS code te laten herimplementeren, dan is dat ook mogelijk voor Closed Source code. Ik voorzie dat we zo druppelsgewijs met GTM hulp gemaakte “bevrijde” versies van commerciële pakketten gaan zien. Gewoon omdat iemand in de Open Source beweging daar behoefte aan had.
Arnoud, ga je nog schrijven over hoe Anthropic op deze manier in de tank is genomen.
Ze hebben per ongeluk hun Typescript code openbaar gemaakt in hun repository.
Een derde heeft die code genomen en met Claude Code omgezet in python code en die claimt dat dat geen afgeleid werk is.
Ze zitten nu dus in de spagaat dat ze overal claimen dat hun AI niet kopieert en geen afgeleid werk is van wat je er in stopt, maar als ze hun eigen code willen beschermen kan dat alleen door te claimen dat hun model een afgeleid werk maakt. Ze zullen dus een hele dunne lijn moeten bewandelen om zichzelf niet tegen te spreken.
Waar vind ik een voorbeeld van “dat ze overal claimen dat hun AI niet kopieert en geen afgeleid werk is van wat je er in stop”? De algemene positie dat het model geen afgeleid werk is van de trainingsdata deel ik. Maar staat geheel los van het geval waarin je een bak data erin gooit en zegt “schrijf dit om”.
Je hebt gelijk, dat was niet Anthropic.
Sigrid Jin heeft het omgezet en zegt dat hij de architectuur en een beschrijving van de functionaliteit aan de AI heeft gegeven en niet de code, zoals ook voor Chardet is gedaan. (Jin heeft overigens OpenAI Codex en wat tools die daar op bouwen gebruikt) En daarom heeft het een andere licentie en kan een notice en takedown niet.
Ik ben wel benieuwd of Anthropic nu gaat proberen het argument te maken dat het wel een afgeleid werk is, omdat ze daarmee hun eigen klanten tegen zouden spreken.
We hebben nu dus in ieder geval de situatie dat Anthropic en hun klanten een tegengesteld belang hebben. Wat weegt voor Anthropic zwaarder?