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 geen open source meer op Github zetten?

| AE 9296 | Intellectuele rechten | 10 reacties

Paniek in de tent: softwarehostingsite Github heeft nieuwe voorwaarden, en die botsen met veel open licenties. Dat las ik op diverse plekken. Je moet ze een brede licentie geven en afstand doen van je persoonlijkheidsrechten, en dat kan nu eenmaal niet als je open source daar neerzet. Maar volgens mij valt dat wel mee.

De pijn zou zitten in sectie D, over eigendomsrechten. Allereerst de licentie die je moet verlenen:

If you set your pages and repositories to be viewed publicly, you grant each User of GitHub a nonexclusive, worldwide license to access your Content through the GitHub Service, and to use, display and perform your Content, and to reproduce your Content solely on GitHub as permitted through GitHub’s functionality. You may grant further rights if you adopt a license.

In gewone taal: wij als Github mogen jouw content (inclusief eventuele werken van derden daarin) gebruiken en verspreiden op onze dienst, en alle gebruikers mogen dat ook. Dit is typisch juridisch moeilijk doen: oh jee, straks zegt iemand dat wij een kopie maken van zijn software omdat hij die bij ons host, laten we maar even zeggen dat hij ons een licentie moet geven.

Maar belangrijker, ik zie er geen tegenspraak in met de opensourcelicentie die je op je werk plakt. Mensen moeten met de Github functionaliteit kunnen doen wat die functionaliteit doet. En met open source mag je alles: kopiëren, aan derden geven, importeren in je eigen project en ga zo maar door. Het is de distributie naar anderen toe waarop de voorwaarden geschreven zijn, en die anderen moeten dus gewoon zorgen dat ze de voorwaarden nakomen.

Dan de morele rechten: daar moet je inderdaad afstand van doen, iets dat van de Auteurswet mag (behalve het recht van verminking, maar hoe dat moet uitpakken bij software weet werkelijk niemand). Dat botst dan met licenties die naamsvermelding eisen, en dat is 99% van de opensourcelicenties. Maar ik zie ook dat niet als een probleem:

To the extent such an agreement is not enforceable by applicable law, you grant GitHub a nonexclusive, revocable, worldwide, royalty-free right to (1) use the Content without attribution strictly as necessary to render the Website and provide the Service; and (2) make reasonable adaptations of the Content as provided in this Section. We need these rights to allow basic functions like search to work.

Github wil met name voorkomen dat elke zoekopdracht moet zeggen “met code van Jan, Piet en Klaas”. Iets dat iedere rechter volkomen redelijk zal vinden. Zeker omdat je meteen wordt doorverwezen naar de resultaten, waar de naam van de programmeurs wel gewoon bij staat. Ik vraag me zelfs af of Github uberhaupt een licentie nodig heeft om zoekresultaten te mogen tonen, dat zie ik gewoon als citaatrecht.

Alles bij elkaar lijkt dit me dus een storm in een glas water, hoewel ik wel toegeef dat dit iets handiger had kunnen worden opgeschreven.

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