U bevindt zich in
OpenSource
Dwarsligger

Juridische Status

OpenSource praktijkgids
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.
Pakketten zoals het Linux besturingssysteem, de Firefox webbrowser of the Apache webserver zijn de bekendste voorbeelden van OpenSource.

OpenSource heeft zeker voordelen.
Het kan alleen lastig zijn om uit te zoeken wat nu precies mag.
OpenSource licenties lijken op een aantal essentiële aspecten af van traditionele "gesloten" licenties of EULAs.
Het meest opmerkelijke is de eis om eigen software die voortbouwend op OpenSource ook weer vrij te geven als OpenSource.

Inhoudsopgave
Wat is OpenSource
OpenSource is vrijelijk beschikbaar voor iedereen.
Omdat het concept van software vrij aanbieden -inclusief broncode- veel mensen vreemd aandoet, zijn er nogal wat mythes en misverstanden rondom OpenSource.
Om een paar van die mythes weg te nemen:
Het gebruik van OpenSource als alternatief voor commercieel ontwikkelde software wordt steeds populairder.
OpenSource is hoge kwaliteit, direct beschikbaar en ook nog eens zonder licentiekosten.
Een logische keuze dus.

En dit geldt niet alleen voor pure software-firma's of adviesbureaus.
Ook fabrikanten van elektronica en andere apparaten maken steeds vaker gebruik van OpenSource om grote delen van de functionaliteit daarin te realiseren, om zo sneller met nieuwe producten te kunnen komen.

OpenSource is wel vrij maar geen publiek domein.
Ook bij OpenSource horen licenties.
De software mag alleen worden gebruikt in overeenstemming met die licenties.
Omdat OpenSource voorwaarden nogal af kunnen wijken van "gewone" licenties, is het belangrijk om extra op te letten dat deze voorwaarden worden nageleefd.

OpenSource als een ontwikkelmodel
OpenSource is een ontwikkelmodel voor software waarbij de broncode vrijelijk gedeeld wordt.
Iedereen krijgt het recht deze aan te passen en de software in gewijzigde vorm te verspreiden.
Het is de bedoeling dat wijzigingen teruggegeven worden aan de oorspronkelijke auteurs, al is dit niet verplicht.

Bij dit ontwikkelmodel draait alles om samenwerken.
En dit blijkt een zeer succesvolle manier om snel software van hoge kwaliteit te produceren.
Alhoewel het model het meest bekend is bij wereldwijde projecten zoals het Linux besturingssysteem of de Apache webserver, kan het ook wel worden gebruikt binnen een bedrijf.
Het wordt dan ook wel "Inner Source" genoemd.

De OpenSource gemeenschap
OpenSource wordt niet beheerd door een bedrijf, stichting of andere organisatie.
Het is een gemeenschap, die bestaat uit een groot aantal individuen en groepen die bijdragen aan een bepaald project.
Een klein deel van deze gemeenschap -de "vrije software" beweging- is politiek actief.

Veel OpenSource software ontwikkelaars doen om pragmatische redenen mee en hebben weinig behoefte om deel te nemen aan juridische of politieke discussies.
De scheiding tussen deze twee groepen wordt duidelijk zichtbaar als wordt gekeken naar de twee meest prominente organisaties: de Free Software Foundation (FSF) en de OpenSource Initiative (OSI).

De Free Software Foundation
De Free Software Foundation (FSF) is opgericht in 1985 en promoot de rechten van computergebruikers om software te mogen gebruiken, kopiëren, bestuderen, wijzigen en doorgeven.
De FSF stimuleert de ontwikkeling van wat zij "vrije software" noemen (vrij in de betekenis van "vrije meningsuiting" en niet zozeer "gratis").
Dit gebeurt vanuit een politieke visie.
De FSF vindt dat iedereen het onbeperkte recht moet hebben om software te mogen gebruiken en aan te passen.
Beperkingen op dit recht zien zij als moreel verwerpelijk.
Software behoort geen eigenaar te hebben.
Om dit ideaal te realiseren, heeft Richard Stallman, oprichter van de FSF, de GNU General Public License (GPL) ontwikkeld.

Deze licentie bepaalt dat alle GPL software gebruikt, verspreid en aangepast mag worden zonder dat royalties verschuldigd zijn aan de auteurs.
Verspreiding van aangepaste of uitgebreide versies mag echter alleen als ook de aanpassingen of uitbreidingen onder de GPL beschikbaar worden gesteld.
Deze overervende clausule zorgt ervoor dat vrije software vrij blijft, en bovendien dat ook steeds meer software vrij wordt.
Het doel van de FSF is immers ervoor zorgen dat alle software ter wereld vrij zal zijn.

De OpenSource Initiative
De FSF is een politieke organisatie met een harde opstelling richting bedrijven die "onvrije" software gebruiken ("moreel verwerpelijk" is een van hun beleefde uitdrukkingen wat dit betreft).
Deze houding, gecombineerd met de -onjuiste- angst dat alle software vrij moet worden als ergens een stukje GPL software gebruikt wordt, heeft bedrijven lang terughoudend gemaakt om de vrije software te gebruiken.
In 1998 kondigde het bedrijf Netscape Communications aan dat het de broncode van haar webbrowser vrij beschikbaar zou stellen.
Een groep prominente vrije software-ontwikkelaars greep deze kans aan om het ontwikkelmodel te promoten bij bedrijven, en verzon de neutralere term "OpenSource" als omschrijving daarvan.
De OpenSource Initiative (OSI) werd vervolgens opgericht als een publieke stichting die onder andere licenties certificeert als ze aan bepaalde eisen voldoen.
Zulke licenties heten dan officieel "OSI Certified OpenSource".

Voordelen van OpenSource software
Door de vrije beschikbaarheid van de broncode kan iedereen bijdragen aan de verdere ontwikkeling van OpenSource.
Veel mensen doen dit dan ook.
Dit geeft een continue ontwikkel-cyclus waarmee de software in korte tijd snel wordt uitgebreid en verbeterd.

Deze vrije beschikbaarheid is ook een voordeel voor gebruikers.
Een gebruiker van OpenSource is niet afhankelijk van de oorspronkelijke auteur om bepaalde verbeteringen of uitbreidingen te realiseren.
Hij kan deze gewoon zelf maken.
Als de leverancier de ondersteuning stopt, kan de gebruiker de ontwikkeling overnemen of een andere leverancier zoeken.
Het feit dat de licentie gratis is, is natuurlijk ook interessant.

Risico's van OpenSource software
OpenSource kent enkele unieke risico's vanwege de eveneens unieke licentie-voorwaarden.
Voor bedrijven die gewend zijn aan traditionele licenties, kan het duur of lastig zijn om te zorgen dat ze zich eveneens houden aan OpenSource licenties.
Het negeren van OpenSource licentie-voorwaarden betekent dat de software zonder geldige licentie wordt gebruikt, wat kan leiden tot een rechtszaak of slechte publiciteit.

Zo is het vaak verplicht om de aanwezigheid van OpenSource te melden in de handleiding van het product.
Wie dit pas beseft nadat de handleidingen zijn gedrukt, heeft een probleem.
Sommige licenties eisen dat eigen uitbreidingen of verbeteringen aan OpenSource ook als OpenSource worden vrijgegeven.
Het bepalen wanneer iets nu precies een uitbreiding is kan een lastige zaak zijn.

Veel bedrijven zien deze eisen als een risico en proberen daarom het gebruik van OpenSource zoveel mogelijk te vermijden.
Dit is tegenwoordig echter geen realistische optie meer.
Het gebruik van OpenSource in commerciële producten wordt steeds populairder.
OpenSource negeren betekent dat een bedrijf zichzelf de toegang ontzegt tot software van hoge kwaliteit zonder licentiekosten.
Het gevolg is vertragingen en duurdere producten ten opzichte van de concurrent.

Soms is het commercieel simpelweg niet haalbaar om "bij te blijven" bij een OpenSource concurrent voor een zelf ontwikkeld stuk software.
De enige optie is dus met de risico's leren omgaan.

Uitgangspunten van OpenSource licenties
OpenSource software is vrij beschikbaar voor iedereen, inclusief broncode.
De licentie verleent iedereen toestemming om de broncode 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 de software, al dan niet in gewijzigde vorm, vrijelijk verspreid worden.
De auteur vraagt hier geen geld voor.
De software staat gratis beschikbaar op Internet.
Sterker nog, iemand die de OpenSource software van een ander verkoopt, mag de opbrengst geheel zelf houden.

Geen contract nodig
Bij OpenSource licenties is het niet nodig om expliciet een contract te tekenen met de auteur.
De software kan legal worden gedownload, en de licentie-voorwaarden zitten bij de software.
Wie vervolgens de voorwaarden onaanvaardbaar vindt, hoeft zich er niet aan te houden - maar mag de software dan niet aanpassen of verder verspreiden.

OpenSource licentiecategoriën
Er zijn ongeveer 40 verschillende OpenSource licenties met elk hun eigen regels en voorwaarden.
Deze kunnen worden onderverdeeld in drie categorieën:
Een OpenSource licentiepolicy kiezen
Het lijkt nu voor de hand te liggen om alleen het gebruik van free-for-all OpenSource toe te staan, en de andere twee vormen buiten te sluiten of aan strenge regels te onderwerpen.
Echter, op ongeveer 65% van alle OpenSource is de GPL van toepassing, terwijl slechts ongeveer 15 procent onder een free-for-all licentie beschikbaar is.
Wie gebruik wil maken van OpenSource, kan dus niet om share-alike en keep-open licenties heen.
Goede regels zijn nodig, maar deze moeten gaan over waar en niet of OpenSource mag worden gebruikt.

Interpretatie van licentievoorwaarden
Het interpreteren van OpenSource licenties kan lastig zijn.
Deze licenties wijken op belangrijke punten af van traditionele, "gesloten" licenties of EULAs.
Dit kan voor onverwachte problemen zorgen voor ontwikkelaars of verspreiders wanneer ze zich pas na verspreiding de consequenties van deze voorwaarde realiseren.

OpenSource licentievoorwaarden hebben bijvoorbeeld vaak de eis dat je gebruik van de software moet melden in de documentatie.
Meestal moet zelfs de hele licentie-tekst worden afgedrukt.
De broncode moet worden meegeleverd, of op zijn minst worden nagestuurd naar mensen die daar om vragen.
En in sommige gevallen moet bepaalde eigen software ook OpenSource gemaakt worden als deze afgeleid is van OpenSource.

Licentie-FAQs gebruiken
Bij sommige OpenSource licenties is extra uitleg beschikbaar, meestal in de vorm van een FAQ of VVV (veel voorkomende vragen).
IBM biedt bijvoorbeeld antwoord op veel gestelde vragen over haar IBM Public License.
De FSF doet hetzelfde voor de GPL en heeft bovendien een apart e-mailadres ingesteld voor specifieke vragen.
Antwoorden uit dergelijke documenten zijn nuttig maar niet zaligmakend.
Als de auteur van de software iemand anders is dan de opsteller van de licentie, dan is de interpretatie van de opsteller minder belangrijk dan de interpretatie van de auteur.
En alleen die laatste kan uitzonderingen verlenen op de plichten uit de licentie.

Soms maakt de auteur zelfs fouten bij de interpretatie van zijn eigen licentie.
Een veel voorkomend voorbeeld is "Deze software valt onder de GPL en mag dus niet commercieel gebruikt worden".
De GPL staat echter wel degelijk commercieel gebruik toe, zolang de broncode maar wordt meegeleverd en men zich verder ook aan de GPL houdt.
Dus wat bedoelde de auteur nu?
Gebruikte hij "commercieel" in de zin van "gesloten, zonder broncode mee te leveren" of wilde hij expliciet commercieel gebruik van de software verbieden?
Het is daarom verstandig om voorzichtig te zijn bij het interpreteren van OpenSource licentie-voorwaarden.
De "geest" van de licentie en de dagelijkse praktijk is vaak belangrijker dan de letterlijke tekst.

De belangrijkste licentie-voorwaarden zijn: Naamsvermelding van de auteur
In vrijwel alle gevallen is het verplicht om de auteur van de OpenSource software te noemen wanneer diens software wordt gebruikt.
Dit zou geen probleem moeten zijn, al is het soms lastig om te achterhalen welke auteurs nu precies genoemd moeten worden of op welke manier.
Soms staat dit in de documentatie of op de website.
In andere gevallen is een e-mail naar een van de auteurs de oplossing.

Belangrijk daarbij is wel om de verschillende delen van de software van elkaar te scheiden.
Zeg dus niet zomaar "Copyright Joe Hacker" als er een stukje software van Joe Hacker gebruikt wordt.
Dat suggereert dat de hele software van hem komt.
"Portions copyright Joe Hacker" of zelfs een precieze omschrijving van welke delen is een betere aanpak.

De licentie kan eisen stellen aan waar deze naamsvermelding moet gebeuren: in de documentatie, bij het opstartscherm of in een "About" scherm.
De laatste twee gevallen zijn natuurlijk lastig als de software wordt gebruikt in een product zonder scherm (bijvoorbeeld embedded software).
De auteur vragen om een uitzondering is dan de enige mogelijkheid.

Afdrukken van licentievoorwaarden
Naast de eis om de naam van de auteur te vermelden, is het in veel gevallen ook verplicht om de tekst van de licentie en de uitsluiting van garantie zelf te reproduceren.
Dit mag meestal in de documentatie of handleiding.

De tekst moet letterlijk overgenomen worden.
Ook hier is het verstandig om deze vooraf te laten gaan door een duidelijke verklaring dat de licentie alleen betrekking heeft op bepaalde delen en niet op het hele product.
"Deze software bevat de ABC bibliotheek geschreven door Joe Hacker.
Op deze bibliotheek zijn de volgende voorwaarden van toepassing:"

Verspreiden van broncode
OpenSource licenties zoals de GPL eisen dat de broncode van het werk beschikbaar gesteld wordt wanneer het werk wordt verspreid.
De eenvoudigste manier om aan deze eis te voldoen is door die broncode te bundelen met de software op de CD ROM.
Als de software via een website beschikbaar wordt gesteld, dan is een extra download-link voor de broncode zo gelegd.
Wel moet de download van de broncode op de site van de verspreider zelf aangeboden worden.
Het is niet genoeg om simpelweg te verwijzen naar de oorspronkelijke lokatie.
Als deze immers gesloten wordt, dan wordt niet langer voldaan aan de licentie-eis dat de broncode aangeboden moet worden.

Als het niet wenselijk of haalbaar is om de broncode elke keer mee te leveren, dan is er soms een alternatief beschikbaar.
Dat hangt echter sterk af van de precieze voorwaarden uit de OpenSource licentie in kwestie.
Zo zegt de Mozilla Public License dat het ook toegestaan is om in de documentatie de URL (het webadres) te vermelden waar de broncode kan worden gedownload.

De GPL en LGPL bieden een vergelijkbare optie: in plaats van de broncode mag ook een schriftelijk aanbod gedaan worden om iedereen die er om vraagt, broncode op te sturen.
Dit aanbod moet minstens drie jaar geldig zijn.
Bij deze licenties is het niet voldoende om simpelweg te verwijzen naar een website!
Er moet echt een postadres worden genoemd, en de broncode moet dan ook op CD-ROM of vergelijkbaar medium worden opgestuurd.
Het vermelden van een webadres kan natuurlijk het aantal verzoeken per post wel verminderen.

Geen garanties
Vrijwel alle OpenSource software komt zonder enige vorm van garantie.
Hooguit wordt er een enkele keer gezegd dat de auteur verklaart dat hij inderdaad de auteur is (en de code dus niet "geleend" heeft van elders).
Deze uitsluiting van garantie betekent dat de ontvanger/gebruiker de auteur niet aansprakelijk kan houden voor welke schade dan ook.

Uitsluitingen als deze zijn niet uniek voor OpenSource.
Wie software koopt in de winkel, kan de leverancier ook zelden aansprakelijk stellen voor schade.
Maar wie een bedrijf inhuurt om software te laten ontwikkelen, kan de leverancier normaal wel aansprakelijk stellen voor schade of fouten.
En daar wijkt OpenSource dus af van de norm.

Herkennen van OpenSource
Een klein maar toch significant risico is dat software niet altijd met de juiste licentie-voorwaarden aangeboden wordt.
Er zijn gevallen bekend waarin verspreiders "vergaten" de licentie bij te sluiten, of de software op een site plaatsten met de vermelding dat deze vrij van auteursrechten was.
Anderen verspreiden de software zonder zich aan de licentie te houden, bijvoorbeeld door de broncode niet mee te leveren.
De ontvanger van dergelijke software kan deze dan niet verder verspreiden.

Daarnaast kan de licentie van de software worden gewijzigd bij het uitbrengen van een nieuwe versie.
Dit moet dus elke keer opnieuw gecontroleerd worden.
Als de licentie bijvoorbeeld wijzigt van een eenvoudige BSD licentie naar de GPL, dan moet nu ineens worden voldaan aan de veel uitgebreidere verplichtingen van de GPL.

En als laatste, als ontwikkeling van software wordt uitbesteed bij een derde, is er de mogelijkheid dat die leverancier OpenSource in het resultaat verwerkt heeft maar dit niet meldt.
In dat geval is de verspreider aansprakelijk voor de schending van de OpenSource licentie.
Of dergelijke schade verhaald kan worden op de leverancier, is dan nog maar de vraag.

Bron: Iusmentis door ICT-jurist Arnoud Engelfriet op 07 juni 2017.

Valid HTML 5.0 Valid CSS
© 2018 dwarsligger.org/
overname met bronvermelding is toegestaan.
Pagina grootte: 25347 bytes.
Gemaakt met Ron's Webber versie 180106b.
Pagina gemaakt in 0.068 seconden,
Pagina aangepast op 11 January 2018 20:59:45.