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

| AE 7673 | 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

Deel dit artikel

  1. Het is wel mogelijk de geschiedenis van je git repository aan te passen, dus hele repro verwijderen is niet nodig. Zoek maar eens naar gevallen waar mensen hun wachtwoorden per ongeluk online zettten via git.

    Wel is het een hels karwij, vooral als de code al wat langer in je repro zit. Vervolgens moet je je lokale repro dus over die in github zit heen kopiëren met alle risico’s van dien. Daarna hopen dat je niet ook perrongelijk werk van andere ongedaan maakt, die bijvoorbeeld synchroon met jou zitten te werken. En daarna is het nog maar de vraag of andere gebruikers die jou repro lokaal hadden staan, jou wijzigingen wel meenemen. Kan mij goed voorstellen dat iemand die lokaal de gewraakte data nog heeft, deze bij zijn volgende commit automatch weer terug plaatst.

  2. Hierop doorgaand: Stel ik heb een website met usercontent, en ik maak backups op ouderwetse tapes. Iemand post iets waar andermans auteursrechten op zitten, en maanden later wordt ik gedwongen om het weg te halen.

    Is weghalen van de huidige site (en ook weghalen van toekomstige incarnaties mocht ik mijn backups nodig hebben) voldoende, of moet ik dan ook mijn tapes gaan wijzigen (iets wat met incrementele backups nog niet zo eenvoudig is om veilig te doen)

  3. Het hangt er een beetje van af welke rol je hebt: Als hosting provider hoef je alleen die inbreukmakende zaken te verwijderen of ontoegankelijk te maken waar je van op de hoogte bent gesteld, en hoef je niet actief op zoek naar dergelijke zaken. Dus krijg je een verzoek voor het verwijderen van een auteursrechtelijk bezwaard object uit github, dan doe je dat. Als je niet op de hoogte bent gesteld van verdere instanties binnen jouw dienst (op een niet ambigue manier), dan houdt je verantwoording daar op.

    Als uitgever van een repository is dat wat lastiger. Als je je niet kunt beroepen op een uitzondering op het auteursrecht, dan zul je door je repository moeten graven, en het gewraakte werk verwijderen. Gelukkig zijn daar wat tools voor.

    Toch blijf ik het gek vinden dat er auteurs zijn die niet willen dat hun werk gelezen wordt… 🙂

  4. Het “het is veel werk” argument gaat echt niet op, het is inderdaad in git en github eenvoudig om files definitief om zeep te helpen, ook uit de archieven. Dat iemand zoiets niet dagelijks doet, en dus moet opzoeken hoe dat moet, is geen excuus. En het is maar goed ook, dat mensen zoiets niet elke dag hoeven te doen.

  5. Git heeft natuurlijk wel het “kleine” nadeel dat iedereen dan een force-pull zou moeten doen van je repository, omdat de geschiedenis herschreven is. Dus niet alleen werk voor de publiceerder, maar ook voor iedereen die ooit met de code gewerkt heeft – al was dat maar simpel binnentrekken en gebruiken zonder aanpassingen. Daar komt nog bij dat elke clone van een git repository ook weer een git repository is, dus een oude versie volledig laten verdwijnen is praktisch onmogelijk. Maar hey, er worden wel meer dingen ge-eist door de wetgeving die technisch helemaal niet kunnen. Welkom in de echte wereld 🙂

  6. Openbaarmaking: Dit verbaasd me een beetje, hoe is het materiaal verkregen? Stel ik ben Prof fotograaf en ik heb een website waar ik een aantal fotos op heb staan. Zonder betaling zijn die zichtbaar. Een bezoeker kan ze downloaden. Dat mag, zolang hij ze niet openbaar maakt. De openbaarmaking lijkt mij essentieel voor een werk wat wel auteursrechtelijk beschermd is maar kennelijk vrijelijk toegankelijk is (het idee van (de gratis versie van) github).

Laat een reactie achter

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren en <em> en <strong> voor italics en vet.

(verplicht)

Volg de reacties per RSS