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

Hoe verdeel je de eigendom van versgemaakte software?

software-code-binary-bits-bytesRegelmatig krijg ik vragen van softwareontwikkelaars en hun klanten over hoe om te gaan met het intellectueel eigendom op software die gemaakt is voor die klant. Hoe ga je daar nu mee om, hoe verdeel je die rechten op een manier waar beide partijen tevreden mee zijn.

Hoofdregel uit het auteursrecht is dat de partij die het werk maakt, de rechten daarop heeft. Huur je dus iemand in (een bedrijf of een freelancer), dan heeft deze de rechten. Niet de opdrachtgever. Ook niet als deze alle uren betaalt en/of als de software heel specifiek voor zijn situatie is ontwikkeld.

Wil je als opdrachtgever de rechten, dan moet je dat afspreken in de offerte. Achteraf opeisen kan ook, maar je staat dan een stuk zwakker. De ontwikkelaar hoeft dan niet akkoord te gaan met overdracht, dat was immers niet afgesproken. En iets verkrijgen dat niet afgegeven hoeft te worden, is onderhandelingstechnisch een lastige. Plus, wat moet dat kosten?

Een gebruikelijk compromis is maatwerk eigendom klant maken en het standaarddeel eigendom leverancier laten blijven. Zo kunnen zij door met het maatwerk, en kan de leverancier door met het standaardproduct naar andere klanten. Dit kan worden aangevuld met een verbod voor de leverancier om exact/vrijwel hetzelfde op te leveren voor een concurrent.

Nadeel voor de klant (en voordeel voor de leverancier) hiervan is dat de leverancier nu altijd nodig blijft om onderhoud aan de standaardsoftware te doen. Dat kan een leuke inkomstenbron zijn voor die leverancier, maar veel frustratie opleveren bij de klant. Zeker als de standardsoftware wordt uitgefaseerd of de ontwikkelaar gewoon geen zin meer heeft.

Van de ontwikkelaar eisen dat hij de rechten op de standaardsoftware afstaat, is niet redelijk. Hij maakte die immers om bij meerdere klanten in te zetten, en die optie wordt nu geblokkeerd.

Een alternatief kan zijn om te eisen dat de ontwikkelaar alleen werkt met open source. Daarvan is immers niet echt een eigenaar aan te wijzen, en bovendien heeft de klant dan altijd genoeg gebruiksrechten om er zelf mee te kunnen werken. Hij is dan leveranciersonafhankelijk. Maar lang niet iedere ontwikkelaar kan of wil werken met open source van derden.

Sommige juristen stellen dat je zou kunnen zeggen dat het totaalpakket eigendom van de klant kan worden, zonder dat de leverancier daarmee de onderliggende rechten verliest. Vergelijk dat iemand foto’s levert voor in een boek: de rechten op de foto blijven van de fotograaf maar het auteursrecht op het boek is van de uitgever daarvan. De uitgever mag het boek dan herpubliceren in bewerkte vorm zonder aparte toestemming van de fotograaf. Die analogie gaat echter niet helemaal op, want foto’s hoeven in een boek zelden aangepast te worden en bij standaardsoftware (zoals een CMS of framework) moet dat juist wél kunnen. Misschien als je zegt, het gaat hier om de ‘foto’ zoals aangepast voor maatwerkproduct X van klant Y. Een standaardpakket zal altijd iets moeten worden aangepast voordat het werkt bij klant Y.

Hoe dan ook, maak alsjeblieft vóóraf afspraken. En vraag door als klant: menig ontwikkelaar denkt dat als je zegt “je wordt eigenaar van de software” de klant daarbij begrijpt “behalve natuurlijk het framweork/cms dat ik erbij krijg, dat spreekt voor zich”.

Arnoud

Opensourcebibliotheek Glibc nu eindelijk open source

gnu-c-library-glibc-software-library-bibliotheek-linken.pngOpmerkelijk: de basisbouwsteen van vrijwel alle open source blijkt nooit 100% open source te zijn geweest. Pas vorige week is de GNU C Library (glibc), de standaardbibliotheek voor Linuxapplicaties, ontdaan van een stukje antieke code die voorzien was van een licentie die niet voldeed aan de definitie van open source.

Glibc is een onderdeel van Linux dat door vrijwel elke applicatie wordt gebruikt. Deze bibliotheek implementeert alle standaardfuncties uit de programmeertaal C. De licentie is de Lesser GPL, die toestaat om applicaties te maken zonder dat die zelf ook weer open source moeten worden. Maar enkele jaren terug werd ontdekt dat er code in zat die stiekem eigenlijk niet open source was.

Nu was die code uit 1984, toen het hele idee van open source nog niet bestond. De bedrijfsjuristen van Sun Microsystems, die de code had uitgebracht, hadden dan ook hun eigen tekst verzonnen die op zich best liberaal en netjes was:

Sun RPC is a product of Sun Microsystems, Inc. and is provided for unrestricted use provided that this legend is included on all tape media and as a part of the software program in whole or part. Users may copy or modify Sun RPC without charge, but are not authorized to license or distribute it to anyone else except as part of a product or program developed by the user.

(inderdaad, tape media)

Het stukje in italics leverde het pijnpunt op: open source moet op elke mogelijke manier kunnen worden hergebruikt, niet alleen als onderdeel van een groter product. Omdat je dit stukje code van Sun niet op zichzelf mag doorverkopen, is het geen open source, en het kan dan dus ook niet opgenomen worden in glibc.

Dat is best wel een probleem voor zo’n belangrijk en essentieel stuk software. Oplossen is echter lastiger dan je zou denken, zoals Simon Phipps aangeeft, want:

  1. Waar komt de code vandaan?
  2. Wie heeft deze geschreven, en was die persoon in dienst bij het bedrijf of een leverancier of inhuurkracht?
  3. Wie is tegenwoordig verantwoordelijk voor deze code en mag beslissen dat deze open source wordt?

In dit specifieke geval was de uploader Sun nog wel te vinden, maar moest er in een papieren archief worden gedoken om te achterhalen waar de rechten lagen. En dat werd nog eens extra moeilijk omdat de nieuwe eigenaar van Sun (Oracle) druk bezig was met afhandelen van de aankoop en alle juristen in de “geen commentaar”-modus zaten.

Alles bij elkaar duurde het meer dan een jaar om de wijziging door te voeren. Maar het ís gelukt, en dat is wel een complimentje waard.

Arnoud<br/> Foto: GNU C Library handleiding, Free Software Foundation.