Juridische vraag: moet je code die auteursrechten schendt ook uit archieven verwijderen?
ICT-jurist Arnoud Engelfriet geeft elke week antwoord op een interessante vraag over beveiliging, recht en privacy. Heb jij een vraag? Stuur hem naar juridischevraag@security.nl.
Vraag: 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 de niet-programmeurs:
Als ik in de online broncode-opslag van mijn softwareproject code van elders toevoeg, en iemand klaagt dat daardoor zijn auteursrechten worden geschonden, 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?
Antwoord: 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 Engelfriet is ICT-jurist, gespecialiseerd in internetrecht waar hij zich al sinds 1993 mee bezighoudt. Hij werkt als partner bij juridisch adviesbureau ICTRecht. Zijn site Ius mentis is één van de meest uitgebreide sites van Nederland over internetrecht, techniek en intellectueel eigendom. Hij schreef twee boeken, De wet op internet en Security: Deskundig en praktisch juridisch advies.
Sterker nog, als ik in mijn repository enkel code plaats zonder enige vorm van een licentie etc. kan ik dan later claimen dat de code auteursrechtelijk beschermd is?
Jouw werk is altijd auterusrechterlijk beschermd. Dat is niet afhankelijk van de licentie. De licentie bepaald alleen wat anderen met jou (beschermd) werk mogen doen.
Peter
Sterker nog, als ik in mijn repository enkel code plaats zonder enige vorm van een licentie etc. kan ik dan later claimen dat de code auteursrechtelijk beschermd is?
Allereerst: ook open source werk is altijd auteursrechterlijk beschermd! Dat is een andere vraag onder welke licentie het beschikbaar wordt gesteld. Als de auteur geen nadere licentie specificeert, dan geeft anderen dus geen recht (geen licentie) om het te herpubliceren of te bewerken.
Alle open source licenties die ik ken hebben geen tijds-gebonden bepaling. Als gebruiker kan de code die destijds open source was dus gewoon blijven herpubliceren. De auteur kan dat niet voorkomen. Als auteur er later voor kiest om de code niet meer te publiceren, dan mag dat. Dat veranderd niets aan de destijds afgegeven licenties. Als de open source licentie van destijds geen tijdsgebonden bepaling had, mag iemand anders gewoon doorgaan met herpubliceren (en wellicht bewerken).
De auteur mag er voor kiezen om eventuele wijzigingen die hij later aan de code doet niet meer onder een open-source licentie te verspreiden. In dat geval mag iemand anders die wijzigingen natuurlijk niet herpubliceren (maar zal de andere genoegen moeten nemen met voortborduren op een oude versie). Merk op dat een auteur dit zelfs mag als hij een 'free software' licentie kiest (zoals GNU GPL), die eist dat latere bewerkingen ook onder GPL gepubliceerd worden: de auteur, als rechthebbende/eigenaar, mag als enige besluiten om de code alsnog onder een tweede (minder open) licentie uit te brengen (een soort dual-license), en hoeft dus niet aan de GPL te voldoen. Anderen hebben dat recht niet. Ze zijn immers geen eigenaar, maar alleen gelicenceerden.
Even doordenken en je komt op een interessante vraag: Stel, je hebt een repository waarin onder andere code van A die zegt "alles van mij eruit, want schending van mijn rechten", maar ook van B onder licentie die zegt dat alle code (van B en alles wat erbij hoort) gepubliceerd moet worden, dus het geheel "onpubliceren" zou schending van de licentie van B veroorzaken.
Dan zou aan de eisen van A voldoen schending van B zijn rechten betekenen. Zijn hier provisies voor?
Lijkt me dat je ten eerste heel goed moet uitkijken wat voor code je toevoegt. Ten tweede zou het wel handig zijn als je het historisch archief kan aanpassen met een notitie "hier is censuur gepleegd" zonder dat je het geheel moet wegmaken. Aan de andere kant, dat soort revisionisme is wellicht ook weer niet helemaal de bedoeling en is het wellicht (alweer) een reden om eens naar het auteursrecht te kijken, en of het nog wel doet wat het moet doen en of de bijkomstige effecten niet meer schade kosten dan het geheel aan positiefs oplevert. Want dit soort constructen zijn vrij snel als wapen in te zetten en dat is wellicht toch net niet de bedoeling.
Dan zou aan de eisen van A voldoen schending van B zijn rechten betekenen. Zijn hier provisies voor?
Mij lijkt dit gewoon een kwestie van je repository goed doorzoeken en alles van A verwijderen en alles van B laten staan. Misschien handiger is om een nieuwe repository te maken met alleen B en de oude repository volledig verwijderen. Dan loop je ook niet het risico dat je per ongeluk stukken A laat staan of stukken B verwijdert.
Peter
Nee.
Het is mogelijk om selectief iets te verwijderen: https://help.github.com/articles/remove-sensitive-data/
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
