Microsoft en Github aangeklaagd voor opensourceschending door AI tool

| AE 13669 | Informatiemaatschappij, Intellectuele rechten | 17 reacties

Otto, the inflatable autopilot from the movie “Airplane.”

Programmeur en jurist Matthew Butterick heeft Microsoft en Github aangeklaagd vanwege schendingen van opensourcelicenties, las ik bij Bleeping Computer. De reden is Github’s tool Copilot, een AI code generator die getraind is op de bergen software die op Github gehost worden. De generator blijkt regelmatig lappen tekst uit bestaande werken 1-op-1 aan te leveren, zonder daarbij de juiste licentie + bron te noemen. Hoe zeiden ze dat ook weer, één bron jatten is plagiaat en duizend is inspiratie?

Vorig jaar bracht Github de dienst Copilot uit, een AI-gedreven pair programmer die ontwikkelaars helpt bij het schrijven van code. Copilot stelt contextgebonden code en functies voor, en helpt actief bij het oplossen van problemen door te leren van de code die iemand schrijft. “Trained on billions of lines of public code, GitHub Copilot puts the knowledge you need at your fingertips, saving you time and helping you stay focused.” Het idee is vrij simpel: soms heb je even een klein zetje nodig, een paar regels code om weer verder te kunnen – of om te beseffen, nee dit is precies niet hoe het moet. (Ik experimenteer zelf met Lex.page, die dit doet voor tekstschrijvers, als iemand een invite wil hoor ik het graag.)

Het probleem is natuurlijk: die suggesties moeten ergens vandaan komen. Dat is dus die inspiratie, die patronen die Copilot leert herkennen in honderdduizenden bestanden met source code. Net zoals Lex.page en vele andere tools dat doen met tekst, en DALL-E en consorten met afbeeldingen. Alleen: die hebben een bronbestand dat orde van groottes ruimer is. Alle teksten van heel internet versus alle geprogrammeerde software op Github, dat scheelt nogal een slok op een borrel. Daar komt bij dat er bij software nou eenmaal heel wat minder manieren zijn om iets aan te geven, het moet nou eenmaal technisch aansluiten op het voorgaande.

Het verbaast mij dan ook helemaal niets dat je bij Copilot veel vaker gewoon een lap code uit eerdere software krijgt, “hier, zoals deze het doet”. Dat is helemaal logisch gezien context en dataset, alleen is dat juridisch dus problematisch want een lap broncode in je eigen werk overnemen noemen wij auteursrechtinbreuk tenzij dat mag van de licentie. En aangezien dat dus vaak een opensourcelicentie is, krijg je dan te maken met eisen zoals naamsvermelding of – bij de GPL – het weer moeten open sourcen van je eigen broncode wanneer je dat werk publiceert.

Naar goed Amerikaans gebruik is Butterick dus nu een class action lawsuit begonnen, waar iedereen mag meedoen die ook code op Github heeft staan. Het lastige bij zulke zaken is altijd bewijzen dat jouw werk is overgenomen. Maar specifiek bij dit soort Amerikaanse zaken kan dit interessant worden: als onderdeel van de discovery procedure moet Github op zeker moment onthullen hoe zij aan haar dataset is gekomen. En dan kun je gewoon zien dat jouw code daarin is opgenomen (of niet, maar dat lijkt onwaarschijnlijk).

Arnoud

GitHub brengt AI-programmer uit die helpt bij het schrijven van code, mag dat van de GPL?

| AE 12764 | Intellectuele rechten, Ondernemingsvrijheid | 10 reacties

GitHub heeft een technische preview uitgebracht van Copilot, een AI-gedreven pair programmer die ontwikkelaars helpt bij het schrijven van code. Dat las ik bij Tweakers. Copilot stelt contextgebonden code en functies voor, en helpt acties bij het oplossen van problemen door te leren van de code die iemand schrijft. De AI is getraind op een grote dataset van publieke broncode, en dat zal vast grotendeels open source zijn onder de GPL want dat is nu eenmaal de bulk van de “publieke” software. Maar de GPL vindt daar iets van, van hergebruik.

Copilot kan automatisch opmerkingen omzetten in code, repetitieve code aanvullen en een functie testen tijdens het schrijven. Het systeem leert en verbetert zichzelf. Het klinkt als een hele goede ontwikkeling, maar als je even doordenkt dan besef je dat dit alleen kan door een héle berg broncode door te akkeren en tot een machine learning model om te zetten. Dat zegt men zelf ook:

Trained on billions of lines of public code, GitHub Copilot puts the knowledge you need at your fingertips, saving you time and helping you stay focused.

Er is die merkwaardige gedachte dat als iets “publiek” is, dat je er dan wat mee mag. Misschien moeten we naast “data is niets” nog een juridisch mantra invoeren: “dat het publiek is, is geen argument”. Want het gaat hier om software, en die is zonder twijfel auteursrechtelijk beschermd. En wanneer die “publiek” online staat, dan weet ik vrij zeker dat het om open source gaat. En dan krijg je dus te maken met de licentie. Of niet?

Interessant genoeg zegt men in de FAQ dan:

GitHub Copilot is a code synthesizer, not a search engine: the vast majority of the code that it suggests is uniquely generated and has never been seen before. We found that about 0.1% of the time, the suggestion may contain some snippets that are verbatim from the training set. Here is an in-depth study on the model’s behavior.
Er is natuurlijk een ontzettend groot verschil tussen een lap code copypasten en heel goed kijken naar “billions of lines of code” om jezelf te trainen. Wie zei dat ook weer, kopiëren uit één bron is diefstal en kopiëren uit honderd is inspiratie? Dat lijkt me hier ook van toepassing.

Het komt neer op de algemene vraag of het maken van een machine learning model een kopie is van alle brondocumenten of -data. Als dat zo is, dan krijg je met de licentie te maken en daar zou dan in dit geval de GPL op van toepassing kunnen zijn. Dan zou alle code die Copilot suggereert, onder de GPL vallen, want dan is al die code afgeleid van de GPL code die erin ging. En dan is dus ook elk door Copilot mede geschreven project GPL.

Bewijstechnisch valt daar nog wel wat op aan te merken: de GPL auteur zal moeten bewijzen dat deze suggestie gedaan is op basis van haar code, want zonder kopie geen inbreuk. En dat zal niet meevallen. Maar dat terzijde.

Is een machine learning model inbreuk op de rechten van de brondocumenten? In de VS waarschijnlijk niet. In 2019 oordeelde de Second Ciruit (de hogerberoepsrechter voor New York, Connecticut en Vermont) dat het verwerken van stukjes uit boeken om een boekenzoekalgoritme te trainen géén inbreuk op auteursrechten is. De dataset die daarmee ontstaat, is dus niet onderworpen aan toestemming (of licentie) van de boekenrechthebbenden.

In Europa zijn er geen vergelijkbare zaken. We hebben wel de Infopaq-zaak, waarin werd bepaald dat het overnemen en verspreiden van 11 woorden (een snippet in zoekresultaten) onderworpen kan zijn aan auteursrechten, maar het ging daar om het publiceren van zoekresultaten in een nieuwsbrief. Dat is toch echt wat anders dan een statistisch model maken waarin staat dat codestukje X vaak samengaat met Y, of dat constructie A goed aansluit bij aanhef B. Ik volg dan ook de conclusie van professors Gotzen en Janssens:

Vooral de overwegingen in de arresten Infopaq I, in verband met bepaalde handelingen van ‘data capturing’ die onder het toepassingsgebied van de uitzondering kunnen vallen, verdienen aandacht. Maar de vijf voorwaarden die de uitzondering … oplegt, zijn cumulatief en, mede in het licht van de regel van de strikte interpretatie, zijn we niet geneigd om te concluderen dat alle gebruikshandelingen voor het trainen van AI-systemen die gebruik maken van beschermd materiaal, door deze uitzondering zullen worden afgedekt.
Die vijf voorwaarden zijn als volgt:
  1. deze handeling is tijdelijk;
  2. deze handeling is van voorbijgaande of incidentele aard;
  3. deze handeling vormt een integraal en essentieel onderdeel van een technisch procedé;
  4. dit procedé wordt toegepast met als enig doel de doorgifte in een netwerk tussen derden door een tussenpersoon of een rechtmatig gebruik van een werk of beschermd materiaal mogelijk te maken, en
  5. deze handeling bezit geen zelfstandige economische waarde.
Een machine learning dataset maken is een tijdelijke handeling, die essentieel en integraal nodig is om het neuraal netwerk mee te maken. Dat trainen is niet op zichzelf economisch waardevol (de exploitatie van het resultaat natuurlijk wel, maar dat bedoelt men hier niet). Punt 4 zou je dan naar analogie moeten interpreteren, wat het Hof van Justitie doet in punt 64 van het arrest:
wanneer de levensduur ervan is beperkt tot hetgeen noodzakelijk is voor de goede werking van het betrokken technische procedé, waarbij dit procedé geautomatiseerd moet zijn zodat deze handeling automatisch, zonder menselijke interventie, wordt gewist zodra de functie ervan om dit procedé mogelijk te maken is vervuld.
Oftewel in gewone taal “ik extraheer even de essentiële kenmerken om een statistisch model te maken, daarna gooi ik het weer weg” en dat zou dan mogen.

Arnoud

Github introduceert werknemersvriendelijk IP-contract

| AE 9359 | Ondernemingsvrijheid | 4 reacties

Broncodebeheerbedrijf Github staat sinds kort toe dat hun werknemers de rechten (IP) op eigen werk mogen houden als ze die met bedrijfsmiddelen of onder werktijd hebben gemaakt, meldde QZ onlangs. Hiermee wijkt men werknemersvriendelijk af van de standaard in de VS: gebruikelijk daar is dat alle IP toekomt aan de werkgever van alles dat ook maar enigszins gerelateerd is aan het werk, of dat met een bedrijfsmiddel vervaardigd is. Met de Balanced Employee IP Agreement wil men een modeltekst voor andere werkgevers bieden. Zou dat ook in Nederland nodig zijn?

Allereerst meteen even een ergernis uit de weg: nee, IP bestaat niet en intellectueel eigendom ook niet. Die termen verwijzen naar een juridisch rechtsgebied, net zoals arbeidsrecht – maar we spreken niet van aantasting van je arbeidsrechten, we zeggen dat je te weinig vakantiedagen krijgt of dat de proeftijd in strijd met de wet is. Doe dat dus ook niet meer met “IE”: wil men auteursrechten hebben, octrooien of iets anders? (En dit is geen muggeziften, ik zie te veel contracten waarin “het IE” als een autonoom onderwerp wordt behandeld náást auteursrechten.)

Maar goed. Auteursrecht dan maar even. Volgens de wet (artikel 7 Auteurswet) komt, tenzij anders overeengekomen, het auteursrecht toe op wat de werknemer maakt in het kader van het dienstverband. Wij kennen dus geen criteria zoals “het moet onder werktijd zijn gemaakt” of “het moet in directe opdracht zijn gemaakt” of “er moet een werkcomputer zijn gebruikt”. In het weekend op je eigen laptop een ongevraagd rapport met aanbevelingen voor een betere testprocedure typen, maakt dat de werkgever daar het auteursrecht op heeft. Op werkdagen tussen 9 en 12 op de bedrijfscomputer een roman schrijven is waarschijnlijk plichtsverzuim maar de rechten op die roman heb je zelf.

Amerikaansrechtelijke brede claims op alles dat je doet tot 2 jaar na je ontslag, ongeacht tijdstip of middel, zijn dus tegen de wet bij ons. Afgezien van dat “tenzij anders overeengekomen” dan: je mag als werkgever en werknemer anders afspreken. Ik blijf erbij dat dat beide kanten op gaat (sorry Alex), als beiden willen afspreken dat ook privéprojecten werkgeverseigendom worden, dan moet dat contractueel kunnen. (Wel op schrift en met handtekening, in verband met artikel 2 Auteurswet.) Waarom je dat als werknemer zou tekenen is natuurlijk een andere vraag.

Een probleem daarbij is wel dat zo’n afspraak tegen het basale principe van kenbaarheid aanloopt. Een toekomstig auteursrecht afstaan kan namelijk alleen als het betreffende werk op voorhand voldoende kenbaar is. “Ik wil dat je een roman schrijft en ik wil daar de auteursrechten op” voldoet daar waarschijnlijk wel aan. Maar “ieder project dat jij de komende jaren start, wordt van mij” is écht te vaag.

Misschien als je het koppelt aan het werk: “alle projecten die verwant zijn aan producten/diensten die wij leveren, worden van ons”, dat is nog redelijk te toetsen. Alleen: wélke? Die men nu heeft? Of ook in de toekomst? En alleen van de afdeling waar meneer/mevrouw werkt, of het hele bedrijf? Wereldwijd? En hoe definieer je ‘verwant’? Ik denk dat het daar al snel op zal stranden.

Hoe dan ook, die BEIPA van Github lijkt me te Amerikaans specifiek. Als principe vind ik het wel een heel goed idee: laat werkgevers ook eens nadenken over wat creatieve werknemers naast het werk willen doen, en claim niet op voorhand daar de rechten op. Programmeren is niet alleen werk, het is ook gewoon leuk.

Arnoud

Mag je in een Git repository andermans merknaam gebruiken als verwijzing?

| AE 8983 | Intellectuele rechten, Ondernemingsvrijheid | 5 reacties

Diverse lezers wezen me (dank!) op dit artikel over het Docker-merk dat strenge regels hanteert over wat je met hun merknaam mag doen. Eén van die regels is dat je geen extensies mag publiceren op Docker als je daarbij de term ‘Docker’ gebruikt. Kan dat zomaar? Docker is een containersysteem voor software, waardoor deze makkelijker… Lees verder

Mag GHTorrent openbare data van Github aggregeren als onderzoeksdataset?

| AE 8460 | Intellectuele rechten, Privacy | 25 reacties

Mag je eisen dat je e-mailadres verwijderd wordt uit de GHTorrent dataset? Een veel voorkomende klacht bij dit project. GHTorrent is een onderzoeksproject dat Github-softwareprojecten indexeert en gemakkelijk doorzoekbaar maakt. Hierbij worden ook de e-mailadressen van ontwikkelaars geïndexeerd, waardoor je allerlei koppelingen kunt leggen. Maar mag dat eigenlijk wel? Github is een van de grootste… Lees verder

Moet je bij een notice/takedown je hele GitHub repository verwijderen?

| AE 7673 | Intellectuele rechten | 15 reacties

Een lezer vroeg me: Als ik in mijn GitHub repository een pull-request binnenhaal waar ik later een notice and takedown over krijg, voldoet het dan om met een nieuwe commit de omstreden code te verwijderen (de omstreden code blijft dan in in de git historie beschikbaar) of moet ik dan de hele repository verwijderen? Voor… Lees verder