Steeds meer softwarebedrijven en -auteurs kiezen ervoor om hun software open source te maken. Daarmee willen zij aansluiten bij de snel groeiende beweging die gelooft in software delen en samen verder ontwikkelen. Eén vraag blijft daarbij vaak onderbelicht: welke licentie kun je het beste gebruiken als je software uitbrengt als open source?
De gedachte achter open source is dat de broncode van software open en vrij beschikbaar moet zijn voor iedereen. Zo kan iedereen voortbouwen op de software, van fouten herstellen tot deze integreren in andere pakketten of delen hergebruiken in compleet andere situaties. Om dit vast te leggen, moet de software onder een open source licentie worden geplaatst.
Er zijn meer dan vijftig open source licenties (en dan tel ik de vele kleine variaties daarop niet eens mee). Iedere licentie heeft zijn eigen filosofie over de beschikbaarheid van broncode en de rechten en plichten van gebruikers en verspreiders van de software. Dat maakt de keuze niet eenvoudig. Met onderstaande vuistregels komt u hopelijk een eind.
Voortbouwen op bestaande open source
Voor wie voortbouwt op een bestaand stuk open source, is de keuze meestal eenvoudig: gebruik de licentie van die bestaande open source. Soms is dat juridisch verplicht (de GPL eist dit bijvoorbeeld) maar ook als het niet verplicht is, is het zeer verstandig. De mensen die die bestaande open source kennen, zijn gewend aan die licentie en zullen dus het liefst de voortbouwsels ook onder die licentie gebruiken.
Ook als men de code graag opgenomen zou zien worden bij een bepaalde community, zal de keuze van de licentie snel gemaakt zijn. De meeste communities hebben een standaard licentie, en verwachten dat alle bijdragen onder die licentie geplaatst worden. Zo accepteert het Apache Project alleen bijdragen onder de Apache Software License, en verwacht de Eclipse community dat men de Eclipse Public License gebruikt. (De BSD community is dan weer iets minder streng en staat ook andere licenties toe, afhankelijk van de situatie.)
Geheel eigen software
Bij een geheel eigen stuk software is de keuze vrij. Maar hoe dan te kiezen?
Alle open source licenties hebben een aantal dingen gemeenschappelijk. Zo wordt aansprakelijkheid van de auteur zo ver mogelijk uitgesloten, krijgt de gebruiker het recht deze aan te passen en te verspreiden hoe hij maar wil en is naamsvermelding van de originele auteur verplicht. Dat helpt dus niet echt bij de keuze.
Wél helpt als eerste schifting de categorielijst van Opensource.org. Deze noemt acht licenties (Apache, BSD, GPL, LGPL, MIT, Mozilla, CDDL en Eclipse) die in de praktijk populair blijken. Die populariteit is belangrijk want dat betekent dat anderen deze licentie waarschijnlijk kennen, en dus snappen wat er mag en moet als ze de code gaan aanpassen en/of verspreiden. Ook is er meer code onder die licentie elders beschikbaar, zodat deze desgewenst kan worden hergebruikt of gecombineerd.
Drie smaken open source
De licenties lopen vooral uiteen waar het gaat om de beschikbaarheid van broncode, en zeker waar het gaat om het beschikbaar moeten stellen van aangepaste of uitgebreide broncode. Hierin zijn er grofweg drie smaken:
- De gebruiker/ontvanger mag zelf weten of hij broncode beschikbaar stelt, en zo ja welke. (Bekende voorbeelden: Apache, BSD, MIT)
- De gebruiker/ontvanger moet bij verspreiding de originele broncode mee beschikbaar stellen, inclusief bewerkingen daarvan. Eigen code hoeft niet te worden gedeeld. (Bekende voorbeelden: LGPL, Mozilla, CDDL, Eclipse)
- De gebruiker/ontvanger moet bij verspreiding de originele broncode mee beschikbaar stellen, inclusief bewerkingen daarvan. Ook eigen code die integreert met die broncode moet beschikbaar gesteld worden. (Bekend voorbeeld: GPL)
De keuze voor één van deze drie smaken zal vooral afhangen van wat men verwacht (of juist wil) dat de concurrent gaat doen. Als code open source wordt, kan immers de concurrent er ook van profiteren.
Profiteren van uitbreidingen
Bij keuze 1 is de concurrent vrij om voort te bouwen op die open source gemaakte code, maar kan de auteur niet profiteren van die voortbouwsels. Wil men juist wel kunnen profiteren van die uitbreidingen, dan is keuze 3 een betere. In feite wordt open source dan ingezet als een soort samenwerkingsovereenkomst waarbij iedereen mag meedoen maar wel de resultaten moet delen.
Het nadeel van keuze 3 is dan weer dat een concurrent vaak minder geneigd zal zijn om de software met eigen code te integreren. Die eigen code moet dan open source worden, en daar zijn niet alle bedrijven toe bereid. Keuze 2 is dan een mooi compromis: de auteur kan wel profiteren van bijdragen aan die code, en de gebruiker kan de code ook gebruiken zonder eigen code te hoeven vrijgeven.
Dat wil echter niet zeggen dat keuze 1 nooit een goed idee is. Code onder een dergelijke licentie kan eenvoudig overal worden gebruikt, ook door partijen die niets hebben met het idee van open source. Daarmee kan die code uitgroeien tot een de facto standaard. Een al wat ouder voorbeeld is de TCP/IP netwerkcode uit het BSD besturingssysteem, die gedeeltelijk overgenomen werd in Microsoft Windows.
De belangrijkste vragen zijn dus: hoe graag wil ik dat iedereen deze code gebruikt, en hoe erg vind ik het als ik uitbreidingen of aanpassingen niet terug zou krijgen? Wat levert hergebruik me op, en zal het eisen van teruggave van broncodes dit stimuleren of juist beperken?
