Interessante discussie bij het pgrust project: als je bestaande software met een taalmodel omzet naar een andere programmeertaal, kun je dan je eigen licentie op het resultaat plakken?
Het pakket Postgres is een vrije relationele databaseserver. Vrij als in vrijheid: de software is beschikbaar onder de simpele BSD licentie die alle handelingen toestaat (“use, copy, modify, and distribute this software”) zonder nadere voorwaarden behalve copyright notice en geen claims als er fouten in zitten.
Iemand vond het een goed idee om Postgres te porten van de aloude programmeertaal C naar het modernere Rust. Redenen te over: Rust heeft ingebouwde bescherming tegen geheugenlekken en efficiëntere multithreading. En van de licentie mag het, want “modificeren” omvat auteursrechtelijk ook het ‘vertalen’ van een werk.
Het resultaat is zonder al te veel menselijke nabewerking opgeleverd op Github en onder de AGPLv3 licentie geplaatst. Die is iets strenger dan de BSD licentie: afgeleide werken mogen alleen onder diezelfde AGPLv3 aangeboden, en bij publieke vertoning van het werk (SaaS dus) moet de broncode als hyperlink erbij.
Postgres-ontwikkelaar Greg Burd stelde daarop “ter verduidelijking” de vraag: op welke grond is de licentie op onze software omgezet naar die AGPL?
Bij gewone integratie, herimplementatie of hertaling is dat een rare vraag. Immers, als programmeur moet je behoorlijk wat creativiteit inbrengen om dat te doen, en dan heb je auteursrecht op dat resultaat en dan mag je daar een licentie op zetten. Maar waar is hier de menselijke creativiteit, als een taalmodel 95%+ van de creatieve keuzes heeft gemaakt en de mens hooguit nog correcties en hier en daar wat poetswerk?
Een bestaand werk onder een nieuwe licentie plaatsen (dus niet integreren in of herzien tot een eigen werk) mag alleen als het woord sublicentie voorkomt in de licentietekst (voorbeeld: Apache 2.0). Dat is bij BSD niet het geval.
De reactie van de Rustversie-initiatiefnemer (Michael Malis) leest voor mij als een politiek zorgvuldig statement:
Re human vs ai authorship: we didn’t keep precise records of which code is ai generated and which code is human authored. Many of the high-level design decisions I personally made. For example, how to represent the Postgres error handling and memory management in Rust were decisions I personally made. These decisions for how memory management and error handling are designed are reflected in nearly every function.Het is inderdaad goed voorstelbaar dat je als developer keuzes op hoog niveau maakt, en dan een taalmodel die uit laat werken naar concrete software. Alleen zijn “keuzes op hoog niveau” niet het soort creatieve inbreng waar je auteursrecht mee krijgt. De keuze “doe maar lila” is te weinig om auteursrecht op Postgres-de-software te krijgen. Daarvoor moet je echt actief in de broncode aan het schilderen zijn geweest.
Een subtiele oplossing kan nog zijn dat je zegt: daar waar sporen van creativiteit uit het origineel te herkennen zijn, geldt gewoon de BSD licentie. Auteursrecht door de taalmodel-wijzigingen is juridisch onmogelijk, dus afgezien van het handwerk achteraf is die gehele codebase gewoon BSD.
Het enige lastige daarmee is dat licenties – ook open source – niet binden tenzij je daarmee akkoord bent gegaan. Licenties zijn contracten. En afgaande op de reactie van Malis weigert hij de BSD licentie te accepteren. Dan blijft als conclusie over dat er auteursrechtinbreuk wordt gepleegd, want er wordt dan software aangeboden zonder rechtsgeldige licentie.
Arnoud
Waarom zou dat bij normale hertaling geen probleem zijn?
Je hebt toegang tot die code onder een licentie, die omzetten in een andere programmeertaal vergt welliswaar eigen creativiteit, maar die komt bovenop de creativiteit van het werk die je vertaalt. En die eist dat de licentie hetzelfde blijft.
Bij een boek heb je toch ook alleen auteursrecht op de vertaling, niet het oorspronkelijke verhaal en heb je je te houden aan de licentie waaronder het boek beschikbaar is? Dit is niet anders.
Bij het “porten” van software is er vaak veel minder creativiteit betrokken dan zeker het vertalen tussen twee menselijke talen. In veel gevallen kunnen dingen heel mechanisch (volgens vaste regels) gedaan worden en het moeilijkste is verschillen in bibliotheken (daarom is het omzetten naar een ander besturingssysteem lastiger). Met andere woorden, auteursrecht is er alleen als er een creative bijdrage/keuze van de auteur is. Volgens vaste regels vertalen is niet creatief. En sommige keuzen zijn creatiever dan andere (veel software regels zijn sowieso niet “creatief”) en vertaling heeft veel voor de hand liggende keuzen (waarschijnlijk dat een andere auteur precies dezelfde keuze zou maken).
Bij een letterlijke port van een programmeertaal naar de andere kan ik dat nog wel zien, maar als een AI bijv. is opgedragen, hetzelfde programmeertechnische “probleem” op een vergelijkbare, maar voldoende afwijkende manier op te lossen, dan wordt het veel lastiger om toepassing van dezelfde licentie te kunnen eisen.
Het auteursrecht beschermt immers niet de functionaliteit, maar alleen de concrete “uitdrukkingswijze”. Anders zou je al snel uitkomen bij het beschermen van ideeën, in plaats van hoe deze specifiek zijn uitgevoerd en vastgelegd.
Als de nieuwe code voldoende verschillend is om niet als afgeleid werk van het “origineel” te gelden, dan zou deze als het goed is zowel auteursrechtvrij (want niet-menselijk), als ook vrij van licenties moeten zijn.
Een punt dat onderbelicht blijft is het morele aspect van het onder een andere licentie uitbrengen van een eigen (vertaalde) versie van Open Source code. Je zou, uit respect voor de originele auteurs, hun licentiekeuze intact horen te laten. (En wat is het fundamentele bezwaar tegen een BSD licentie voor een grotendeels geautomatiseerde vertaling?)
Ik denk dat een mechanische vertaling door AI een mechanische vertaling blijft, en dat daarom het auteursrecht van de oorspronkelijke auteur(s) blijft gelden.
Wat je zou kunnen doen is een zogenaamde “clean-room” herimplementatie, maar dan met LLMs, waarbij je met een LLM de systeemvereisten en het gedrag uit de implementatie extraheert, en daarna met een andere LLM (die niet “toevallig” getraind is op de betreffende code!) uit die geëxtraheerde vereisten een nieuwe implementatie maakt.
Dat lijkt me een stuk lastiger dan de code herschrijven in een andere taal, waarbij de structuur waarschijnlijk gewoon grotendeels in stand blijft.