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

| AE 10903 | Intellectuele rechten | 48 reacties

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

Mag je licentie-incompatibele dependencies meeleveren met je software?

| AE 9144 | Intellectuele rechten | 34 reacties

Een lezer vroeg me:

Bij veel opensourcepakketten heb je allerlei extra software nodig, zogeheten dependencies. Soms is deze extra software meegeleverd met het pakket, maar vaak niet. Je moet dan maar hopen dat het via de repository van je Linux-distributie beschikbaar is. Ik had vernomen dat dat soms een juridische keuze is, hoe zit dat?

Het lijkt zo logisch om, als je eigen software afhankelijk is van andermans open source, die open source mee te leveren. Het is immers gewoon toegestaan om open source software te verspreiden, dat is het hele punt van open source. Het doet dus wat raar aan dat je bepaalde open source niet mee mag leveren.

De reden dat het soms toch niet kan, zit hem in de licentievoorwaarden. Sommige opensourcelicenties (met name de GNU GPL) eisen dat zogeheten afgeleide werken alleen mogen worden gedistribueerd onder die licentie. Als de licentie van het andere werk dit niet toestaat – zogeheten licentie-incompatibiliteit – dan is het dus niet mogelijk die twee samen te verspreiden.

Wat precies een afgeleid werk is, is al decennia een lange discussie, maar goed verdedigbaar is dat gebruik van een dependency daaronder valt. Heb je een specifiek ander stuk software nodig, dan bouw je voort op dat andere stuk software en dus ben je daar een afgeleide van. Hoewel ook goed verdedigbaar is dat je dan alleen functionaliteit aanroept, en dat valt buiten het auteursrecht en dus ook buiten de licentiescope. Maar als je dus zegt dat inroepen van dependencies jouw software een afgeleid werk daarvan maakt, dan moeten de licenties van de software en de dependencies allemaal compatibel met elkaar zijn.

Het gekke is dat het wél toegestaan is – ongeacht compatibiliteit – om te melden welke dependencies er gelden en de gebruiker die zelf te laten downloaden en installeren. Dat mag je zelfs automatiseren met een handig installatiescript of package manager-functionaliteit. Opensourcelicenties zijn namelijk distributielicenties, oftewel de voorwaarden gelden pas bij distributie. Wie alleen downloadt en gebruikt, heeft dus niets te maken met compatibiliteit van eventuele licenties.

Arnoud

Wat is beter voor open source: rechtszaken of praten?

| AE 8911 | Intellectuele rechten | 16 reacties

gpl-sans-plombeOh oh, Linus Torvalds in de bocht in een discussie bij de Linuxfoundation over GPL handhaving. Dan weet je het wel. De stelling was: “we can all decide to give up on the GPL, or we can enforce it in Courts.” Torvalds, zeer karakteristiek: “this arguing for lawyering has become a nasty festering disease, and the SFC and Bradley Kuhn has been the Typhoid Mary spreading the disease.” De juristerij als builenpest, oké dan. Heeft hij een bult, eh punt?

Handhaving van de GPL bij de rechter komt zelden voor. Afgezien van een paar simpele kortgedingzaken in Duitsland is er niemand die daarover echt procedeert. Daardoor ontstaat er enige onzekerheid in de markt: hoe ver gaat die GPL nou, wat mag er wel of niet. Maar het omgekeerde komt ook voor: geen rechtszaken, dan geloof ik het wel en ga ik gewoon doen wat ik wil totdat ze piepen.

Dat piepen, dat gebeurt regelmatig. De Linux-mensen, maar ook vele anderen, steken een hoop energie in het aanspreken van bedrijven en instellingen die de GPL niet netjes naleven. Informeel en achter de schermen, joh er gaat iets niet helemaal lekker, mag ik je een tip geven? En vrijwel altijd heeft dat effect, zij het dat het enige tijd kan duren. (Ik spreek uit persoonlijke ervaring vanaf de ‘andere kant’ van die tips.)

Zie je een overtreding van de GPL op jouw code, dan kún je natuurlijk ook een blafbrief sturen en daarna naar de rechter. Dat heeft nog niemand gedaan, mogelijk vanwege de kosten en het gedoe. Ook de onbekende status van de GPL speelt een rol – ga je wel winnen, zegt de rechter niet bijvoorbeeld iets doms straks over afgeleide werken waarmee de GPL tandeloos zou worden.

Torvalds:

But quite apart from the risk of loss in a court, there real risk is something that happens whether you win or lose, and in fact whether you go to court or just threaten: the loss of community, and in particular exactly the kind of community that can (and does) help. You lose your friends.

En dat is natuurlijk waar. Als je iemand aanklaagt, verstoor je de relatie. Want welk bedrijf je ook dagvaardt, de reactie zal eigenlijk altijd hetzelfde zijn: de luiken gaan dicht, een externe advocaat doet de correspondentie en alle banden met het OSS-project in kwestie gaan de ijskast in want alles kan tegen je worden gebruikt. Van zo’n klap herstel je niet makkelijk. En als je dat als community doet, loop je ook de kans dat ánderen gaan denken, die club daar moeten we van wegblijven want die klagen je aan, raar spul dat open source. Dus het is zeker niet gezegd dat het een goede move is.

Natuurlijk, het gevolg van de Linus-aanpak is wel dat sommige gebruikers wegkomen met licentieschendingen. Dat voelt oneerlijk; doe jij veel moeite netjes compliant te zijn, gaat je buurman je de pas afsnijden met in feite gejatte code. En dan zegt die Torvalds “heb geduld, we spreken ze nog wel een keer en over een jaar of twee draaien ze vast bij”. Logisch dat je daar juridisch van gaat dreigen. Maar dan kom ik weer bij het juridische punt: hoe groot acht je de kans dat je gaat winnen, en wat heeft jouw rechtszaak dan voor gevolgen voor de community?

Arnoud

Hoe kan ik een opensourcemodule opnieuw implementeren?

| AE 8194 | Intellectuele rechten | 18 reacties

Een lezer vroeg me: Ik werk aan een opensourceproject dat een kloon (fork) is van een groter project. Wij krijgen bij onze nieuwste module nu het verwijt hun auteursrechten geschonden te hebben omdat de code te veel lijkt. Maar wij hebben deze echt zelf geschreven, hoewel de module wel exact hetzelfde doet. Plegen wij nu… Lees verder

Maakt linken van een GPL bibliotheek je software automatisch GPL?

| AE 7290 | Intellectuele rechten | 40 reacties

Intrigerende discussie in de comments vorige week: als je programma linkt tegen een GPL open source library, is je programma dan alleen onder de GPL te verspreiden? Immers, de GPL zegt dat je afgeleide werken alleen onder de GPL mag verspreiden. En wat is er nu meer afgeleid dan een programma dat noodzakelijkerwijs een library… Lees verder

Spionagemalware Duqu schendt GPL

| AE 3040 | Intellectuele rechten, Iusmentis | 25 reacties

Sjongejongejonge, wat zullen de Duqu-makers daar wakker van liggen: de beruchte spionagemalware Duqu bevat open source-code die onder de ‘virale’ licentie GPL vallen, las ik bij Webwereld. Duqu blijkt open source blokken te bevatten van derden en die licentie te negeren. Tsja, wat moet je met zo’n berichtje? Ik noem het maar ‘grappig’, wanthet is… Lees verder

Kun je als koper van een Tomtec tablet ze dwingen de Linuxbroncode vrij te geven?

| AE 2939 | Intellectuele rechten | 61 reacties

Een lezer wees me op een draadje bij Gathering of Tweakers over de broncodes van de Linuxkernel in een Tomtec tablet: als aanvulling ik ben afgelopen vrijdag in een mailwisseling met TOM-TEC er achter gekomen dat zij niet eens (willen) snappen wat gpl betekend als kernel licentie en dat zij eigenlijk hun source moeten openbaren…. Lees verder

Zijn WordPress themes GPL?

| AE 2785 | Intellectuele rechten | 10 reacties

Een lezer vroeg me: Alweer een tijdje geleden speelde een discussie over het Thesis theme voor WordPress. Dat is een systeem voor layouts en uitbreidingen op het WordPress blogsysteem, dat eerst onder een gesloten (niet-open source) licentie beschikbaar was. WordPress zelf is GPL, en de auteurs daarvan eisten dan ook dat Thesis ook GPL moest… Lees verder