Open source licenties

Softwarepakketten zijn steeds onderhevig aan een bepaalde licentie, die voorwaarden oplegt aan het gebruik van dit pakket. Bij open source software (OSS) is dit niet anders. Vaak denkt men bij OSS aan de GNU Public License, kortweg GPL. Er zijn evenwel verschillende categorieën van OSS-licenties met elk hun eigenschappen. Net zoals bij commerciële software moet er bij OSS nagegaan worden of de licentievoorwaarden compatibel zijn met het beoogde gebruik.

We gaan hier dieper in op een aantal aspecten:

1. Open source software of Vrije software?
2. Klassen van licenties
3. Dual licensing
4. Aandachtspunten

Open Source of Vrije software?

Het Open Source Initiative (OSI) hanteert 10 criteria waaraan een licentie moet voldoen om door hen als "Open Source" erkend te worden. Deze Open Source Definition wordt wereldwijd aanvaard als definitie. De belangrijkste elementen zijn:

• beschikbare broncode
  Het belangrijkste aspect aan OSS is het 'open source'-karakter, namelijk de vrije beschikbaarheid van de programma- of broncode. Dit in tegenstelling tot 'closed source', software waarvan de broncode niet vrij beschikbaar is.

• vrije (her)verspreiding
  De software mag vrij verspreid worden.

• mogelijkheid tot het maken van afgeleide software
  De broncode mag als basis dienen voor afgeleide software. Het licentiemodel van deze afgeleide software kan afhankelijk zijn van de licentie van de broncode (zie verder).

Momenteel zijn er een 60-tal licenties die OSI-approved zijn, waaronder naast de klassiekers (GPL, LGPL, MIT, MPL) misschien verrassend ook twee licenties van Microsoft.

De Free Software Foundation (FSF) hanteert andere criteria voor wat het Free software of vrije software noemt. De diverse GNU-licenties zoals GPL en LGPL komen van de FSF. De licenties die de FSF aanbeveelt steunen op vier fundamentele vrijheden voor de gebruiker van de software:

• De vrijheid om het programma te gebruiken voor elk doel (vrijheid 0).
• De vrijheid om de manier waarop het programma werkt te bestuderen, en om het aan te passen aan je behoeften. Beschikbaarheid van de broncode is hiervoor noodzakelijk (vrijheid 1).
• De vrijheid om het programma te verspreiden, zodat je je naasten kan helpen (vrijheid 2).
• De vrijheid om het programma te verbeteren en daarna te verspreiden, zodat de hele gemeenschap er voordeel uit kan halen. Hiervoor is beschikbaarheid van de broncode eveneens noodzakelijk (vrijheid 3).

FSF heeft dus zelf ook een lijst van licenties die aan haar criteria voor een "free software license" voldoet. Er wordt hierbij het onderscheid gemaakt tussen licenties die compatibel zijn met GPL en deze die dat niet zijn. Dit is belangrijk als je verschillende open source componenten als basis gebruikt voor eigen ontwikkelingen. Sommige licenties zijn immers niet compatibel met elkaar.

De meeste licenties komen zowel in de lijst van OSI als FSF voor, dus eigenlijk maakt het voor de gebruiker niet zoveel uit.

Klassen van licenties

Zoals gezegd, zijn er verschillende types van OSS-licenties te onderscheiden. Als we ervan uitgaan dat de licentie voldoet aan de reeds vermeldde Open Source Definition, dan zijn er twee uitersten te onderscheiden copyleft en permissieve licenties.

• Copyleft licenties werken zoals de term aanduidt als tegenpool van copyright. De broncode van software met deze licentie dient ten allen tijde vrij te zijn en afgeleiden van deze software dragen dezelfde licentie indien de afgeleide wordt verspreid. Het bekendste voorbeeld van zo een licentie is de GNU General Public License (GPL).

• Permissieve licenties laten in tegenstelling tot de vorige klasse toe om afgeleiden te maken die volledige gesloten zijn. Een mooi voorbeeld hiervan is de Apache-licentie.

De licentiewereld is uiteraard niet zwart-wit en bevat nogal veel grijze zone. Heel wat licenties situeren zich tussen puur copyleft en heel permissief.

In de volgende tabel worden een aantal licenties weergegeven met een aantal eigenschappen.

Licentie	Mogelijkheid tot kopiëren, distribueren en wijzigen	Mogelijkheid combinatie met propriëtaire software en herdistributie	De bron dient bij herdistributie beschikbaar te zijn
GPL, AGPL, EUPL	Ja	Nee	Ja
LGPL	Ja	Ja	Ja
MPL	Ja	Ja	Ja
BSD	Ja	Ja	Nee
Apache	Ja	Ja	Nee

In de copyleft licenties wordt de term redistribution of herdistributie gehanteerd. Dit betekent dat je custom software gebaseerd op software van dergelijke licentie niet mag leveren, al dan niet tegen betaling, aan derden zonder het beschikbaar stellen van de volledige broncode. Software voor puur intern gebruik valt dus bijvoorbeeld niet onder deze clausule.

Hierna volgt een korte bespreking van verschillende licenties om aan te geven wat een mogelijke impact kan zijn. Deze informatie heeft uiteraard geen juridische waarde. Hiervoor verwijzen we naar de expliciete tekst van de licenties.

GNU General Public License (GPL)

Dit is de bekendste open source licentie. De licentie is berucht omwille van het 'virale' karakter van de licentie. De GPL bevat een voorwaarde die stelt dat software welke GPL-gelicentieerde code gebruikt (een stuk broncode of een softwarebibliotheek), ook moet uitgebracht worden onder de GPL bij herverspreiding van de software. Dit heeft als gevolg dat een bedrijf dat een blok code met GPL licentie opneemt in zijn eigen software en deze software verdeelt bij klanten, deze software ook moeten vrijgeven onder de GPL. In een commerciële context is dit meestal ondenkbaar.

Merk hierbij op dat het gebruik van een GPL-softwarebibliotheek onderhevig is aan hetzelfde gedrag.

GNU Affero General Public License (AGPL)

Dit is een zeer sterke versie van GPL. De term herverspreiding is van toepassing op software die via het web wordt gebruikt. Als je toepassing dus vanop afstand toegankelijk is voor eindgebruikers dien je dus de source code beschikbaar te maken. Als application service provider of Software-as-a-Service-provider houdt het gebruik van dergelijke software dus sterke consequenties in.

GNU Lesser Public License (LGPL)

Dit is een variant van de GPL die toelaat om OSS-bibliotheken te gebruiken, zonder dat hierbij de code van het softwarepakket dient worden vrij gegeven. Een goed voorbeeld hiervan zijn de GNU C-bibliotheken.

EUPL (European Union Public Licence)

Dit is de officiële Europese licentie die gelijkaardig is aan de GPL en sedert versie 1.1 eigenlijk meer te vergelijken is met de Affero GPL. Het bijzondere aan deze licentie is het feit dat ze vertaald is in 22 talen en juridisch geldig is in die talen. EUPL v1.1 werd op 4 maart 2009 een officiële OSI-licentie. Het doel is dat softwareontwikkelingen in het kader van Europese projecten deze licentie zouden dragen.

Mozilla Public License (MPL), IBM Public License, Sun Public License

De MPL was de oorspronkelijke licentie van de broncode van de Netscape webbrowser toen die werd vrijgegeven. Al deze licenties zijn gelijkaardig aan de LGPL.

BSD, Apache en  MIT-licentie

Deze licentievormen bieden veel vrijheid wat de bruikbaarheid van de code betreft. Het product zelf mag commercieel gebruikt worden en afgeleiden hoeven niet onder dezelfde licentie te vallen. Het resulterend softwarepakket mag zowel als broncode of als binaire vorm verspreid worden.
Onder de BSD-licentie mogen afgeleide producten de naam van de oorspronkelijke auteur niet gebruiken als reclame.

Dual licensing

Er zijn heel wat open source softwarepakketten die beschikbaar zijn onder een zogenaamde dual-license. Dit betekent meestal dat er een open source licentie is op de software en dat er daarnaast ook een commerciële licentie beschikbaar is tegen betaling. Typisch is de open source licentie dan een copyleft-licentie en zal de commerciële licentie de softwareontwikkelaar beschermen tegen het 'virale' karakter.

Je moet evenwel opletten met deze dual-licensing. Soms is het softwarepakket niet hetzelfde voor beide licenties. Er ontbreekt bijvoorbeeld bepaalde functionaliteit in de open source versie die eigenlijk als lokmiddel wordt gebruikt.

De open source licentie kan soms zelf kleine lettertjes bevatten zoals "deze versie mag je enkel gebruiken op een specifieke applicatieserver met die specifieke databank". Wil je het pakket dan gebruiken op een andere omgeving ben je dus niet in regel.

Voor een aantal softwarepakketten betekent de commerciële licentie gewoon een mogelijk supportcontract en is het onderliggende softwarepakket net hetzelfde.
Kijk dus goed uit met pakketten die onder een dubbel model beschikbaar zijn.

Aandachtspunten

Zoals na lectuur van deze tekst al duidelijk moet zijn is de interpretatie van de impact van de licentie van een softwarepakket niet altijd evident. Let bij de keuze van een open source software dus vooral goed op. Kort gezegd dien je rekening te houden met:

• Is dit pakket een basis voor eigen ontwikkelingen en wat is de mogelijk impact van de licentie?
• Wie zijn de eindgebruikers van de software en is er een impact van de licentie?
• Zijn er "kleine lettertjes" in de licentie?
• Ga ik het (gewijzigde) pakket zelf verspreiden of is het intern gebruik?
• Zijn er meerdere licentievormen van toepassing (dual licensing)? Indien dit het geval is, let dan goed op met mogelijke restricties, gebrek aan functionaliteit of ontbreken van support met de open source versie.
• Ga je meerdere open source pakketten als basis gebruiken voor ontwikkelingen, dan moet je opletten voor de (in)compatibiliteit tussen licenties.