Open source software, opgehelderde misvattingen en praktische handvatten

Door de NGB Werkgroep Digitalisering, op voorzet van mr. Maurits Meijboom. 

Voor veel bedrijfsjuristen valt het gebruik van Open Source Software ("OSS”) in hun organisaties in de afdeling ‘wat niet weet, wat niet deert’. Open source en OSS spelen echter een grote rol bij het gebruik en inzetten van software. Het gebruik van OSS is, net als bij commercieel aangeboden en gelicentieerde software, niet vrij van risico’s. Maar er is ook goed nieuws: tegenwoordig zijn deze risico’s als bedrijf een beter in kaart te brengen en daarmee beter te beheersen. Tijd dus om ons meer te verdiepen in Open Source Software! 

Dit artikel legt kort uit wat OSS is en benoemt de voornaamste juridische aspecten van OSS en de bijkomende risico’s. Vervolgens komen diverse tips aan bod die helpen om een beter beeld te krijgen van het gebruik van OSS binnen een organisatie om daarmee een aantal voorname risico’s uit de weg te gaan.

1. Wat is open source software

De term OSS wordt te pas en te onpas gebruikt en de betekenis vraagt oplettendheid. Bij juist gebruik betekent het dat de broncode (dat wil zeggen het door mensen leesbare deel van de computercode) vrij toegankelijk is. Deze OSS mag dus door iedereen worden gebruikt, vaak zonder dat er licentievergoedingen betaald hoeven worden. De filosofie achter OSS is oorspronkelijk geïnspireerd door het concept van vrijheid van eigendom en verzette zich tegen de beperkende aard van intellectuele eigendomsrechten. Het idee is dus dat de software vrij mag worden verspreid en iedereen het mag verbeteren of optimaliseren, waarna het vervolgens verder kan worden gedistribueerd. Dit resulteert in een voortdurende cyclus van open en gezamenlijke verbetering van de software.

OSS kan een vrij beschikbaar softwareproduct zijn. Denk bijvoorbeeld aan de Android- en Linux-besturingssystemen, de Mozilla Firefox-webbrowser, databasesoftware zoals MySQL en content managementsoftware als WordPress. Daarnaast worden OSS-elementen veelvuldig als bouwstenen gebruikt in de ontwikkeling van software. Een softwareontwikkelaar zal vaak online op zoek gaan naar standaard bouwstenen, dat wil zeggen stukken OSS-computercode, die kunnen worden gebruikt voor bepaalde functies die voor de software nodig zijn. Wel zo efficiënt: zo hoeft het wiel niet opnieuw te worden uitgevonden.

Het gebruik van OSS heeft naast de efficiëntie nog vele andere voordelen, waaronder (meestal) geen licentiekosten, lagere ontwikkelingskosten, flexibiliteit tussen softwareoplossingen en leveranciers, regelmatig (en vrij) beschikbare fixes en updates via de samenwerkende OSS-gemeenschap en het versnellen van software-releasecycli. Daarnaast maakt ook de enorme hoeveelheid beschikbare gerenommeerde OSS dat het gebruik daarvan een essentieel onderdeel is geworden van het hedendaagse softwareontwikkelingsproces. Maar liefst 90% van de respondenten van een in november 2019 door Gartner uitgevoerd onderzoek onder IT specialisten gaf aan in meer of mindere mate van OSS-componenten gebruik te maken.[1] OSS is dus zeer populair en wordt eigenlijk in de meeste organisaties gebruikt.

2. Juridische aspecten OSS

Er zit echter een addertje onder het gras. Een veel voorkomende misvatting is dat de vrije beschikbaarheid van OSS ook 'licentievrij' impliceert. Niets is minder waar: gebruikers van OSS zijn nog steeds onderworpen aan een softwarelicentie die moet worden nageleefd, net als gebruikers van commerciële software. Immers, zowel op commerciële software als OSS rusten auteursrechten. Dat de software vrij mag worden verspreid en dat de broncode vrij toegankelijk is, betekent dus niet dat de software niet (auteursrechtelijk) is beschermd. De OSS-licentie bepaalt onder welke voorwaarden de broncode vrij beschikbaar is, en soms of deze bij verspreiding of wijziging ook weer beschikbaar moet worden gesteld. OSS-licentiegevers gebruiken nog steeds het auteursrecht om het gedrag van gebruikers te beheersen. Echter, in plaats van het auteursrecht te gebruiken om te beperken wat een gebruiker anders zou kunnen doen (d.w.z. kopiëren of distribueren), gebruiken ze de bevoegdheden die ze hebben als auteursrechthebbenden om ervoor te zorgen dat de OSS 'vrij' blijft.  

Voor de gebruiker van software, maar nog meer voor de softwareontwikkelaar, valt het sterk aan te raden om het gebruik van OSS en de onderliggende licenties nauwlettend in de gaten te houden om zeker te zijn dat de desbetreffende OSS licentie het beoogde gebruik van het totaalproduct (waarin de OSS wordt opgenomen) toestaat. Er is immers een brede variatie aan OSS-licenties. Globaal kunnen de OSS-licenties worden onderverdeeld in 1) Free-for-all; waarbij de voornaamste eis is het noemen van de auteurs (o.a. MIT, BSD licenties), 2) Keep-open; waarvan alleen de wijzigingen aan de OSS zelf ook als open source moeten worden gepubliceerd (o.a. Linux), en 3) Share-alike; waarbij wijzigingen aan de OSS maar ook andere uitbreidingen van de OSS of zelfs de gehele software waarvan het onderdeel vormt moeten worden gepubliceerd (o.a. verschillende versies van GPL). Daarbij komt dat sommige licenties nog geen A4’tje in beslag nemen en andere licenties uitgebreide en complexe juridische documenten zijn.

De voornaamste vrees met betrekking tot het gebruik van OSS komt waarschijnlijk voort uit een concept dat bekend staat als 'Strong Copyleft' dat opduikt in sommige OSS-licenties. De term ‘Copyleft’ is een tegenhanger van ‘Copyright’ en houdt de plicht in een kopie van de source code vrij beschikbaar te stellen. En ‘Strong Copyleft’-licenties, ook wel bekend als 'virale' licenties, bepalen dat de voorwaarden die van toepassing zijn op de originele OSS worden geërfd door de gecombineerde software die is ontwikkeld met behulp van de originele OSS. In de praktijk betekent dit dat als een organisatie software wil distribueren die OSS-bouwblokken bevat, zij de broncode voor die software ‘vrij’ beschikbaar moet stellen onder de voorwaarden van die betreffende licentie. Dit dus mogelijk inclusief elementen van de code die zelfstandig door de organisatie zijn ontwikkeld. Software architectuur kan dit bezwaar ondervangen en gelukkig bevat veel OSS geen Strong Copyleft verplichtingen en worden deze bepalingen over het algemeen alleen geactiveerd als een licentiehouder de OSS distribueert; louter ‘intern’ gebruik binnen een organisatie zal derhalve meestal geen problemen en veroorzaken. Ook verschillen de voorwaarden per specifieke OSS-licentie. Zo bepalen sommige OSS-licenties bijvoorbeeld dat het beschikbaar stellen van software als een software-as-a-service (SaaS) geen 'distributie' van de software oplevert. Desalniettemin, als een organisatie met de gecombineerde broncode bijvoorbeeld een commercieel of concurrentievoordeel wil behalen, dan is het gebruik van OSS met een Strong Copyleft licentie af te raden.

Hoewel het dus niet waarschijnlijk is dat intern gebruik van OSS problemen zal opleveren, vergt ieder ander gebruik dat de toepasselijke licentievoorwaarden vanuit juridisch oogpunt -en in het licht van het beoogde gebruik- beoordeeld worden. De reden is dat als de OSS-licentie wordt geschonden, sprake is van een auteursrechtinbreuk waartegen kan worden opgetreden. Dit laatste gebeurt echter niet vaak: pasvorig jaar is in Nederland voor het eerst een vonnis gewezen t.a.v. OSS-licentie inbreuk.[2] Meestal is het dreigen met optreden of een sommatie al voldoende om het inbreukmakende gebruik te doen eindigen.

[1] Rechtbank Amsterdam (kortgedingvonins: Jelurida IP/Apolla Fintech), 22 september 2020, ECLI:NL:RBAMS:2020:4717. Zie ook W. Dammers, ‘’Niet noemen open source licentie blockchain is auteursrechtinbreuk’, Lawfox.nl, 15 oktober 2020.

[2]Gartner; D. Gardner, ‘Technology Insight for Software Composition Analysis’, Gartner Research (ID G00441603), November 2019.

Maurits Meijboom

mr. Maurits Meijboom

Naast de notoire Strong Copyleft OSS-voorwaarden kunnen er natuurlijk ook andere voorwaarden bestaan, zoals bijvoorbeeld de eis dat onder meer de naam van de ontwikkelaar dient te worden vermeld, dat wijzigingen die worden gemaakt als zodanig herkenbaar moeten zijn of dat de OSS niet voor commerciële doeleinden mag worden gebruikt.  

3. Implicaties gebruik OSS

Iedereen zal begrijpen dat bij het gebruik van OSS-bouwstenen die op vele verschillende manieren worden gecombineerd bij de ontwikkeling van software, een ingewikkeld technisch vlechtwerk ontstaat met complexe interacties en afhankelijkheden. Daarbij kunnen de juridisch implicaties van de toepasselijke licentievoorwaarden minstens zo complex zijn.

Om achteraf te bepalen welke OSS-licenties en voorwaarden van toepassing zijn, zal de softwarecode moeten worden geanalyseerd om de OSS te identificeren, de wijze waarop OSS componenten samenwerken in kaart moet worden gebracht en vervolgens de toepasselijke OSS-licenties worden achterhaald. Dit vergt gedetailleerde praktische kennis van de code in kwestie en hoe het afgeleide werk of de aanpassing van de OSS tot stand is gekomen. Er is hiervoor ook een aantal praktische softwaretools beschikbaar (zie de tips hieronder).

De uitdaging is dat voor veel potentiële gebruikers, althans de juristen die er iets van moeten vinden, de relatief zeldzame en vermijdbare effecten van (Strong) Copyleft-licenties maakt dat zij huiverig zijn voor het gebruik van OSS in het algemeen. Dit is een houding die – gezien de vele voordelen van het gebruik van OSS – over het algemeen niet houdbaar is. De enige optie is om met de risico’s te leren omgaan. Bij het gebruik van een OSS-oplossing of softwareoplossing die OSS bevat, moet je erop voorbereid zijn dat daarbij zeer weinig tot geen garanties zullen (kunnen) worden gegeven. OSS is immers ook vrij van kosten en beperkte garanties spelen in zo ongeveer elke vorm van software een rol. Over het algemeen is vooral bij intern gebruik binnen een organisatie het risico van OSS zeer beperkt. Voor organisaties die OSS gebruiken voor software die zij vervolgens aan derde in licentie geven of door derden laten hosten, zal de uitdaging groter zijn. Er zal gezorgd moeten worden dat alle toepasselijke OSS-licenties worden nageleefd, dat deze niet conflicteren en dat - zoals ook bij andere software - de downstream-licentierechten die worden verleend (dat wil zeggen de rechten die door de oorspronkelijke OSS-licentiegever worden verleend) niet worden overschreden. In enkele gevallen zal dan naar aan andere oplossing dan het gebruik van de OSS moeten worden gekeken.

4. Tips bij het gebruik van OSS

Of je het nu eens bent met de opvattingen waarop de open source-filosofie gestoeld is of niet, de realiteit is dat je niet meer om het gebruik van OSS heen kunt.  Het zal daarom in ieder geval nodig zijn om een beeld te krijgen van welke OSS-licenties er in de organisatie worden gebruikt, en om duidelijk beleid op te zetten over wanneer, welke soorten OSS-licenties kunnen worden gebruikt. Een voordeel hierbij is dat veel IT’ers op de hoogte zullen zijn van (een deel van) deze problematiek en al waakzaam zijn in het gebruik van bepaalde OSS-licenties. Samenwerking met IT’ers wordt ook vaak herkend als de enige wijze om als organisatie het complexe samenstel van software en licentievoorwaarden effectief te hanteren. Dit zal ook helpen bij het opzetten van een aanpak om eventuele problemen te beheersen voordat ze zich voordoen.

Ten slotte nog een aantal tips:

  1. Presenteer jezelf als partner bij de IT-afdeling die toegevoegde waarde kan hebben voor de IT-afdeling waar het aankomt op begrip van de licentieovereenkomst en de impact daarvan op hun werk.
  2. Softwareafnemers doen er goed aan in kaart te brengen welke OSS-licenties van toepassing zijn op de software die zij afnemen, en of dit impact heeft op het beoogde gebruik en de rechten op de software.  
  3. Softwareontwikkelaars valt aan te raden een beleid op te zetten op wat voor manier welke OSS kan worden gebruikt
  4. Maak een lijst beschikbaar met OSS-licenties die zonder problemen kunnen worden gebruikt binnen jullie organisatie en zet samen met de IT-afdeling een proces op voor het gebruik op voor andere soorten OSS.
  5. Bij software die in licentie wordt gegeven of wordt ontwikkeld voor een andere partij, zal de jurist -in nauwe samenwerking met een IT-specialist- ervoor moeten zorgen dat duidelijk is welke OSS wordt gebruikt en dat de downstream-licentierechten de oorspronkelijke OSS-licenties niet overschrijden of daarmee conflicteren.    
  6. Het kan de moeite waard zijn om te investeren in een OSS management software zoals Black Duck, WhiteSource, FOSSA, JFrog en vele andere, die o.b.v. een scan van de sourcecode de gebruikte OSS en licentie kan identificeren.
  7. Verdiep je als jurist iets meer in de verschillende OSS licenties en voorwaarden, daarbij zijn websites als https://tldrlegal.com/ en https://choosealicense.com/licenses/ en Comparison of free and open-source software licences - Wikipedia erg nuttig.
  8. Regels over open source moeten niet gericht zijn op het verbieden daarvan, maar moeten onderdeel zijn van de strategie waarmee het bedrijf effectief gebruik van open source maakt.
  9. Technische keuzes kunnen juridische consequenties hebben, bijvoorbeeld dat de gehele software stack alleen als open source kan worden uitgebracht, daarom moeten bij een projectdefinitie niet alleen de technische maar ook de juridische eisen worden geformuleerd. Zo zal ook het beoogde (derde) gebruik, de OSS-componenten en daarop toepasselijke licenties in kaart moeten worden gebracht.
  10. Leun niet te veel (op bepaalde soorten) OSS voor strategische software of doe hierbij goed onderzoek naar de OSS-licenties en risico’s.

 

Dit is het derde artikel namens de NGB Werkgroep Digitalisering. Eerder verschenen artikelen over het gebruik van elektronische handtekeningen en over risicobeperking bij contracteren met startups.