Licentie Problematiek
OpenSource licentieproblematiek
OpenSource is een verzamelnaam voor alle soorten software waarvan de broncode vrijelijk ter beschikking gesteld wordt.
Iedereen mag aanvullingen of verbeteringen maken voor de software en deze verder verspreiden.
De voorwaarden uit OpenSource licenties kunnen echter in sommige gevallen tot problemen leiden.
Zo worden er regelmatig heftige discussies gevoerd over de scope van bijvoorbeeld de GPL.
Ook is het niet altijd mogelijk om software onder verschillende licenties met elkaar te combineren, omdat die licenties conflicterende eisen opleggen.
Inhoudsopgave
Licenties
Wie een computerprogramma schrijft, heeft daar automatisch het auteursrecht op.
De auteur kan controle uitoefenen over het kopiëren, gebruiken en aanpassen van zijn computerprogramma door derden.
Om software beschikbaar te stellen aan anderen, moet de auteur toestemming geven voor datgene wat hij wil dat die anderen ermee kunnen doen.
Dit heet een licentie.
Een licentie is een overeenkomst waarin de auteur onder bepaalde voorwaarden toestemming verleent voor bepaalde handelingen.
OpenSource licenties verlenen iedereen toestemming om de broncode van een software-pakket aan te passen of uit te breiden, bijvoorbeeld om fouten te repareren,
om een efficiëntere implementatie te maken of om geheel nieuwe functionaliteit toe te voegen.
Ook mag het pakket vrijelijk gekopieerd en verspreid worden.
De auteur vraagt hier geen geld voor.
Verschil van interpretatie
OpenSource licenties zijn vaak algemeen geformuleerd, zodat ze voor diverse pakketten gebruikt kunnen worden.
Dit leidt echter nogal eens tot vage regels of onduidelijk gedefinieerde criteria over wanneer de licentie van toepassing is.
De belangrijkste discussiepunten bij OpenSource licenties zijn:
- Wat is 'gebaseerd op'?
- Wat is 'commercieel'?
- Wat is linken?
Wat is 'gebaseerd op'?
Diverse licenties, zoals de GPL, de Qt licentie, de Sleepycat licentie en de Open Software License, stellen bijvoorbeeld als eis dat combinaties met andere software eveneens vrijelijk beschikbaar moeten zijn.
Zo mag een pakket dat gebaseerd is op software onder de GPL alleen maar verspreid worden onder de GPL zelf.
Ook moet de broncode van het gehele pakket vrijelijk beschikbaar gesteld worden.
Het is echter niet duidelijk gedefinieerd wanneer dit nu het geval is.
Een simpele situatie is het overnemen (kopiëren) van broncode in de eigen broncode.
Statisch linken, het samenvoegen van verschillende modules tot één uitvoerbaar programma, lijkt ook onder dit criterium te vallen.
Maar als een bibliotheek (DLL) dynamisch wordt gelinkt tegen het eigen programma, is de situatie al een stuk minder duidelijk.
En met technieken als CORBA, RPC, sockets, plug-ins enzovoorts kan de situatie bijzonder complex worden.
Dit maakt het lastig om software onder de GPL te verwerken in een pakket met een andere licentie.
Wat is 'commercieel'?
Het komt soms ook wel voor dat een auteur zelf niet precies weet wat de implicaties zijn van de licentie die hij gekozen heeft.
Het is bijvoorbeeld niet toegestaan om software onder de GPL te verkopen onder een licentie die verdere verspreiding verbiedt of toegang tot de broncode beperkt.
Dit betekent echter niet dat er geen geld mag worden verdiend met het verspreiden van dergelijke software.
Die software mag best op een CD-ROM worden gezet en verkocht, mits de broncode van de software maar vrijelijk beschikbaar is en de rechten van de koper niet worden aangetast.
Toch zijn er auteurs die denken dat "GPL" betekent "alleen zonder winstoogmerk".
En dat leidt helaas nogal eens tot ruzie met distributeurs als Red Hat.
Wat is linken?
Er is nogal een verschil tussen de GPL en de Library of Lesser GPL.
De Library General Public License (LGPL) is een variant op de GPL, met name bedoeld voor bibliotheken (libraries of DLL's), programma's met functionaliteit die andere programma's kunnen gebruiken.
De LGPL staat het 'linken' van de bibliotheek met een programma toe zonder eisen op te leggen aan dat programma.
Wijzigingen aan de bibliotheek zelf mogen, net zoals wijzigingen aan een werk onder de GPL, alleen worden verspreid inclusief broncode en onder de voorwaarden van de LGPL.
Het verwerken van een bibliotheek onder de LGPL levert dus geen licentie-problemen op, mits het maar mogelijk is om de bibliotheek te vervangen door een nieuwe versie die interface-compatibel is.
Auteurs die geen bezwaar hebben tegen commercieel gebruik van hun bibliotheek, kiezen dan ook meestal voor de LGPL.
Dit geldt niet alleen voor 'klassieke' bibliotheken in bijvoorbeeld C of C++, maar ook voor Java classes, COM-componenten en vergelijkbare technieken.
De LGPL spreekt echter alleen over 'linken' en niet over technieken zoals die bij Java of COM gebruikelijk zijn.
In hoeverre dit nu analoog in te vullen is, is nog maar de vraag.
Distribueren van gewijzigde versies
Eén van de grootste voordelen van OpenSource software is de vrije beschikbaarheid van de broncode.
Hiermee is het altijd mogelijk de software aan te passen, bijvoorbeeld om bugs te repareren of extra functionaliteit toe te voegen.
Het verspreiden van gewijzigde versies levert echter soms problemen op.
Vaak krijgen namelijk de auteurs van het oorspronkelijke werk de klachten over wijzigingen die niet goed werken, of wordt van hen verwacht dat zij alle wijzigingen kennen en ondersteunen.
Vrijwel alle licenties eisen dat men altijd de wijzigingen documenteert en duidelijk aangeeft wie wat gewijzigd heeft, maar dit is niet voor alle auteurs genoeg.
Sommige licenties leggen dan ook een aantal extra eisen op aan het verspreiden van gewijzigde versies.
De Apache licentie bijvoorbeeld eist dat men gewijzigde versies onder een andere naam verspreidt.
Op die manier is meteen duidelijk wat nu de "echte" Apache software is en wat een aangepaste versie.
Andere licenties, waaronder die van Perl en LaTeX, staan het verspreiden van wijzigingen alleen toe in de vorm van "patches".
Dit zijn losse bestanden die aangeven welke regels van de originele versie op welke manier aangepast moeten worden om de wijzigingen door te voeren.
De gebruiker die het werk installeert, kan de patches dan toepassen en zo het gewijzigde werk verkrijgen.
Het is dan wel voor hem duidelijk dat het hier een gewijzigde versie betreft.
Ook bij het e-mail programma Pine werd deze eis opgelegd.
De bewoordingen van de licentie leken echter te suggereren dat men gewijzigde software zelf ook mocht verspreiden.
Dit leidde echter tot diverse dreigementen met rechtszaken van de universiteit van Washington, de auteurs van Pine.
Incompatibele licenties
Net als software kunnen ook licenties incompatibel met elkaar zijn.
Twee licenties zijn incompatibel wanneer ze conflicterende eisen opleggen aan de gebruiker of verspreider van de software.
Als de ene licentie verspreiding van broncode verbiedt, zoals bij de meeste commerciële software, en de andere licentie verspreiding van broncode vereist,
zoals bijvoorbeeld bij de GPL of de Sleepycat licentie, dan is het onmogelijk om aan beide licenties te voldoen als de software wordt gecombineerd.
De combinatie van twee programma's mag namelijk alleen worden gebruikt of verspreid wanneer de licenties van die twee programma's dit allebei toestaan.
Sommige OpenSource pakketten kunnen om deze reden niet met elkaar worden gecombineerd.
Een voorbeeld hiervan is het combineren van bijvoorbeeld de OpenSSL cryptografische bibliotheek met een pakket onder de GPL.
De GPL verbiedt het opleggen van enige restrictie op de rechten uit deze licentie aan de ontvanger van de software.
Daardoor kan men verdere verspreiding van deze software niet verbieden door middel van bijvoorbeeld een geheimhoudingsverklaring of een octrooi.
Echter, dit verbod geldt voor alle soorten restricties of extra eisen.
De OpenSSL bibliotheek wordt verspreid onder de BSD-licentie.
Deze licentie geeft toestemming voor alles wat men met de software zou willen doen, en legt vrijwel geen eisen op waaraan de gebruiker of verspreider moet voldoen.
Zolang de copyright notice niet wordt verwijderd, is er niets aan de hand.
Sommige versies van de BSD licentie bevatten echter een extra clausule.
Deze clausule verplicht iemand die de software in een pakket verwerkt, de aanwezigheid hiervan bij elke advertentie van het pakket te vermelden.
Wie dit niet doet, mag de software niet verspreiden.
De combinatie van de GPL en de BSD licentie met deze zogeheten "advertising clause" levert dus een probleem op.
Aan de ene kant is iedereen verplicht de aanwezigheid van de BSD software te adverteren, en aan de andere kant is het verboden iemand te verbieden extra dingen te moeten doen.
Het is dus onmogelijk om bij verspreiding bij de licenties na te komen.
Dit heeft tot gevolg dat het niet toegestaan is om een dergelijke combinatie te verspreiden.
Dit probleem doet zich eigenlijk alleen voor bij combinaties met software onder de GPL.
Dit is namelijk één van de weinige veelgebruikte licenties die zo'n duidelijke beperking oplegt aan wat je verder nog mag eisen aan een gebruiker.
Gedeeld eigendom
Het auteursrecht geeft de maker van het werk bepaalde rechten, waarmee hij anderen kan verbieden het werk te gebruiken, kopiëren of verspreiden.
In het geval van OpenSource software is er meestal niet één enkele maker, maar zijn er meerdere.
Iedereen die een stukje heeft bijgedragen aan een programma is mede-auteursrechthebbende daarop.
De gebruiker van dat programma moet van alle auteursrechthebbenden toestemming hebben voordat hij het werk mag gebruiken.
Bij OpenSource software is dit meestal niet zo'n probleem.
Meestal sluit iedereen zich aan bij de licentie die de oorspronkelijke auteur heeft gekozen.
Wil men echter op zeker moment de licentie wijzigen, dan is daarvoor toestemming van alle mede-auteursrechthebbenden nodig.
Ook bij het geven van uitzonderingen op de licentie is toestemming van alle mede-auteursrechthebbenden nodig.
Eén enkele auteur kan dus niet het werk "vercommercialiseren" door de nieuwste versie alleen onder een commerciële licentie uit te brengen.
Hiertoe moeten alle auteurs samen besluiten.
Die ene auteur kan echter ook geen aparte toestemming geven voor iets dat de licentie normaliter verbiedt.
In het geval van Linux heeft bijvoorbeeld Linus Torvalds gezegd dat gewone applicaties die bovenop Linux draaien, niets te maken hebben met de licentie van het besturingssysteem zelf.
Toen hij dat zei, was hij echter allang niet meer de enige auteursrechthebbende.
Juridisch gezien is het dus nog maar de vraag wat deze verklaring voor waarde heeft.
Sommige projecten, met name de projecten die de Free Software Foundation (FSF) beheert, eisen om deze reden een expliciete overdracht van auteursrecht.
De FSF kan op die manier in haar eentje optreden tegen overtredingen van de licentie, de licentie aanpassen en desgewenst uitzonderingen verlenen.
Een dergelijke overdracht moet overigens schriftelijk plaatsvinden; een overdracht per e-mail heeft wettelijk gezien geen waarde.
Zijn OpenSource licenties eigenlijk wel bindend?
Er is bij OpenSource software geen installatieprocedure waarbij op "I Accept" moet worden geklikt, en er is geen contract dat hoeft te worden getekend.
Ook hoeft er niets betaald te worden aan de auteur.
Naar Nederlands recht is het niet vereist om iets te tekenen, te klikken of te betalen om een overeenkomst te sluiten tussen auteur en gebruiker van software.
OpenSource licenties zijn dus gewoon bindend, en het niet volgen van de voorwaarden levert inbreuk op het auteursrecht op.
Naar Amerikaans (Angelsaksisch) recht is voor het sluiten van een overeenkomst een zogeheten 'consideration' nodig.
Dit wil zeggen dat de gebruiker iets moet teruggeven aan de auteur.
Bij OpenSource software lijkt er niets te worden teruggegeven, dus volgens sommige Amerikaanse juristen zijn OpenSource licenties geen bindende overeenkomsten.
Dit zou kunnen betekenen dat de auteur de licentie te allen tijde kan intrekken, waarna iedereen moet ophouden de software te gebruiken.
Vrijwel alle gebruikers en verspreiders van OpenSource software lijken er echter van uit te gaan dat de OpenSource licentie-voorwaarden wel degelijk bindend zijn.
Conclusie
Licenties van OpenSource software leveren niet alleen problemen op voor bedrijven die software zoveel mogelijk geheim willen houden.
Ook binnen OpenSource projecten zelf kunnen licentieproblemen ontstaan.
Het is dus zaak de licentievoorwaarden zorgvuldig te bestuderen wanneer je overweegt software van iemand anders in een eigen project te verwerken.
