Tag: github

About github

Subscribe Feeds

Microsoft en Github aangeklaagd voor opensourceschending door AI tool

Geplaatst op in 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?

Geplaatst op in 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

Geplaatst op in 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?

Geplaatst op in 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?

Geplaatst op in Intellectuele rechten, Ondernemingsvrijheid, 5 reacties

github-octocatDiverse 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 te verspreiden is. Het is mogelijk hier allerlei extensies of scripts bij te ontwikkelen, en waar Docker zich dus tegen verzet is wanneer mensen zo’n eigen werk een naam geven die begint met docker. Zij zien dit als verwarringwekkend: mensen kunnen denken dat Docker, Inc. zelf deze projecten beheert of ze heeft goedgekeurd of gesponsord.

Het doet vagelijk denken aan dit geval uit maart waar een discussie over de merknaam 'Kik' zelfs lijdde tot een tijdelijk stukgaan van het internet. Maar daar ging het over het bezet houden van een naam (kik) door één van meerdere merkhouders. Hier gaat het over aanvullingen: docker-existdb bijvoorbeeld, een script waarmee je bij het bouwen van een container makkelijk verbinding kunt leggen met een database van eXist.

Is het nu verwarrend, docker-x als je wilt zeggen, een X voor/met Docker? Ik zou zeggen van niet. Het is toegestaan onder de merkenwet om te refereren naar een merkproduct, met name om aan te geven dat je daarmee compatibel bent of dat jouw product daarvoor bestemd is. "Hoesje voor Samsung Galaxy S" is dus legaal om te zeggen.

Daar staat tegenover dat je ook merkinbreuk pleegt door te onduidelijk te zijn over wie je wél bent. "Hoesje-voor-samsung-galaxy-s.nl" als webshop die zegt "Welkom, koop snel het mooiste hoesje voor uw Samsung Galaxy S" zou merkinbreuk zijn, omdat het hier (door stilzwijgen) lijkt alsof deze site van Samsung zelf is. Je moet dus als merkenverkoper expliciet en groot duidelijk maken wie je wél bent.

Bij Github-projecten wordt altijd vermeld wie de beheerder is van een project. De ontwikkelaar uit het artikel onderhoudt bijvoorbeeld zijn repositories op Github onder de naam 'zopyx', en dat kun je prima zien bij zijn projecten. Ik denk niet dat iemand hier uit zou halen dat dit een project van Docker is. Die zien er zo uit. Plus, in de opensourcegemeenschap dóe je dat nu eenmaal zo, de naam van het origineel combineren met wat jouw project daaraan toevoegt.

Maar toegegeven, deze informatiepresentatie is wel érg zakelijk en strak. De grootste en duidelijkste termen zijn de naam van het project. Als daar dan 'docker' in staat, dan zou je wellicht kunnen zeggen dat je daarmee de nadruk legt op Docker en zo dus stilzwijgend de indruk wekt dat dit project van Docker afkomstig is.

Wat vinden jullie? Overdreven zorg, of zou Docker legitiem kunnen vrezen dat mensen die onafhankelijke projecten aanzien voor die van hen?

Arnoud

Mag GHTorrent openbare data van Github aggregeren als onderzoeksdataset?

Geplaatst op in Intellectuele rechten, Privacy, 25 reacties

ghtorrent-data-structureMag 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 platforms voor gedistribueerde softwareontwikkeling, met name voor open source. De activiteit op het platform maakt het ook interessant voor wetenschappelijk onderzoek naar gedrag en handelen bij softwareontwikkeling. Zo las ik dat bijdragen van vrouwen eerder opgenomen worden in softwareprojecten dan die van mannen.

Dit onderzoeken betekent dat je honderdduizenden projecten moet doorlopen, iets dat handmatig vrijwel onmogelijk is. Vandaar GHTorrent: plat gezegd een offline mirror van alle Github metadata, zodat je niet per onderzoeksvraag de hele site af hoeft te struinen.

Niet iedereen is daar blij mee. Met name niet omdat ook het e-mailadres van ontwikkelaars opgenomen is. Je kunt dat e-mailadres dan als identifier gebruiken (het man/vrouw onderzoek werkte zo: via het e-mailadres kon je het Google+ profiel vinden en daar het geslacht van de ontwikkelaar achterhalen). En je kunt er natuurlijk ook mail heen sturen, waar de klachten over begonnen. Continu vragen krijgen om mee te doen aan allerlei onderzoek is niet prettig.

De data is publiek. E-mailadressen zijn gewoon zichtbaar, dus iedereen die wil kan dezelfde dataset verkrijgen als GHTorrent. Is het dan slechts een kwestie van fatsoen dat je toch mailadressen blokkeert of van antispam-maatregelen voorziet? Nou, niet per se. In Europa – waar het project vandaan komt – gelden strenge privacyregels ten aanzien van persoonsgegevens, en die gelden ook als de gegevens uit openbare bron zijn verkregen.

Een e-mailadres is een persoonsgegeven onder de Europese regels, omdat het naar een persoon (de ontwikkelaar) te herleiden is. Wie dergelijke gegevens bij elkaar brengt en ontsluit, is daar verantwoordelijk voor. Deze verantwoordelijke moet een grondslag in de wet hebben om dit te mogen doen, en moet zich houden aan de informatieplichten en het recht van inzage, correctie en verwijdering dat alle betrokken personen hebben.

Ook als de data publiek is. Dat ondervond Google in 2014 met het vergeetrecht-arrest: hoewel Google-zoekresultaten afgeleid zijn van openbare bronnen, heeft Google een eigen verantwoordelijkheid bij hoe zij die resultaten rangschikt en presenteert. Zij is dus zelf onderworpen aan het vergeetrecht (en de andere wettelijke plichten voor verantwoordelijken), los van de bronnen waar zij zich op baseert.

Hetzelfde geldt voor GHTorrent. Zij brengt openbare data bij elkaar, maar die data bevat persoonsgegevens. En daarom is de beheerder van GHTorrent de verantwoordelijke en verplicht om te informeren en om correctie en verwijdering toe te staan.

Verwijdering hoeft echter niet altijd. De vraag is of de data irrelevant is voor het doel waarvoor deze is verzameld. In het geval van Google: wanneer de zoekresultaten achterhaald of anderszins niet meer relevant zijn voor de persoon op wie je zocht, bij een zoekopdracht naar een persoon. Bij GHTorrent geldt hetzelfde, maar dat vertaalt zich lastiger naar de praktijk. Immers, ook oude gegevens van een ontwikkelaar zijn relevant voor wetenschappelijk onderzoek, dus het Google-criterium gaat hier niet op. Welk criterium dan wel, dat weet ik zo even niet.

Maar misschien is er een simpeler oplossing. Er moet immers sowieso een wettelijke grondslag zijn voor je gebruik van de gegevens. Enkel “ze komen uit openbare bron” is niet genoeg als grondslag, net zo min als “wij doen wetenschappelijk onderzoek”. Toestemming is er niet, een contract met GHTorrent ook niet, dus dan val je terug op de eigen dringende noodzaak: er is een legitiem belang (wetenschappelijk onderzoek), de gegevens zijn daar écht voor nodig (die zie ik wel) en alles is in het werk gezet om de privacy zo veel mogelijk te beschermen.

En bij dat laatste gaat het mis, want in principe is dan een opt-out vereist. Niet perse, andere maatregelen mogen ook. Zo kun je bijvoorbeeld de e-mailadressen hashen, zodat je er wel op kunt matchen maar ze niet kunt gebruiken om te mailen. Of je laat ze weg uit de publieke dataset en verstrekt ze alleen als mensen apart akkoord gaan met geheimhouding van die set. Maar opt-out lijkt mij het makkelijkste.

GHTorrent lijkt me dus legaal, maar ze moeten zich wel houden aan de Europese regels over persoonsgegevens. En in de praktijk betekent dat dus wel degelijk dat er een opt-out moet zijn.

Arnoud

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

Geplaatst op in Intellectuele rechten, 15 reacties

notice-takedownEen 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 de niet-programmeurs:

Als ik in de online broncode-opslag van mijn softwareproject code van elders toevoeg, en iemand klaagt dat daardoor zijn auteursrechten door geschonden worden, is het dan genoeg om deze code te wissen uit de meest recente versie van mijn project, of moet ik deze ook uit het archief met oude versies wissen?

Wanneer je een kopie van andermans software publiceert of verspreidt, is het mogelijk dat je daardoor auteursrechten schendt. Dit staat los van de techniek die je gebruikt, via een flitsende GitHub repository of heel ouderwets op een FTP server of website. Krijg je een klacht van de rechthebbende, dan zul je maatregelen moeten nemen en eentje daarvan is het staken van de inbreuk.

Bij zo’n ouderwetsche website is dat eenvoudig: weg is weg. Maar GitHub is een veel moderner en handiger systeem, en heeft onder meer een uitgebreid archief waarin je alle oude versies en varianten van de software kunt opvragen. Dan kun je het dus wel uit de huidige versie van de software halen, maar zit er nog steeds een kopie in dat archief.

En ja, ook die moet weg want ook een kopie in een archief telt als “verveelvoudiging” en als die in strijd is met auteursrechten dan moet er worden ingegrepen. Het argument dat het een historisch document is, of dat het veel werk is om die oude kopie op te ruimen, is niet relevant. Het had er nooit mogen staan, dus bij deze moet het alsnog weg.

Arnoud