Is een contributor license agreement wel gunstig voor een OSS ontwikkelaar?

Een lezer vroeg me:

Ik wilde een bijdrage doen aan een opensourceproject. De stichting erachter geeft echter aan dat ik daarvoor een contributor license agreement (CLA) moet tekenen. Dit omdat OSS licenties problematisch zijn in Europa vanwege morele rechten? Enig idee hoe dat zit? En welke nadelen haal ik me op de hals?
Een contributor license agreement of CLA is een contract waarbij een persoon die een bijdrage levert aan een OSS project, de beheerder van dat project bepaalde rechten geeft. Op zich is dat niet nodig: de bijdrage zal onder dezelfde licentie zijn als het project zelf, en de beheerder kan de bijdrage dus zo opnemen onder die licentie. Het grote nadeel daarvan is natuurlijk dat je dan mogelijk honderden auteursrechthebbenden in je project hebt.

Voor veel projecten is het een brug te ver om de auteursrechten op te eisen, wat de juridisch beste oplossing zou zijn voor het probleem. En daarom komt men met CLA’s: daar staat namelijk in dat men een onbeperkte licentie krijgt, en/of de mogelijkheid om de OSS licentie naar een andere om te zetten. Als het project dan bijvoorbeeld van BSD naar GPL wil switchen, dan is er toestemming op voorhand van alle bijdragenden.

Er is het theoretisch risico dat een bijdragende zich op hun zogeheten persoonlijkheidsrechten beroept. Dat kan in Europa (artikel 25 Auteurswet, bij ons) en dan kun je met name optreden tegen verminking van je software. Dit ongeacht je licentietekst, want je kunt van dat verzet geen afstand doen. Dan zou je dus zeggen, ook al had ik het open source gemaakt, déze specifieke aanpassing haalt mijn naam als auteur keihard door het slijk, ik ben daar fysiek misselijk van en ik eis dat het stopt.

In de praktijk wordt aangenomen dat dit bij open source eigenlijk niet kan, met name omdat het heel moeilijk voorstelbaar is wat zo’n aanpassing dan zou moeten zijn. (Enkel het werk gebruiken in een verwerpelijke context is niet genoeg, het moet echt om een aantasting van het werk gaan.) Maar goed, als men er anders in zit dan is dit een ingewikkelde discussie. “Iemand op een blog zegt van wel” is meestal geen sterk juridisch argument.

Dit geldt trouwens óók na overdracht auteursrecht (zie lid 1 zin 1 van artikel 25) dus het is geen argument om een CLA in plaats van een OSS licentie te gebruiken.

Voor de bijdragende is er weinig tot geen voordeel voor een CLA. Zelden staat er bijvoorbeeld een betalingsregeling in, of een ander voordeel zoals inspraak of medebeslissingsrecht. Het enige echte voordeel zou zijn dat als je niet tekent, je code niet in het project komt.

Arnoud

 

19 reacties

  1. Een voordeel zou kunnen zijn dat het project waar jij aan bijdraagt niet de nek wordt omgedraaid door auteursrechtproblemen.

    Persoonlijkheidsrechten zouden mogelijk omzeild kunnen worden door in de CLA een heel breed gedefinieerde lijst op te nemen voor welke toepassingen deze software allemaal gebruikt zou mogen worden en welke wijzigingen er wel niet allemaal aan gemaakt kunnen worden. Als jij dat getekend heb, dan lijkt het me lastig om achteraf te zeggen dat je wilt dat een wijziging/toepassing die onder die lijst valt, stopt.

      1. Juist dat soort extreme gevallen moet je dan dus opnemen in die lijst: “Ik verklaar dat ik het gebruik van mijn code door een project dat genocide beoogd, nooit en te nimmer zal zien als inbreuk op mijn “persoonlijkheidsrechten”, niettegenstaande het feit dat ik genocide ten sterkste veroordeel. Hetzelfde geld voor alle andere gebruiken en misbruiken, zoals het aansturen van nucleaire wapens. Dit doe ik om te voorkomen dat “persoonlijkheidsrechten” worden gebruikt of misbruikt om de open-source infrastructuur te ondermijnen.” En om te voorkomen dat eventuele erfgenamen dit negeren, kun je de rechten bij testament overdragen aan een stichting die ook achter die doelstellingen staat.

        De andere oplossing is om je bijdragen anoniem te doen, via een proxy in een land dat geen persoonlijkheidsrechten kent (de VS), maar dat levert weer andere problemen op.

        Tenslotte: Een recht waar je geen afstand van kunt doen is geen recht maar een verplichting, en kan in het ergste geval een vorm van onteigening zijn (zoals bijvoorbeeld de verplichting te dulden dat de SENA naburige rechten int, een ontneming van het recht om dat “om niet” toe te staan, dat iedere muzikant had voordat het naburige recht werd ingevoerd.) Er zijn goede redenen om sommige rechten onvervreemdbaar te maken (zodat je jezelf niet in slavernij kunt verkopen), maar bij naburige rechten is dat concept gewoon misbruikt onder het mom van “efficientie” — terwijl natuurlijk de CC-licentie nog een stuk efficienter is dan de SENA.

  2. Er zijn verschillende overeenkomsten die “CLA” worden genoemd:

    1) een verklaring dat jouw bijdrage onder dezelfde licentie als de rest van de code valt (bijv: https://www.home-assistant.io/developers/cla/ ). Het idee hierachter is volgens mij dat er in de bestaande code wel staat onder welke licentie het valt, maar niet in jou losse bijdrage, dus dan zou daar gedoe over kunnen komen. (Volgens mij is de benaming “Developer Certificate Of Origin” zoals de Linux kernel het noemt beter, maar er zijn dus projecten die dit een CLA noemen.)

    2) de mogelijkheid om de code ook onder een andere licentie aan te bieden: dan heb je dus kans dat het bedrijf erachter opeens bedenkt dat ze de volgende versies niet meer onder een open source licentie beschikbaar maken (zoals bijv MongoDB en ElasticSearch: https://www.theregister.com/2021/01/18/elasticsdoublingdownonopen/ ) Het kan natuurlijk ook gaan om een stichting die echt het beste voorheeft met het project, en bang is dat er ooit toch iets mis blijkt te zijn met de huidige licentie. Dan is het handig als je nog kunt switchen zonder dat je iedereen die ooit een bijdrage heeft geleverd om toestemming moet vragen (zoals bijv. OpenSSL https://www.openssl.org/blog/blog/2015/08/01/cla/ )

    In geval 1) is er volgens mij geen probleem, in geval 2) heb je dus kans dat jouw bijdrages opeens onder een niet open source licentie (of in elk geval een andere dan die jij wel ok vond) worden gebruikt.

    1. Om hierop in te haken, vanuit principieel oogpunt zijn er best veel partijen tegen CLAs. De Linux foundation weigert ze, net zoals de GNOME Foundation en ook de Software Freedom Conservency is er op tegen.

      In de praktijk draaien CLA’s namelijk nooit om het ‘vereenvoudigen’ van licenties. Ze bestaan er om eerlijke contributors van hun rechten te ontdoen: “Alles wat wij aan jou geven valt onder de GPL, maar alles wat jij aan ons geeft is rechten-vrij”. Buiten kantooruren zal ik dus ook altijd een CLA weigeren. Gelijke monniken gelijken kappen, of betaal me.

      1. GPL heeft 1 van de problemen opgelost door in de licentie op te nemen dat de gebruiker de keuze heeft om afgeleide code te releasen onder dezelfde of een latere versie.

        Dat lost het ‘probleem’ niet op voor bestaande projecten van voor deze clausule, zoals de Linux kernel. Maar Linus ziet dat niet als een probleem, in tegendeel, hij is geen fan van GPL v3.

  3. Als het project dan bijvoorbeeld van BSD naar GPL wil switchen, dan is er toestemming op voorhand van alle bijdragenden.
    Dat mag gewoon zonder CLA toch? Aangezien je onbeperkt BSD code mag verwerken in een GPL product, lijkt me dat je dan ook BSD software mag doorontwikkelen en uitgeven onder de voorwaarden van de GPL. Het zou me zelfs raar lijken dat het niet kan, want de BSD licentie staat je ook toe om de software closed source door te ontwikkelen en uit te geven.

      1. Het is me niet helemaal wat je bedoelt met “intrekken”? Reeds uitgegeven BSD versies van de software mag je niet meer intrekken, maar je mag de volgende release wel GPL-only maken toch? Zo lang je maar terug verwijst naar die laatste BSD release waar je je GPL versie op gebaseerd hebt. Mensen die het daar dan niet mee eens zijn moeten de laatste versie met BSD licentie dan maar forken.

        1. Inderdaad ik bedoelde de volgende release GPL-only maken. Dat kan niet als je broncode onder BSD hebt, die kun je niet relicensen maar alleen verwerken in een groter werk dat je als geheel onder GPL plaatst. Maar mensen kunnen dan de BSD stukjes eruit knippen en die onder BSD verder gebruiken. Als je dát wil verhinderen, dan kan dat alleen door de BSD codebase offline te halen en een nieuwe online te zetten waar uitsluitend GPL als licentie op staat. Maar wie de BSD codebase heeft, kan inderdaad daar een fork van blijven aanbieden.

          1. Dan begrijp ik het geloof ik niet helemaal, want wat je nu beschrijft klinkt als de copyleft van GPL, die BSD helemaal niet heeft. Bedoel je dat de code in mijn GPL project óók nog te vinden is het BSD project, en dan kan iemand die specifiek díe code wil gebruiken dat natuurlijk gewoon onder de BSD licentie doen. Maar kleine wijzigingen in het GPL project worden niet opeens BSD licentie omdat het gebaseerd is op BSD code. Ook niet als die GPL wijzigingen gemaakt zijn door iemand die oorspronkelijk niks met het BSD project te maken had.

            De BSD licentie staat mij toe om jouw BSD project te forken, aan te passen en uit te brengen zonder de broncode te delen; op deze manier is bijvoorbeeld de BSD4.4 network code ooit in Windows beland.

            Dus, closed source fork van een BSD project, al is het maar met één regel aangepast, helemaal prima – zo lang je de originele auteur maar credit (daar ging het in het Windows geval even mis geloof ik) – maar als ik die closed source fork nu zou willen open gooien onder de GPL, lijk jij opeens te zeggen dat ik het dan óók onder de BSD licentie moet uitgeven? Die stap volg ik niet; de BSD licentie is niet copyleft.

            1. Ik probeer het nog eens 🙂 Stel er is een codebase onder BSD. Ik wijzig daar een en ander aan, op creatieve wijze. Ik verkrijg dan een auteursrecht op mijn gewijzigde versie. Ik besluit op die versie de GPL te plaatsen. Dat mag, want BSD en GPL zijn compatibel.

              Jij vindt mijn gewijzigde versie, en ziet daar stukjes in die niet door mij gewijzigd zijn maar 1-op-1 gelijk aan die originele codebase. Die stukjes zijn BSD en niét GPL, ook niet als je ze uit mijn distribute haalt. Ik heb immers geen recht van sublicentie onder de BSD.

          2. Het is “not done” om alleen maar de licentietekst aan te passen in een source file. Je zult de BSD code moeten herschrijven om het GPL te maken. Of je krijgt iets als

            This source can be freely distributed under the terms of the GPL Portions (c) [naam] [BSD-style licentie]

  4. Een CLA heeft wel degelijk zin om de licentie te kunnen aanpassen, zoals OpenVPN 2.x heeft aangetoond en daardoor niet in de Appstore zit omdat de GPL-licentie niet konden aangepast. Je weet nooit of een bepaalde platform een bepaalde licentie zal vereisen in de toekomst.

    Daarnaast is het voordeel dat de auteur schriftelijk verklaard “auteur” te zijn van het geschreven stuk code en dus geen code “geleend” te hebben van derden.

    In europa zijn “moral rights” niet geharmoniseerd en zijn er veel verschillen tussen de landen. In een project waarbij auteurs van verschillende EU-landen deelnemen is het verstandig om te beperken dat er persoonlijkheidsrechten problemen optreden. Door in een CLA een ruim gebruiksrecht te vragen voorkom je dat een auteur later kan claimen dat hij het niet eens is met specifiek gebruik van zijn code.

  5. Het nadeel van een CLA is de onduidelijkheid bij faillissement. Als de auteur failliet gaat, gold onder de Nebula-leer dat de licentienemers (de gebruikers van de OSS) de software niet zonder meer konden blijven gebruiken. In het Berzona-arrest heeft de Hoge Raad die regel genuanceerd en onderscheid gemaakt tussen verbintenissen waarbij niet-nakoming een passieve handeling is (door niet te betalen, niet te leveren, enz) en waarbij dat een actieve handeling is (zoals door ontruiming te vorderen van een huurpand). In het tweede geval heeft de curator niet de bevoegdheid om zo’n actieve handeling te verrichten. De huurder blijft dus zitten en de licentienemer mag de software blijven gebruiken. Toch twee kanttekeningen:

    1. Bij OSS komen er bij veel projecten telkens nieuwe gebruikers en dus licentienemers bij. Nebula en Berzona gaan alleen over bestaande wederkerige overeenkomsten. Waarom zou je gehouden zijn nieuwe licenties te verstrekken?

    2. Het is maar de vraag of het onderscheid tussen actief en passief stand houdt: in dit artikel wordt betoogd dat je elke verplichting ook passief kunt verwoorden, zoals een betalingsverplichting die wordt geformuleerd als de verplichting om een automatische incasso te gedogen.

    1. Dat gehouden zijn nieuwe licenties te verstrekken is een lastige inderdaad. Ik denk dat je daartoe gehouden bent omdat dat in de OSS licenties staat: iedereen die een kopie van de software krijgt, krijgt van jou een eeuwigdurende licentie erbij. Dus niet sublicentie of zo. Als ik ergens nog een rondslingerende zip vind met jouw versie 1.2.1 dan heb ik jouw aanbod tot BSD licentie ook te pakken en dan aanvaard ik dat meteen.

      (Hoe ik de mededeling van aanvaarding weer bij jou krijg, en/of hoe jij je aanbod kunt intrekken voordat mijn mededeling jou bereikt, is dan weer een masterscriptie waard.)

  6. Ik zie ook wel eens gebruik van CLA’s zodat de partij achter de software in staat is om de software aan te bieden aan USA enterprise bedrijven. Die zijn vaak heel huiverig voor open source omdat ze bang zijn voor een aanklacht voor schending van auteursrecht.

    Door zo’n CLA kan de partij de software onder een andere licentie aanbieden waardoor de bedrijfsjuristen van de klant sneller blij worden.

    1. Een ander voorbeeld waarbij angst voor schending auteursrecht speelde was bij een open-source project waarbij meerdere developers betrokken waren. De software was onder BSD licentie beschikbaar gesteld. Vervolgens wilden meerdere organasities geld doneren om de software verder te ontwikkelen. Echter we konden geen entiteit vinden die “het geld wilde aannemen” en verantwoordelijk wilde zijn voor het open-source software, omdat geen enkele auteur iets getekend had en juristen bang waren dat er mogelijk third-party code onterecht hergebruikt was.

Geef een reactie

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