Mag je licentie-incompatibele dependencies meeleveren met je software?

| AE 9144 | Open source, Software | 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

Maakt linken van een GPL bibliotheek je software automatisch GPL?

| AE 7290 | Open source, Software | 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 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

After-dinner dip: mijn lezing over GPLv3, 13 november

| AE 1290 | Iusmentis, Open source, Presenteren | Er zijn nog geen reacties

vira.jpgOp 13 november organiseert de Vereniging Informaticarecht Advocaten een studiemiddag/avond over open source software (meelezende advocaten: 5 PO punten!). Drie keer raden wie er over GPLv2 versus GPLv3 mag komen vertellen.

De organisatie was zo vriendelijk mij na de borrel en het diner in te plannen, dus dat kan nog leuk worden.

Arnoud

Nederlandse vertaling van GPLv3

| AE 1144 | Open source | 4 reacties

Collega-blogger en advocaat Bart Beuving heeft samen met kantoorgenoot Maurits Westerik een inofficiële vertaling van GPL versie 3 gemaakt. Deze vertaling kan niet worden gebruikt als vervanging van de Engelstalige GPLv3, maar is erg nuttig voor wie moeite heeft met de vaak cryptische Engelse terminologie in de open source licentie. Mijn complimenten voor Bart en… Lees verder

Nieuw op Iusmentis: Uit principe: de GNU General Public License (GPL) versie 3 (in Software > Open source software @ iusmentis.com)

| AE 546 | Open source | Er zijn nog geen reacties

Versie 3 van populairste open source licentie introduceert vérgaande verboden op octrooien, technische voorzieningen en beperkt toegankelijke hardware. Na vijftien jaar is er dan eindelijk een derde versie van de GNU General Public License. De reden: onvrede over bepaalde praktijken in de open source wereld. In dit artikel, gepubliceerd in het juridisch tijdschrift Computerrecht bespreekt… Lees verder

The Jem Report: The real heart of the GPLv3 rift

| AE 502 | Auteursrecht, Open source | Er zijn nog geen reacties

Alweer een zeer juiste observatie over GPL versie 3 in The Jem Report: With events like Eben Moglen’s bizarre tirade against Tim O’Reilly, the FSF leadership (even though Moglen is no longer officially a leader, he still acts as a spokesperson) is appearing more like a group of religious extremists, and less like programmers intent… Lees verder

CIER lezing: Uit principe – de GNU General Public License versie 3

| AE 484 | Open source, Presenteren | 1 reactie

Gisteren gaf ik een lezing over GPL versie 3: Uit principe – de GNU General Public License versie 3. De bijbehorende tekst staat nu via CIER online en verschijnt ook in het eerstvolgende nummer van Computerrecht (2007/5). Het was een grote uitdaging om deze complexe licentie op een duidelijke manier toe te lichten, maar ik… Lees verder

Niet vergeten: mijn lezing over GPL versie 3 bij het CIER in Utrecht

| AE 449 | Open source | Er zijn nog geen reacties

Voor wie wil horen waar GPL versie 3 nu eigenlijk over gaat: komt allen volgende week -3 oktober dus- naar het Molengraaff Instituut voor Privaatrecht, Drift 9 te Utrecht. Wel even opgeven bij CIER. GPLv3 is tegen. Tegen DRM, tegen software-octrooien en vooral tegen bedrijven die hun hardware beperkt toegankelijk maken. En dat is een… Lees verder

Linus: Liever GPL versie 2

| AE 374 | Open source | Er zijn nog geen reacties

Linus Torvalds spreekt: liever GPL versie 2 dan versie 3, zo meldt Tweakers. ‘Ik vind niet dat het een ‘verschrikkelijke’ licentie is,’ antwoordde Torvalds op de vraag van EFYTimes onder welke omstandigheden hij het onder de gplv3-licentie uitbrengen van de Linux-kernel zou steunen, ‘Ik vind alleen niet dat het eenzelfde soort ‘geweldige’ licentie is als… Lees verder

Zit Microsoft aan GPLv3 vast?

| AE 335 | Contracten, Open source | Er zijn nog geen reacties

GPL versie 3 is tegen Microsoft. En helemaal tegen die man die die creatieve deal met Novell bedacht heeft, waarbij Microsoft tegen betaling octrooilicenties geeft aan klanten van Novell voor het gebruik van SuSE Linux. Dus liep GPLv3 acht maanden achterstand op met als doel een constructie te verzinnen waardoor Microsoft nu aan GPL versie… Lees verder