Nu ga ik aan mezelf twijfelen, is de GPLv2 eigenlijk wel een contract?

Heibel in de Linuxtent, blogde ik vorige week. Ontwikkelaars aan het besturingssysteem lagen in de clinch over een Code of Conduct die ongepast gedrag vastlegt, met de nodige interpretatieproblemen tot gevolg. Dat leidde tot een oproep om je GPL-licentie in te trekken en zo je stem te laten horen. Waarop ik me afvroeg, kan dat wel, een contract opzeggen in zo’n situatie? Maar nu ga ik zelfs twijfelen of er wel een contract ís.

Dat de GPL naar Europees recht een contract is, is al een hele lange aanname. De standaardlicentie komt uit de VS, en daar is de twijfel wel iets serieuzer: voor een overeenkomst is onder de common law het specifieke concept ‘consideration’ nodig, oftewel een tegenprestatie. Een schenking is dus géén overeenkomst daar, maar een eenzijdige rechtshandeling. In Europa waar de civil law geldt (zeg maar heel Europa behalve Ierland, Engeland en Wales) is het goed mogelijk een overeenkomst te hebben met maar één prestatie.

De GPL kent geen tegenprestatie, en kan daarmee dus geen contract zijn onder common law principes. In Europa is dat geen beletsel, dus kun je hier prima spreken van een GPL contract. (Bijkomstig voordeel is dat het Amerikaanse juristen irriteert zonder dat ze er wat aan kunnen doen.) Voor een contract is niet meer nodig dan een aanbod (dit mag je doen, onder deze voorwaarden) dat wordt aanvaard (lijkt me leuk, ik ga typen en verspreiden).

Hoe meer ik er echter over nadenk, hoe meer ik twijfel of dit eigenlijk wel goed gaat. Want die aanvaarding past niet goed in het systeem van de wet, dat er vanuit gaat dat je akkoord zegt tegen de aanbiedende partij. Als die aanvaarding niet daadwerkelijk aankomt, dan gaat er van alles schuiven. Het belangrijkste is dat de aanbieder dan het aanbod mag intrekken, waarmee het vervalt. Oftewel, zolang niemand jou daadwerkelijk meldt “ik aanvaard de GPL op jouw software, dank je” dan kun je gewoon roepen “licentieaanbod ingetrokken, sorry” en kan niemand meer wat met je software.

De praktijk is natuurlijk dat iedereen gewoon zoekt naar de regel “GPL” in de hoofddirectory van de software en concludeert dat het wel goed zit. Maar je moet je best wel in juridische bochten wringen om dan tot een juridisch perfecte aanvaarding te komen. Een mogelijkheid is bijvoorbeeld dat je zegt, de aanvaardingshandeling (het gebruik van de software) bereikt de aanbieder niet maar dat is de aanbieder zijn eigen probleem (art. 3:37 lid 3 BW), had hij maar meer moeten opletten wie zijn software gebruikt.

Maar wat is het dan wel? De Amerikaanse constructie is een “toestemming onder voorwaarden”, analoog aan een bordje bij je erfgrens. Wie zijn landgoed openstelt met een bordje “Vrije toegang dagelijks tussen zonsopgang en zonsondergang” sluit dan geen overeenkomst, maar verleent eenzijdig toestemming onder een voorwaarde (namelijk dat het overdag is). Zolang die voorwaarde wordt gerespecteerd, mag je er zijn. Schend je de voorwaarde of vervalt deze, dan pleeg je erfvredebreuk en moet je dus wegwezen. Vertaal je dat naar softwareland, dan krijg je toestemming onder het auteursrecht om te handelen maar zodra je de voorwaarden schendt, eindigt de toestemming en heb je een probleem.

Het mooie van deze oplossing is, het maakt niet uit of je de voorwaarden aanvaardt of niet. Negeer ze en je pleegt sowieso inbreuk. Dus je hoeft helemaal niets te zeggen tegen de rechthebbende. De toestemming is ook niet zomaar intrekbaar: gezegd is gezegd, zeker gezien de constructie in de aanhef van de GPL dat het krijgen van een kopie van de software tevens toestemming inhoudt.

Het grote nadeel is natuurlijk, het is nog nooit getest bij de rechter. En ik weet ook niet op welke plek in het Burgerlijk Wetboek ik deze constructie zou moeten duiden. Maar het past beter bij mijn rechtsgevoel anno 2018.

Arnoud

48 reacties

  1. Full disclaimer: Ik zit niet in open-source projecten en heb geen enkele ervaring met de GPL of iets dergelijks.

    Mijn vraag: Als iedereen denkt dat de GPL op een bepaalde manier werkt en op een bepaalde manier gebruikt, is dat dan niet hoe het werkt? Het gaat er in het recht nogal eens om dat je “had mogen verwachten” en dergelijke. Als je dan de GPL op je code gooit, en een ander gebruikt het, en jij trekt hem in, mag die andere partij dan niet zeggen “Ik had mogen verwachten dat die licentie gold en dat ik de code daarom mocht hergebruiken, zonder herroeping”, of zoiets? Het maakt dan niet zoveel uit hoe de GPL echt werkt.

    Ik denk dan een beetje zoiets als advertenties als “BTW, weg ermee!” Je weet dat je de BTW gewoon betaalt. Dat is nu eenmaal de wet. Het betekent gewoon ~19% korting. Het wordt dan een soort regel terwijl de verkeerde terminologie wordt gebruikt.

    1. /muggenzift mode: 21/121 = 17,36%

      Maar zo lijkt het me niet echt te werken in de juridische wereld. Je kan wel stellen dat als iets loopt, kwaakt, vliegt en ruikt als een eend, het waarschijnlijk wel een eend zal zijn, maar uiteindelijk wordt er zeker in de juridische werled toch erg naar de letter gelezen.

      Nu moet ik zeggen dat het idee van “toestemming geven onder voorwaarden” me wel aanstaat. Als je vervolgens in je toestemming opneemt dat deze toestemming kan veranderen, kan je ongewenste effecten er op een later tijdstip nog uitfilteren door je voorwaarden aan te passen.

    2. Veel hangt af van bij welke rechter een zaak terecht komt en aan de hand van welk recht de GPL beoordeeld wordt. Zoals al opgemerkt door Arnoud behoren de VS tot de zogenaamde ‘common law’ wereld waar over het algemeen veel strikter naar de letter van een contract wordt gekeken en veel minder naar de partijbedoeling dan alhier.

      1. Heb het even op gezocht (ben binnenkort toch in Schotland). De ‘Copyright, Designs and Patents Act 1988’ geldt voor het gehele Verenigd Koninkrijk dus inclusief Schotland en Noord-Ierland. Schotland en Noord-Ierland hebben daarnaast wel hun eigen common law en ook hun eigen contractenrecht lijkt het dus dat zou voor wat betreft het ‘license or contract’ gedeelte (puur juridisch) in ieder geval inderdaad wel degelijk uit kunnen maken. Wat betreft de praktijk geen idee.

  2. Arnoud, de GPL heeft toch wel een tegenprestatie, te weten dat als je andermans GPL-gelicentieerde software verspreid, je je eventuele eigen IP op die software niet zult gebruiken tegen die software, en als je in je verspreiding andere software linkt met GPL-geliecntieerde software, ook die andere software onder de GPL zult laten vallen zodat er daardoor meer software onder de GPL gaat vallen waardoor ook de auteur van de GPL-gelicentieerde software verrijkt wordt. Ik zou dus niet willen zeggen dat er geen tegenprestatie (consideration) is. Voor NL recht lijkt me m.n. Art. 3:37(1) BW relevant: een verklaring kan gevormd worden door gedragingen, zoals het gebruiken en/of verspreiden van GPL-gelicentieerde software terwijl je weet dat je zonder licentie die software niet mag gebruiken en/of verspreiden.

      1. Dus als in een GPL project alle auteurs hun email adres zetten onderin het doucment met de GPL voorwaarde, dan is het wel goed? Het is dan de taak aan bijvoorbeeld de fabrikant van een machine om alle duizenden mensen te emaillen om te zeggen dat hij akkoord gaat met de GPL voorwaarde voor het gebruik van een Linux kernel in zijn machine.

        En zou het zitten als ik software schrijf waarin ik gebruik maak van GPL code (zonder acceptatie van de voorwaarde te melden aan de originele auteurs) en deze software dan weer onder GPL verspreid. Stel de auteur van wie ik de GPL code heb gebruikt trekt deze in, dan moet ik mijn software weer terugtrekken, ik heb immers geen licentie meer. Maar hoe doe ik dat als iemand mijn GPL heeft geaccepteerd, ik ga ervan uit dat in GPL geen ontbindingsvoorwaarde staan.

      2. Maar art. 5 GPLv2 zegt zelf:

        Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it.
        Als je als licentiegever zelf precies aangeeft hoe aanvaarding plaats moet vinden, en wel op een hele impliciete manier, dan lijkt het me dat je niet gemakkelijk kunt aankomen met ‘de aanvaarding heeft me niet bereikt’. De licentiegever vindt dat blijkbaar niet nodig.

          1. Volgens mij niet. De aanvaarding kan in beginsel in ieder vorm geschieden. Het aanbod kan een bepaalde vorm voorschrijven. (3:37 BW). In casu vindt de aanvaarding plaats op de door de licentiegever voorgeschreven manier zoals weergegeven in art. 5 GPL v2.

  3. Er zijn heeft veel eenzijdige toestemmingen onder voorwaarden actief in ICT land. Zo geldt er een eeuwigdurende licentie voor gebruik van alle Office formaten van Microsoft https://msdn.microsoft.com/en-us/openspecifications/dn646765.aspx Idem voor het VP8 videoformaten van Google bijvoorbeeld: https://www.webmproject.org/license/bitstream/ en zo kennen heel veel IT bedrijven eenzijdige beloftes om hun IP rechten op bijvoorbeeld bestandsformaten of API’s te verstekken aan iedereen onder de voorwaarde dat die partijen niet hen aanklagen voor IP rechten op die bestandsformaten/API’s.

      1. Het betreft dan over het algemeen ook patent en auteursrechten op formaten of API’s. De licenties worden via deze eenzijdige bijvoorbeeld alleen verstrekt op het gebruik van de patenten voor het implementeren van de formaten. Je kan op basis van de gegeven belofte bijvoorbeeld onbeperkt Google patenten gebruiken om een VP8 encoder/decoder of analyzer te maken maar je mag obv van deze licentie niet dezelfde patenten gebruiken om je eigen formaat de encoden/decoden/analiseren.

  4. Ik denk dat het aanbieden van software onder de GPL in Nederland als rechtsverwerking valt te kwalificeren. Je geeft aan je auteursrecht niet te handhaven als het gebruik van je software aan bepaalde voorwaarden voldoet. Eenmaal verwerkte rechten kun je niet opnieuw verwerven.

  5. Even in het kort: de GPL is wel degelijk een contract waar twee prestaties aan verbonden zijn. Dat komt omdat de gebruiker van GPL code vervolgens de eigen code moet vrijgeven indien ze hun project (op basis van GPL code) gaan verspreiden. Dus als jij een IusMentis-app maakt voor je blog voor op de iPhone en Android en je gebruikt daarbij GPL code dan moet je ook jouw code voor die app delen met de rest.

    En dat is de tegenprestatie! Maar zolang je niet je eigen product publiceert is alles voor eigen gebruik en is er dus (nog) geen contract. Dus leef je uit met GPL code! Zeker als je een GPL product als WordPress gebruikt dan kun je er van alles mee doen wat je wilt en draaien op je webserver zolang je jouw versie maar niet deelt met anderen zonder jouw code vrij te geven… 😉

    Toch? 😉

  6. Er moet nog wel even rekening gehouden worden met art. 45h t/m 45n Aw en dan met name met art. 45j Aw. De auteur die zelf het werk ter download heeft aangeboden of daarvoor toestemming gegeven, kan geen voorwaarden verbinden aan verveelvoudigingen die noodzakelijk zijn voor het met dat werk beoogde gebruik.

          1. De GPLv2 stelt toch ook voorwaarden aan verveelvouding in ongewijzigde vorm (als onderdeel van een groter werk). Dan zijn die artikel die aangeven dat je daarbij geen voorwaarden kan stellen toch op dat punt in strijd met de GPL

            1. Als jij een werk waarop de GPLv2 van toepassing is ongewijzigd tot onderdeel van een ander groter werk maakt is dat geen probleem. Ga je dat grotere werk (inc. GPLv2 code) openbaar maken en/of verspreiden (dus niet slechts verveelvoudigen) dan treden er verpichtingen van de GPL2 in werking (GPL bijvoegen, broncode openbaar, etc.). Zoals Arnoud al zei voorziet de Auteurswet niet in een wettelijke grond voor openbaarmaking dus je kunt niet op basis daarvan die verplichtingen omzeilen.

                1. Copy/Paste van een of andere website die ik verder niet wil noemen want een concurrent van Arnoud. (Maar ik link wel even naar hen!)

                  Openbaar maken<\p>

                  Bij openbaar maken gaat het om het beschikbaar stellen van het werk of van een verveelvoudiging ervan aan het publiek. Het gaat er dus om dat anderen het werk kunnen waarnemen.

                  Verveelvoudigen

                  Verveelvoudigen is allereerst het maken van identieke exemplaren van een werk (bijvoorbeeld een boek, cd, schilderij of foto), ook wel vermenigvuldigen genoemd. Dat kan o.a. door reproduceren, overschrijven, natekenen, (foto)kopiëren, afdrukken, branden, het maken van afgietsels, het opslaan in databanken en het op de harde schijf van de computer zetten. Als jij een artikel uit een tijdschrift publiceert op het Internet dan geef je dat bericht dus een nieuw publiek en dan is dat een openbaarmaking. (en een verveelvoudiging!) Als je dat artikel van een andere website had gekopieerd dan was het alleen een verveelvoudiging, mits het oorspronkelijke artikel voor iedereen op het Internet beschikbaar is.

                  1. [quote]Als jij een artikel uit een tijdschrift publiceert op het Internet dan geef je dat bericht dus een nieuw publiek en dan is dat een openbaarmaking. (en een verveelvoudiging!) [/blockquote]Maar als er sprake is van zowel een openbaarmaking als ook ene verveelvoudiging kan een licentie dan een voorwaarde stellen aan de openbaarmaking als de wet stelt dat er geen voorwaarde mag zitten aan de verveelvoudiging.

                    1. In het geval van software geldt de zogenaamde wettelijke licentie van art. 45j Auteurswet. Grof gezegd houdt dat in dat jij als rechtmatige verkrijger van software niet belet kan worden door de auteur om die software te verveelvoudigen als dat nodig is voor het ‘beoogde gebruik’, bijvoorbeeld als dat gebeurt in het kader van het ‘runnen’ van de software of het in beeld brengen met jouw computer. Daar zal echter mijns inziens nooit het verspreiden van software onder vallen.

                2. Jazeker is dat een openbaarmaking, in de zin van de auteurswet dan. Een openbaarmaking van een verveelvoudiging. Ik begrijp nu de verwarring. Het auteursrecht houdt in dat je voor de openbaarmaking en verveelvoudiging van een werk de toestemming van de auteur nodig hebt. Bij openbaar maken gaat het om het toegankelijk maken voor het publiek. Iedereen die dat wil doen heeft daar (iedere keer weer) de toestemming van de auteur voor nodig. Dus als The Economist jouw artikel wil publiceren hebben ze daarvoor jouw toestemming nodig. Als Time dat vervolgens ook wil doen hebben ook zij daar weer jouw toestemming voor nodig enzovoorts. Daarbij maakt het geen verschil dat iemand anders het artikel al eerder heeft openbaar gemaakt.

  7. Grappig: SQLite voegt nieuwe Code of Conduct toe gebaseerd op de Regula Benedicti.

    Having been encouraged by clients to adopt a written code of conduct, the SQLite developers elected to govern their interactions with each other, with their clients, and with the larger SQLite user community in accordance with the “instruments of good works” from chapter 4 of The Rule of St. Benedict. This code of conduct has proven its mettle in thousands of diverse communities for over 1,500 years, and has served as a baseline for many civil law codes since the time of Charlemagne.

    https://www.sqlite.org/codeofconduct.html

      1. Omdat softwareontwikkelaars meer dan andere mensen behoefte hebben aan duidelijke harde regels, en niet tegen vaagheid kunnen. Is een beroepsdeformatie die ik ook heb en waar je maar moeilijk overheen komt. “Doe normaal” zou eigenlijk meer dan genoeg moeten zijn, maar daar kom je niet mee weg bij je werk (“de software moet gewoon mooi zijn en goed werken, hoe moeilijk is dat”) dus ook niet in je Code of Conduct.

        1. Het was half serieus maar ik vind het toch bruikbaarder dan die Regula Benedicti met zijn 72 geboden. En bij ‘doe normaal’ heb je weer het probleem van wat ‘normaal’ is. (Normaal voor jou? Normaal voor mij?) De gulden regel is voor wat betreft communicatie en gedrag praktisch behoorlijk goed toepasbaar IMHO.

          1. Tegenvoorbeeld: menig dikke neckbeard heeft er nul bezwaar tegen dat naaktfoto’s van hem op internet komen (wie wil dat immers nou zien) dus daarom is iedere jongedame vogelvrij als er ergens een naaktfoto van haar te kapen is. Zie TheFappening.

            1. Weet niet of dat waar is maar los daarvan: we hebben het hier over een code of conduct voor een open source software project dus dan lijkt me dat niet echt een realistische casus. Daarnaast zou je kunnen zeggen: als jij dingen hebt waarvan je niet wilt dat dat zonder jouw toestemming gebeurt (jouw foto’s ongevraagd publiceren, of je portemonnee ongevraagd meenemen), zorg dan dat dat ook niet bij iemand anders gebeurt. Ik begrijp ook wel dat we het hier niet mee redden en nog steeds een wetboek van strafrecht nodig hebben maar ik vind dit als ethische richtlijn / code of conduct zo gek nog niet.

        2. Een leuke discussie maar er is een belangrijke eigenschap bij veel ICT’ers die bij normale mensen veelal ontbreekt: het gemiddelde aantal ICT’ers met een (milde) vorm van autisme is veelal hoger dan bij andere beroepsgroepen. Onder autisten is een baan binnen de ICT erg populair omdat je dan meer met apparaten bezig bent en minder met mensen. Minder emotioneel, dus.

          Dus als je zegt “Doe normaal” dan heeft dat al snel een andere betekenis voor ICT’ers dan voor andere personen. Je moet dan ook duidelijker formuleren wat “normaal” is.

    1. Ondertussen is deze Code of Conduct hernoemd naar Code of Ethics, met als doel meer inzicht te verschaffen in het project en de ethische overwegingen van de oprichters. De officiële Code of Conduct, die dus van toepassing is op eventuele contributors, is veranderd naar de Mozilla Community Participation Guidelines.

      Ik heb nog steeds mijn twijfels over het nut van Codes of Conduct. Volgens mij mag ik (onder de GPL licentie) nog steeds code aanpassen en publiceren, ook al hou ik me niet aan de CoC. De vraag is of een projectmedewerker die wel gebonden is aan de CoC nu mijn code mag toevoegen aan het project, al dan niet wetende dat ik een moordenaar ben (ben ik niet hoor).

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.