Open source software

 in IT-recht

Open source software is vaak gratis, maar dat wil niet zeggen dat er voor het gebruik ervan geen regels zijn. Integendeel, er zijn talloze open source licenties waarin vastgelegd is wat wel en niet mag met open source software.

Het verschil tussen open source software en gesloten (proprietary) software is de licentie. Een open source licentie geeft de gebruiker veel vrijheden waar een licentie voor proprietary software deze juist niet geeft. Kenmerkend voor open source softwarelicenties is dat de software ter beschikking wordt gesteld onder voorwaarden die het vrijwel iedereen toestaan de software te gebruiken, aan te passen en te verspreiden.

copyleftHierna zullen de voornaamste eigenschappen van enkele veel voorkomende open source licenties worden besproken. Er zijn grofweg drie vormen van open source licenties te onderscheiden:

  • Copyleft licenties
  • Non copyleft licenties
  • Beperkt copyleft licenties

Copyleft licenties 

Voorbeelden: GNU General Public License 2.0 en GNU General Public License 3.0

Copyleft licenties hebben als uitgangspunt dat het iedereen vrij moet staan om open source software vrij en naar eigen inzicht te gebruiken, verder te ontwikkelen en de programma’s ontwikkeld met behulp van open source software verder te verspreiden. Als tegenprestatie moet de licentienemer, wanneer deze aanpassingen van de open source software verspreidt, deze aanpassingen ook als open source verspreiden. Kort gezegd houdt dit in dat bij distributie van een met behulp van open source software ontwikkeld programma, de broncode van dit programma, inclusief de gemaakte aanpassingen, ter beschikking moeten worden gesteld onder dezelfde voorwaarden als de open source software zelf en zonder verdere beperkingen. Een aanvullende vergoeding vragen voor het gebruik van deze broncode is niet toegestaan.

General Public License 2.0 (GPL 2.0)

Over de GPL 2.0 bestaat onduidelijkheid met betrekking tot de virale werking van deze licentie. Deze virale werking zou inhouden dat wijzigingen, aanpassingen en afgeleide werken altijd onder dezelfde licentie zouden moeten worden gedistribueerd. De virale werking zou ervoor zorgen dat een oorspronkelijk proprietary programma dat via een koppeling gebruik maakt van open source software zelf ook onder de werking van het GPL 2.0 zou vallen waardoor de broncode van het proprietary programma ook zou moeten worden vrijgegeven.

Allereerst moet worden opgemerkt dat het niet per definitie verplicht is software afgeleid van of ontwikkeld met behulp van GPL 2.0 open source software te distribueren. De licentie treedt pas in werking zodra software op de markt wordt gebracht. De licentie verplicht een gebruiker echter niet om de software daadwerkelijk te verspreiden. Bovendien strekt te licentie zich in mijn ogen niet uit over dynamisch gekoppelde en niet afgeleide software. Het virale effect doet zich wel voor in het geval van statisch linken.

Er zijn ook stromingen, waaronder de opstellers van de GPL 2.0 zelf, die verdedigen dat het combineren of het laten samenwerken van proprietary software met open source software met copyleft licentie wel tot gevolg heeft dat het proprietary programma als open source moet worden vrijgegeven. Zowel statisch als dynamisch linken heeft volgens hen tot gevolg dat de licentie op de proprietary software komt te rusten.

In de GPL versie 3.0 wordt aan deze onduidelijkheid definitief een einde gemaakt. In artikel 5 van deze versie wordt aangegeven dat combinaties van GPL  software met andere programma’s niet tot resultaat hebben dat de GPL licentie van toepassing is op die andere programma’s als geheel.

Non copyleft licenties

Voorbeelden: BSD license, MIT license, Apache license

Tegenhanger van de copyleft licenties zijn de non copyleft licenties. Deze licenties hebben ook als uitgangspunt dat het iedereen vrij moet staan om open source software vrij en naar eigen inzicht te gebruiken, verder te ontwikkelen en de programma’s ontwikkeld met behulp van open source software verder te distribueren.

Non copyleft licenties verlangen hiervoor echter niet de tegenprestatie die copyleft licenties wel eisen. Non copyleft licenties laten de gebruiker vrij om zelf de voorwaarden waaronder hij de software en aanpassingen verspreidt te bepalen. Software met een non copyleft licentie kan daarom zonder moeite worden opgenomen in proprietary software. Het is ook niet verplicht om de broncode openbaar te maken bij een verdere verspreiding. Hierdoor zijn copyleft licenties zeer geschikt voor gebruik in en de ontwikkeling van proprietary software.

Veelal zijn de enige eisen van een non copyleft licentie dat het copyright notice en de uitsluiting van aansprakelijkheid van de eerdere auteurs gehandhaafd blijft.

BSD licenties

De BSD licenties zijn veel voorkomende non copyleft licenties. De er bestaan verschillende vormen van de BSD licenties waarvan de twee clausule en de drie clausule variant het meest gebruikt worden. Eis van alle BSD licenties is dat in de bron en/of de objectcode de licentietekst moet worden opgenomen. Daarnaast is in alle BSD licenties een uitsluiting van aansprakelijkheidvoor de voorgaande auteurs en licentiegevers opgenomen. De drie clausule variant verbiedt bovendien het gebruik van de naam of de namen van de oorspronkelijke auteurs om de ontwikkelde software te promoten.

MIT licentie 

Deze licentie vereist ook dat de licentietekst wordt opgenomen in de software en kent ook een uitsluiting van aansprakelijkheid van voorgaande auteurs en licentiegevers.

Apache licentie

De Apache licentie is iets uitgebreider dan de BDS en MIT licenties. Deze licentie geeft toestemming de software te gebruiken, aan te passen en te verspreiden. De licentie kent een duidelijke definitie van afgeleid werk en hiermee worden geen werken bedoeld welke lost te koppelen zijn van of slechts linken naar de open source software.

Verspreiding is toegestaan zolang de licentietekst wordt meegeleverd en gemaakte aanpassingen een melding bevatten waarin staat door wie en wanneer de aanpassing is aangebracht. Gemaakte aanpassingen mogen onder eigen licentievoorwaarden worden verspreidt. Ook de Apache licentie kent de uitsluiting van aansprakelijkheid van de voorgaande auteurs en licentiegevers.

Beperkt copyleft licenties

Voorbeelden: Mozilla Public License, LPGL 2.1

Beperkt copyleft licenties zijn een tussenvorm van de eerste twee categorieën open source licenties. Kenmerkend voor deze licenties is dat zij wel een copyleft bepaling bevatten, maar dat de reikwijdte van deze bepaling beperkt is. Dikwijls ziet de copyleft bepaling alleen toe op de code en aanpassingen van code welke al onder de licentie valt. Bovendien ontbreekt het mogelijke virale effect van copyleft licenties doordat er gedetailleerder en duidelijker wordt geformuleerd.

Mozilla Public License (MPL)

De copyleft voorwaarde van de MPL is slechts van toepassing op zogenaamde covered code. Covered code is code die is opgenomen in bestanden die al code bevatten die onder de MPL valt. Aanpassingen van covered code zijn ook automatisch covered code. Code die niet is opgenomen in die bestanden valt niet onder de copyleft voorwaarden, ook niet als deze deel uitmaken van één en hetzelfde programma. Het opnemen van covered code in een programma met andere licentievoorwaarden is uitdrukkelijk toegestaan zolang de verspreiding maar in overeenstemming is met de artikelen 3.1 tot en met 3.5 van de MPL en duidelijk wordt gemaakt dat de broncode van de covered code beschikbaar is onder de voorwaarden van de MPL.

Doordat de definitie van covered code duidelijk is, is goed vast te stellen welke code wel en welke code niet onder de licentie valt. De onzekerheid die een mogelijk viraal effect met zich meebrengt wordt hierdoor weggenomen.

Lesser General Public License 2.1 (LGPL 2.1)

De LGPL 2.1 heeft als copyleft element dat zogenaamde librairies, inclusief hierop doorgevoerde wijzigingen en hiervan afgeleide librairies,  ook onder de LGPL voorwaarden verspreidt moeten worden.  Een library wordt gedefinieerd als:  ‘a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables’

Het is toegestaan om proprietary software te linken of te combineren met librairies en het geheel onder eigen licentievoorwaarden te distribueren. Voorwaarde is dan wel dat deze licentie het de gebruiker moet toestaan de librairies aan te passen en het gebruik hiervan onder de LGPL valt. De broncode van de librairies moet worden verspreid met de proprietary software.

Wanneer een library wordt gebruikt door middel van dynamisch linken kan de gebruiker een nieuwe library bouwen en het proprietary deel van de software daar naar laten verwijzen. Dit hoeft dan niet te betekenen dat de auteur van de gesloten software verplicht is om de broncode van deel vrij te geven. Van belang is wel dat wanneer er een excecutable ontstaat als gevolg van statisch linken dat dan de gehele executable onder de licentie valt.

Conclusie

Open source software wordt dikwijls als risicovol gezien en licenties voor open source software worden niet zelden over een kam geschoren. De werkelijkheid is echter dat er veel verschillende soorten open source licenties bestaan welke allemaal hun eigen kansen en risico’s met zich meebrengen. Het risico zit hem niet in de licentie zelf maar in het onvoldoende op de hoogte zijn van de inhoud van de licentie en de verplichtingen welke hieruit voortvloeien.

Dit artikel is bedoeld om een kort inzicht te geven in verscheidene open source software licenties en is uitdrukkelijk niet bedoeld als een uitputtend overzicht of advies. Voor een uitgebreid overzicht van open source licenties zie: http://www.opensource.org/licenses/alphabetical

Recente berichten
  • 21 november 2022

    Risicomanagement: voorkom uitval door burn-out

    Marion Hagenaars
    Mirjam Scheper
    Werkend Nederland heeft steeds meer te kampen met burn-out klachten. Dit kan leiden tot (langdurig) ziekteverzuim. Een hoofdpijndossier en kostenpost voor de werkgever. En daarnaast een peperdure levensles voor de werknemer. Uitval door burn-out klachten voorkomen is dan ook beter dan genezen. Maar hoe?
    Lees verder
  • 21 november 2022

    Disfunctioneren: doorgeschoten empowermentbeleid

    Marion Hagenaars
    Mirjam Scheper
    De voorwaarden voor ontslag bij disfunctioneren zijn in de wet duidelijk omschreven. Deze voorwaarden gelden ook als een werkgever een beleid voert dat niet gericht is op dossieropbouw met waarschuwingen en berispingen, maar op aanmoediging.
    Lees verder
  • 21 november 2022

    Monitoring e-mail werknemers: de voorwaarden

    Marion Hagenaars
    Mirjam Scheper
    Onrechtmatig verkregen bewijs door werkgevers brengt belangrijke risico's met zich mee. Dit blijkt ook uit een recente uitspraak van het Hof Arnhem-Leeuwarden. Wat zijn de voorwaarden voor vrije toegang tot de e-mailbox van een werknemer?
    Lees verder

Plaats een reactie

Top