Virale AI-tool kloont razendsnel betaalde softwareprogramma’s, mag dat?

Artistic black and white photo of a wand levitating over wooden boxes, captured with depth.
Photo by Craig Adderley on Pexels

‘Reverse Engineer Anything’ stelt gebruikers in staat om de code van elke software te analyseren en op de kopieermachine te leggen. Dat meldde Quote gisteren. REA is een taalmodel verbonden aan bekende reverse engineering tools en je kunt zo alle software namaken. Mag dat?

REA gebruikt bekende tools voor decompilatie en disassemblage (zoals Ghidra), met als bijzondere toevoeging dat een set agents via MCP de boel aanstuurt zodat je niet handmatig al dat werk hoeft te doen. Het ziet er bijzonder handig en toegankelijk uit, maar in mijn tijd moest ik met Edlin assembly zien te bewerken dus wie ben ik.

Reverse engineering is auteursrechtelijk natuurlijk problematisch. Grofweg mag je observeren hoe software werkt, zodat je dat ook kunt doen, en mag je file formats uitpluizen zodat je een compatibele lezer of schrijver kunt maken. Maar wat niet mag, is broncode uit elkaar halen en opnieuw in elkaar zetten (behalve voor bug fixes).

Er verandert natuurlijk niets als je het proces laat orchestreren door vergaand autonoom opererende scripts, pardon AI agents. Het gaat vooral veel sneller en we zien minder goed wat de tussenstappen waren. Maar dat is geen reden om het ineens legaal te noemen. Software decompileren en een kloon daarmee maken is vrijwel altijd inbreuk.

Quote noemt als voorbeeld de ArtCraft-suite, open source varianten van zo’n twaalf Adobe- en Microsoft Office-softwarepakketten waaronder PhotoShop (“PhotoCraft”) en LightRoom (“LightCraft”, u snapt het thema). De tagline vind ik briljant: software waarvan je al weet hoe ie werkt.

Dat specifieke voorbeeld klopt niet; het is niet met REA gemaakt en niet op basis van decompilatie. Ontwikkelaar Brandon Thomas liet een groep agents software maken die “moest doen wat Photoshop doet” (en Word, en Excel, et cetera), op basis van een groot aantal voorbeelden van Photoshop-bestanden en openbare documenten over wat er allemaal kan. Dát is legaal, je reconstrueert wat er moet gebeuren en genereert eigen code om dat voor elkaar te krijgen.

Tegelijk laat die methode de beperking zien: het ziet eruit als Photoshop, het werkt zoals Photoshop maar het kan bij lange na niet wat Photoshop kan. De onderliggende algoritmes (de hóe dan van software) staan immers niet in die documenten en volgen ook niet triviaal uit de bestanden.

De slimme oplossing van Thomas is om bestaande opensourcefunctionaliteit te verbinden aan de gekloonde UI, bijvoorbeeld om Excelbestanden te lezen of om berekeningen te maken. Dat kun je ook doen met Photoshop-knopjes, alleen is er momenteel geen open source implementatie die net zo slim en krachtig is als wat Adobe op de markt brengt. (Onaardig is om dit Gimp-met-Photoshop-skin te noemen. Vooral voor Gimp, want daar werkt wél alles.)

Wat ik zo vervelend vind, is dat overal de media dit brengt als “AI reverse engineering”, alsof de geheime algoritmen van Adobe en Microsoft door geavanceerde AI technieken achterhaald zijn en hun software nu 100% opnieuw gebouwd is door software afscheidende taalmodellen. Zo ver zijn we nog lang niet, en dit is geen bewijs dat het die kant op gaat.

En ja, in theorie zou je met AI het klassieke clean room reverse engineering kunnen doen, dat ooit op de IBM PC BIOS software is gebruikt. Twee systemen: de ene gebruikt REA om PhotoShop geheel uit elkaar te pluizen en een uitgebreide specificatie op algoritme-niveau te schrijven. De andere ontvangt enkel en alleen die specificatie en produceert code.

Dit heeft nogal wat voeten in de aarde maar ik zie niet waarom het niet in principe zou kunnen. De problemen beginnen bij het bewijzen of het heeft gewerkt: hoe toon je aan dat er geen disassembled Adobe software in de trainingsdata zat, en dat systeem A geen technische inzichten heeft gelekt in de specificatie?

Arnoud

 

 

13 reacties

  1. Hoe toon je aan dat er geen disassembled Adobe software in de trainingsdata zat, en dat systeem A geen technische inzichten heeft gelekt in de specificatie?

    Of je claimt te reverse engineeren, of met AI gewoon een nieuwe app te ontwikkelen, maakt hier natuurlijk geen verschil.

    Je zou denk ik kunnen documenteren hoe je in beide onderdelen de modellen gebruikt – eventueel specifiek verschillende modellen – om trainen van het model uit te sluiten.

    Maar je weet niet of de modellen al eerder zijn getraind op de code.

  2. Ik zie dat fabrikanten dit nu ook als een probleem zien, en ik loop hier zelf ook tegenaan.<br/>

    Ik ben bezig met een clean-room implementation van Efinix software, die maakt bitstream files voor hun hardware devices (FPGA’s). Nu zegt de license :<br/>

    Except to the extent such restrictions are prohibited under applicable law, Licensee may not decompile, translate, reverse-engineer, disassemble, or otherwise reduce the Licensed Software, data files generated by the Licensed Software, and/or programmable hardware devices, transmit the Licensed Software, or make any hard-copy memory dumps of the object code.

    Da’s leuk, maar in hoeverre mag je dit in NL beperken ? De cleanroom doet in principe :<br/>

    Genereer vele inputfiles, en kijk dat hoe de output veranderd. Daarmee leg je dan bloot hoe het formaat in elkaar zit, en vooral, ook hoe de hardware werkt.<br/>

    Dit is al eerder gedaan (project Trellis), maar in hoeverre mag een fabrikant dit beperken ?

    1. Die “except to the extent” staat erbij omdat in de EU decompilatie, disassemblage en reverse engineering algemeen legaal is om de werking van software te achterhalen, en dat mag niet worden verboden. Specifiek bij decompilatie geldt de beperking dat dat alléén mag “indien deze handelingen onmisbaar zijn om de informatie te verkrijgen die nodig is om de interoperabiliteit van een onafhankelijk vervaardigd computerprogramma met andere computerprogramma’s tot stand te brengen” (artikel 45m Aw). Oftewel: alleen omdat jouw applicatie moet samenwerken met de app die je decompileert.

      Wat jij doet klinkt voor mij als puur observeren. Je achterhaalt werking maar kijkt niet naar broncode van de software. Dat is in de EU niet verboden dus die licentiebepaling die je citeert, mist hier toepassing.

      1. Waar in de EU / NL wetgeving staat dat ? Het doel is om om software te ontwikkelen die de benodigde bitstream voor die software kan produceren.

        Het is eigenlijk een dikke mutatietest : Je veranderd 1 feit in de output, en kijkt hoe de uitvoer veranderd.

        Ik ga die software dus alleen gebruiken om de bitstreams te genereren voor alle testcases, om zo te achterhalen wat het bitstream formaat is.

        1. Artikel 45l Auteurswet: “Hij die bevoegd is tot het verrichten van de in artikel 45i bedoelde handelingen, is mede bevoegd tijdens deze handelingen de werking van dat werk waar te nemen, te bestuderen en te testen teneinde de daaraan ten grondslag liggende ideeën en beginselen te achterhalen.” Dit is ingevoerd op basis van artikel 5 lid 3 Softwarerichtlijn (2009/24/EG).

          De term “ideeën en beginselen” omvat ook bestandsformaten. Dat bepaalde het Hof van Justitie in zaak C-406/10 (SAS).

          1. Kunnen ze dat de Wet bescherming bedrijfsgeheimen niet hiervoor gebruiken door te stellen dat de bestandformaten een bedrijfsgeheim zijn ?

            Het lastige eraan is dat de software gewoon vrij en makkelijk te verkrijgen zit. Een ander punt is het porren in de hardware : Je kan door analyses achterhalen hoe het werkt (geen decap dus).

            1. Dat is niet alleen lastig, dat maakt dat argument juridisch onhaalbaar. Je moet bedrijfsgeheimen adequaat beschermen. Het in vrij verkrijgbare software stoppen zonder enige maatregel is niet adequaat, hoe je dat ook wendt of keert. Bij selecte b2b sales waarbij elke klant een NDA tekent, misschien.

  3. Ik heb nooit begrepen hoe die clean-room truc ooit goed is gevonden. Compileren/decompileren is effectief gewoon iets wat in de ene taal is geschreven, omzetten naar een andere taal. Als je dat doet dan breek je gewoon copyright. In het geval van die cleanroom is een van de talen gewoon Engels, waarom is dat nu ineens anders ?

  4. Op door AI gemaakte software geldt toch geen copyright? Bij die artcraft-software zetten ze er een MIT-licentie op (als ik het goed zie), maar als het helemaal door AI gedaan is kan dat toch niet?

    Op Arstechnica (https://arstechnica.com/gaming/2026/10/report-epic-games-goes-all-in-on-ai-for-disney-collaboration/) lees ik dat Epic Games alles in het vervolg door AI wil laten programmeren. “No more hand-written code”, alleen maar gidsen door mensen. Betekent dat dan ook dat hun software in het vervolg copyright-vrij is? Dan is het helemaal makkelijk software kopiëren.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.