Maakt linken van een GPL bibliotheek je software automatisch GPL?

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 gebruikt? Het programma wérkt niet zonder de library. Maar Europees auteursrechtelijk waag ik dat toch te betwijfelen.

De term ‘afgeleid werk’ is een tikje ongelukkig. De term komt uit het Amerikaans auteursrecht; in Europa kennen we alleen de ‘verveelvoudiging in gewijzigde vorm’, oftewel een kopie, al dan niet aangepast, van (een deel van) het werk. Dat klinkt inderdaad wat beperkter, en dat is het volgens mij ook.

In de SAS/WPL-uitspraak heeft het Hof van Justitie de grenzen getrokken van het software-auteursrecht. In die zaak beriep SAS zich op een auteursrecht voor haar programmeertaal en functionaliteit daarin, maar gedaagde WPL kreeg gelijk, zo’n auteursrecht bestaat niet.

Auteursrecht op software bestaat volgens de hoogste Europese rechter alleen op de broncode en de daarvan afgeleide uitvoerbare code. Men noemt dit de ‘uitdrukkingswijzen’ en daaronder wordt alleen datgeen verstaan dat tot “reproductie van het computerprogramma of tot het computerprogramma zelf kunnen leiden”. Je moet dus, kort gezegd, met wat er overgenomen of gebruikt is in het andere werk, het originele programma zelf althans gedeeltelijk kunnen terugvinden.

Bij het gebruik van een software library roep je in je eigen programma een functie aan, waarna de implementatie van de library wordt uitgevoerd om de betreffende functionaliteit te realiseren. In het SAS/WPL arrest ging het om functies uit een programmeertaal, maar ik zie het verschil niet met een API van een specifieke bibliotheek. In feite is de implementatie van een programmeertaal ook een library (of set libraries) die je middels een API aanroept. Wil je in C een tekst op het scherm, dan zeg je printf("Hello, world!");, waarna libc de implementatie daarvan uitvoert, en wil je bij GNU readline een regel invoer verkrijgen dan zeg je readline(my_prompt);, waarna readline de implementatie daarvan uitvoert. Dat is technisch volgens mij dus hetzelfde.

Meer algemeen, als het aanroepen van een functie van een bibliotheek zou meebrengen dat je het auteursrecht op die bibliotheek schendt, dan zou het auteursrecht dus in feite de functionaliteit beschermen die achter de functie zit. En dát is nadrukkelijk niet de bedoeling in het Europese auteursrecht.

Gelet op deze overwegingen moet worden geconstateerd dat, wat de elementen van een computerprogramma betreft (…), noch de functionaliteit van een computerprogramma, noch de programmeertaal en de indeling van gegevensbestanden die in het kader van een computerprogramma worden gebruikt teneinde de functies daarvan te benutten, een uitdrukkingswijze van dit programma vormen in de zin van [het auteursrecht].

Het opnemen van een functie-aanroep in je programma (zoals printf("Hello, world!"); of readline(my_prompt);) kan dus niet leiden tot een auteursrechtinbreuk op libc of GNU readline, omdat die functie-aanroep nog geen uitdrukkingswijze van het programma libc dan wel readline vormt. Pas als je code zou overnemen, ook in gedeelten, zou er inbreuk kunnen ontstaan.

Wat de GPL of de FSF zeggen over afgeleide werken, linken of Complete Corresponding Source doet er hierbij volstrekt niet toe: je komt pas aan terminologie uit een licentie toe als er sprake is van inbreuk. Pas dan zou de aanroeper van de software immers hoeven te zeggen “geen inbreuk, ik heb een licentie”.

Het argument uit Oracle/Google dat het maken van de API zélf creatief is, gaat hierbij niet op. In die zaak werd Google’s API-kloon van Java inbreukmakend geacht omdat Oracle creatieve arbeid had gestoken in het definiëren daarvan. Maar dat was natuurlijk ook het geval bij de SAS programmeertaal waarvoor WPL programma’s maakte. De functionaliteit, dus ook hoe de functies heten, wat ze doen en welke parameters en return values daarbij horen, is geen “uitdrukkingswijze” van het programma.

Een complete reproductie van de API zou mogelijk wél inbreuk kunnen zijn. In de SAS/WPL uitspraak stond ook de eigen handleiding van WPL ter discussie, waarin elke functie was opgenomen (maar volgens mij ook stukken tekst uit de documentatie van SAS). Dit is iets dat de rechter per geval moet onderzoeken: hoe veel is er overgenomen en hoe creatief is hetgeen overgenomen is? Mogelijk dat bij een handleiding het citaatrecht nog een verweer kan zijn, maar bij een volledige overname met als doel een interface-compatibele kloon te schrijven twijfel ik zeer of dat opgaat. Maar wellicht biedt dit dan een lichtpuntje:

In deze context moet worden gepreciseerd dat indien een derde een gedeelte van de bron- of doelcode betreffende een voor een computerprogramma gebruikte programmeertaal of indeling van gegevensbestanden zou aanschaffen en hij met behulp van deze code soortgelijke elementen in zijn eigen computerprogramma zou creëren, deze handeling mogelijkerwijs een gedeeltelijke reproductie in de zin van [het auteursrecht] zou opleveren.

Het lijkt dus echt nodig dat er ook broncodes worden overgenomen. En puur de definities van de functies voldoen niet snel aan die eis.

Wat vinden jullie? Is er een wezenlijk verschil tussen een API van een of andere bibliotheek aanroepen versus de functies uit een programmeertaal? Maakt het uit of er maar één implementatie van die API+bibliotheek is? Of zijn er andere redenen om een API-aanroep toch inbreuk op het auteursrecht te noemen?

Arnoud

Open source met verspreidingsverbod

Interessante vraag vorige week bij mijn blog over “van wie is dat CMS”:

Hoe zit het met een constructie waarin de ontwikkelaar jou enerzijds het CMS onder de LGPL beschikbaar stelt en jij je er vervolgens contractueel op vastlegt het niet te verspreiden op last van een fikse boete? Waarbij de boete vervalt bij faillisement van de leverancier.

Dit is een creatieve poging om een soort van escrowregeling op te zetten. Het idee is dan dat je bij faillissement een LGPL opensourcelicentie krijgt, zodat je toch door kunt blijven werken met die software.

Alleen: het gaat niet werken.

De LGPL is in feite gewoon een licentiecontract (ja, een contract) en contracten kunnen door een curator worden gepasseerd. Dus of je nu een speciale escrowclausule in je ‘gewone’ licentie opneemt of zo’n LGPL-met-boete-constructie hanteert, het verliest zijn waarde zodra de leverancier failliet is.

De constructie deed me denken aan de term open source escrow. Dit komt erop neer dat de escrowagent de broncode in escrow houdt en uitbrengt onder een open source licentie zodra bekend is dat de leverancier failliet gaat (of met zijn bedrijfsvoering stopt om andere redenen). Dat kan dus, maar alleen als de agent de auteursrechten heeft.

Zouden mensen hier behoefte aan hebben? En zou het überhaupt werken, een stukje propriëtaire software die ineens open source wordt? Wie heeft zin daaraan te gaan werken?

Arnoud

Mag je LGPL software subclassen?

ketting-chain-link.pngEen lezer vroeg me:

Naar aanleiding van het softwareboek vroeg ik me af of je ook aandacht gaat besteden aan de kwestie over linken, met name bij de LGPL. Ik weet dat dat legaal is, maar hoe werkt dit bij talen waarbij het concept ‘linken’ niet bestaat? Denk aan objectgeorienteerde talen zoals Java of Objective-J. Daarbij maak je eerder gebruik van code door objecten te subclassen (vererven). Is een klasse die eigenschappen erft een afgeleid werk? En mag je die klasse dan onder een eigen licentie uitbrengen als hetgeen waar je van afleidt, LGPL is?

De GPL en LGPL zijn de twee bekendste opensourcelicenties. Ze zijn grotendeels hetzelfde in opzet. Het belangrijkste verschil zit hem in hoe wordt omgegaan met ‘afgeleide werken’ of wat we in Nederland ‘verveelvoudigingen in gewijzigde vorm’ zouden noemen. Daarvan is sprake als je eigen code op bepaalde manieren combineert om zo een nieuw stuk software te maken.

De GPL eist dat dergelijke afgeleide werken óók weer GPL worden gemaakt wanneer je ze verspreidt. De LGPL doet dat niet, in ieder geval niet als je je eigen code via linking combineert, zo staat in artikel 5 van de LGPL v 2.1. Je bent bij de LGPL alleen verplicht om daadwerkelijke wijzigingen aan de LGPL-code zelf beschikbaar te stellen in broncodevorm wanneer je deze distribueert.

De LGPL is geschreven met C in het achterhoofd, vandaar de vrij specifieke bepalingen over linken. Het is dan ook erg moeilijk om te zeggen hoe de licentie uitpakt voor talen die niet linken maar juist subclassen of een framework bieden waar je mee ontwikkelt.

Er lijkt binnen de Java community een consensus te zijn dat LGPL klassen wél gesubclassed mogen worden maar GPL klassen niet. Maar dat is meer een informele afspraak tussen developers en niet echt een juridisch afdwingbaar iets – tenzij de rechter vindt dat die afspraak gezien mag worden als heersende mening oftewel gewoonterecht. De FSF schrijft “niets aan de hand, gewoon doorlopen”

The LGPL contains no special provisions for inheritance, because none are needed. Inheritance creates derivative works in the same way as traditional linking, and the LGPL permits this type of derivative work in the same way as it permits ordinary function calls.

Voor LGPLv2.1 wordt er dan aan toegevoegd dat “function signatures are checked against the library, creating a link”, wat me een beetje een gezochte interpretatie lijkt want dat is niet het soort ‘link’ dat LGPLv2.1 bedoelt. Maar goed.

De LGPLv3 lost het iets handiger op. Daar wordt in meer algemene zin gesproken van “combining or linking an Application with the Library.” Het lijkt mij dat subclassen of vererven van code ook wel onder die definitie valt.

Alles bij elkaar denk ik dat je met LGPL-code in een objectgeorienteerde taal mag subclassen of erven zonder dat je je eigen code LGPL zou moeten maken bij distributie. Wel moet je ervoor zorgen dat de LGPL code in een aparte JAR of ander soort bestand komt te staan. Ga je copypasten, dan val je buiten de uitzondering in de LGPL.

Arnoud

Belastingdienst schendt open source licenties

De Belastingdienst overtreedt volgens een open source-deskundige meerdere open-sourcelicenties met de aangiftesoftware, meldt Webwereld. Softwareontwikkelaar en -auditor Peter Roozemaal heeft de Belastingaangiftesoftware voor Linux uitgeplozen. In zijn rapport meldt hij dat de OpenSSL en GTK+ licenties niet zijn nageleefd.

De OpenSSL licentie vereist namelijk dat je in de documentatie bij het product de licentievoorwaarden vermeldt. De Belastingdienst volstaat met een link naar de licentievoorwaarden zoals die op internet te vinden zijn. Slordig.

Voor GTK+ ligt het iets gecompliceerder. Deze bibliotheek is beschikbaar onder de LGPL versie 2. De Belastingdienst heeft de software statisch gelinkt met haar applicatie. De LGPL eist dan dat je de gebruiker in staat stelt de GTK+ onderdelen te vervangen. Wat je daarvoor precies moet uitleveren, hangt af van de situatie, maar omdat de Belastingdienst simpelweg niets heeft uitgeleverd, is het wel duidelijk dat de licentie op dit punt niet is nagekomen.

Pijnlijk. Maar wat is de consequentie? Roozemaal schrijft namelijk:

Zolang de Belastingdienst niet aan alle van toepassing zijnde licentievoorwaarden voldoet, is er sprake van auteursrechtinbreuk en verspreiding van de Aangifteprogramma’s behoort gestaakt te worden totdat aan alle licentievoorwaarden voldaan kan worden.

Niet helemaal.

De OpenSSL licentie bepaalt nergens dat de licentie automatisch vervalt als je hem schendt. Daarvoor zal dus een rechtshandeling van de makers nodig zijn. In Nederland zijn softwarelicenties contracten. Wie een bepaling uit een contract niet naleeft, schendt het contract. Op grond daarvan mag de licentiegever het contract ontbinden. Maar dat gaat niet automatisch.

De GTK+ licentie heeft wel een bepaling over ontbinding bij schending:

You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

Die laatste zin beperkt het effect tot wat de Belastingdienst zelf doet. De ontvangers/downloaders van de software mogen deze gewoon blijven gebruiken. Alleen verdere verspreiding van de software door de Belastingdienst of anderen is niet toegestaan.

En ik vraag me nog af in hoeverre toepassing van een dergelijke algemene voorwaarde niet als onredelijk bezwarend te zien is in situaties als deze. Naar Nederlands recht mag je een contract bij een tekortkoming niet ontbinden als “de tekortkoming, gezien haar bijzondere aard of geringe betekenis, deze ontbinding met haar gevolgen niet rechtvaardigt.” Dit is geen dwingend recht (zo te zien) maar of je zó ver kunt gaan in algemene voorwaarden, betwijfel ik.

Het is voor mij dus geen uitgemaakte zaak dat de Belastingdienst haar licentie op GTK+ kwijt is en de software niet meer mag verspreiden. Maar ze moeten wel als de wiedeweerga aan de slag om deze problemen te repareren. Want uitermate slordig is het wel.

Heeft iemand dit al aan het GTK+ team gemeld eigenlijk?

Arnoud