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

5 reacties

  1. Wel moet je ervoor zorgen dat de LGPL code in een aparte JAR of ander soort bestand komt te staan.

    Waarom? Waarschijnlijk interpreteer ik deze zin verkeerd, maar het wekt bij mij de indruk dat ik in C b.v. geen static-linked binary zou mogen maken als ik een LGPL library gebruik. Dat lees ik in LGPL 2 niet terug (andere LGPL licenses heb ik nooit gelezen; ben meer een 3-clause BSD license gebruiker (en deler)).

    (maar zoals gezegd: waarschijnlijk lees ik je opmerking gewoon verkeerd)

  2. Het advies is vooral om te voorkomen dat mensen gaan copypasten of eigen code in de bestanden zetten die LGPL zijn. In die gevallen is de kans groot dat je niet een “work that uses the library” maakt maar een gewijzigde library. En dan moet je al die eigen code delen bij verspreiding.

    Bij static linking geldt de eis uit LGPL 6a, oftewel je moet relinken van de gehele binary mogelijk maken. En dat kan in de praktijk eigenlijk alleen door je eigen broncode te delen (of de .o of .obj files). Als je met dynamic linking werkt, hoef je geen eigen code vrij te geven maar alleen te zorgen dat mensen de library kunnen vervangen.

  3. Overerven gaat toch in principe op dezelfde manier als dynamisch linken? Ik zie het verschil eerlijk gezegd niet helemaal…

    Een .jar bestand bevat een stel classdefinities en uitvoerbare, gecompileerde code. Wanneer je een class subclassed maak je een eigen class “die onder water” (runtime geregeld) methods van de parent kan aanroepen en/of vervangt.

    Een .a , .so of .DLL bestand werkt op dezelfde wijze, behalve dat die nog vergezeld gaan van .h en .lib bestanden die de definities en de stubs bevatten *.

    Kijk maar eens naar een taal als C++ met vrijwel dezelfde overervingsmechanismen als Java maar met vrijwel dezelfde link-methodiek als C. Zeker wanneer je in C++ pure virtual functions (met dynamic binding dus) gebruikt is er niet echt veel verschil meer qua linking en overerving.

    Someone recently made the claim that including a header file always makes a derivative work. That’s not the FSF’s view. Our view is that just using structure definitions, typedefs, enumeration constants, macros with simple bodies, etc., is NOT enough to make a derivative work. It would take a substantial amount of code (coming from inline functions or macros with substantial bodies) to do that.’

  4. De vraagstelling nodigt nogal uit om er allerlei technische details bij te halen over de werking van compilers en linkers, maar dat lijkt me voor de juridische vraag niet relevant. Het gaat er om of je de LGPL-code gebruikt zonder erin te knippen en plakken. Bij een subklasse maak je een nieuw eigen bestand en wijzig je niets in de oorspronkelijke LGPL-code, en dus mag het. Ik ben het dus met de interpretatie in dit artikel eens. Inderdaad niets aan de hand.

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.