U bevindt zich in
OpenSource
Dwarsligger
HoofdstukkenMenu terugOpenSource Volgens Pagina's startBindendheid van LicentiesGevaar of KansJuridische StatusKennisnetwerk OpenSourceMixen Open en GeslotenOnderzoek OSS voor OverheidOpenSource PraktijkgidsOpen source licentieproblematiekOverheid en OpenSourceWelke Licentie
Welke Licentie

Welke OpenSource licentie moet ik kiezen?
Steeds meer softwarebedrijven en -auteurs kiezen ervoor om hun software OpenSource 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 OpenSource?

De gedachte achter OpenSource 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 OpenSource licentie worden geplaatst.

Er zijn meer dan vijftig OpenSource 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 OpenSource
Voor wie voortbouwt op een bestaand stuk OpenSource, is de keuze meestal eenvoudig: gebruik de licentie van die bestaande OpenSource.
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 OpenSource 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 OpenSource 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 OpenSource
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:
  1. De gebruiker/ontvanger mag zelf weten of hij broncode beschikbaar stelt, en zo ja welke.
    (Bekende voorbeelden: Apache, BSD, MIT)
  2. 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)
  3. 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 OpenSource 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 OpenSource 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 OpenSource 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 OpenSource 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 OpenSource.
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?

Bron: ICT Recht door Arnoud Engelfriet op 4 mei 2019.
Valid HTML 5.0 Valid CSS
Een link is een pagina,
een link is een hoofdstuk,
een link is in een externe website,
een link is een download.
© Dwarsligger.org, overname met bronvermelding toegestaan,
tenzij anders aangegeven.
Ron's CMS versie 190612a
Samengesteld in
Inhoud grootte
Aangemaakt op
Aangepast    op
27003 µsec.
11981 bytes
04 mei 2018
05 mei 2019