NL EN
  • Home»
  • Weblog »
  • Risico analyse bij gebruik van open source software

Risico analyse bij gebruik van open source software

Vorige week behandelde ik de door de Australische overheid gepubliceerde vernieuwde richtlijnen voor  gebruik van open source software. Ik heb daarbij aangegeven in een tweede weblog bericht in te gaan op het Open Source Software Licensing Risk Framework, welke als bijlage is toegevoegd bij deze “Guide to Open Source Software for Australian Government Agencies”.

Dit document biedt een high-level overzicht van een aantal belangrijke aspecten die Australische overheidsinstellingen in overweging moeten nemen wanneer ze gebruik maken van open source software. Meer specifiek biedt het document inzicht in risico’s en compliance issues in situaties waarin open source software wordt aangepast, ontwikkeld of verspreid.

Het document is niet enkel relevant voor Australische overheidsinstellingen, maar ook voor ieder bedrijf dat open source software aanpast, ontwikkelt of verspreidt – gemakshalve noem ik beiden in dit blogbericht daarom “gebruiker”. In het navolgende zal ik de kern van dit document bespreken en dit in Nederlands rechtelijk perspectief plaatsen.

Achtergrond

Software kan auteursrechtelijk beschermd zijn. Dat betekent dat de auteursrechthebbende (hoofdregel: de maker) daarvan het exclusieve recht heeft om de software openbaar te maken en te verveelvoudigen. De auteursrechthebbende kan ook anderen toestemming geven om deze handelingen te verrichten door middel van een licentie. Ook open source licenties geven deze toestemming. Open source software kan dus – net als proprietary software – auteursrechtelijk beschermd zijn. Het verschil met proprietary licenties is dat open source licenties het de gebruiker toestaan om de software openbaar te maken en te verveelvoudigen, proprietary licenties beperken deze mogelijkheden meestal. Veel open source licenties staan het toe om (de broncode van de) software te bekijken, te gebruiken, te wijzigen en te verspreiden. Vrijelijk. Om die vrijheid te waarborgen, worden wel voorwaarden aan verbonden aan het verrichten van die handelingen, zodat ook anderen van die vrijheid gebruik kunnen blijven maken.

Net als bij proprietary licenties is het dus van belang om de voorwaarden van open source licenties na te leven. Doe je dat niet, dan heb je geen toestemming om de software openbaar te maken en/of te verveelvoudigen, en maak je dus inbreuk op de auteursrechten van de auteursrechthebbende. Met alle gevolgen van dien.

Om goed voor ogen te hebben welke voorwaarden op welke software van toepassing zijn, en hoe deze na te leven, is het van belang om een risico en compliance analyse te verrichten. Een compliance procedure kan hiervoor uitkomst bieden. Het is ieder bedrijf dat gebruik maakt van open source software aan te raden om in kaart te brengen van welke open source software gebruik wordt gemaakt, alsmede welke voorwaarden daarbij gelden en hoe deze software kan en mag worden gebruikt. Het raamwerk van de Australische overheid biedt hiervoor enkele handvatten.

Introductie in licentie risico’s

Zoals hierboven al aangegeven, kan door het niet naleven van de voorwaarden van een (open source) licentie inbreuk worden gemaakt op de auteursrechten van de auteursrechthebbende.

In Nederland hebben zich nog geen rechtszaken voorgedaan waarin open source licenties zijn getest. Het is dus nog de vraag of ze wel rechtsgeldig gehandhaafd kunnen worden op basis van bijvoorbeeld auteursrecht. Echter, in andere Europese landen en in de VS zijn meermaals juridische maatregelen genomen tegen distributeurs van open source software die de voorwaarden van open source licenties niet zijn nagekomen. Het is mijns inziens aannemelijk dat dit ook in Nederland kan gebeuren. Bovendien acht ik het aannemelijk dat open source licenties naar Nederlands recht rechtsgeldig kunnen zijn (zie bijvoorbeeld mijn bijdrage in het International Free and Open Source Software Law Book).

Het Australische document geeft terecht aan dat inbreuken op licentievoorwaarden niet altijd opzettelijk zijn: ze kunnen veroorzaakt zijn door een gebrek aan ‘governance’ ten aanzien van het gebruik van open source software binnen de onderneming van de gebruiker. Bovendien kan het zo zijn dat de gebruiker niet bewust is van acties die kunnen leiden tot een inbreuk op open source licenties. Het is daarom van (soms zelfs cruciaal) belang dat al het gebruik van open source software op gepaste wijze wordt vastgelegd, gemonitord en geëvalueerd. Richtlijnen voor het verkrijgen, ontwikkelen, verspreiden en gebruiken van open source software is daarom aan te raden.

Het document stelt dat de gebruiker in het algemeen bewust moet zijn van (i) het type licentie; en (ii) het beoogde gebruik. Mijns inziens is dit inderdaad een goed uitgangspunt voor een compliance procedure. Uitputtend kan het niet zijn, maar richtlijnen voor het meest voorkomende gebruik is aan te raden.

Type licentie

Open source licenties kunnen – high level – worden onderscheiden in het licht van mate van wederkerigheid (sterk, gemiddeld of weinig) en mate van beperkingen (beperkend, hybride, of toegeeflijk). Open source licenties zijn doorgaans sterk beperkend én sterk wederkerig of sterk toegeeflijk én weinig wederkerig.

Beoogd gebruik

Het doel van gebruik is met name van belang voor de vraag welke voorwaarden uit de licentie gelden. Wil de gebruiker de software intern gebruiken; verspreiden; wijzigingen toevoegen en intern gebruiken; of met wijzigingen verspreiden?

Gevolgen

Afhankelijk van bovenstaande uitgangspunten kan het zo zijn dat de gebruiker verplicht is om de (gewijzigde) broncode vrijelijk te verspreiden. In het algemeen geldt dat daarvoor is vereist dat:

-       de licentie een bepaling van wederkerigheid kent;

-       een ‘derivative work’ is gecreëerd; en dat

-       het ‘derivative work’ verspreid wordt.

Qua risico’s kan volgens het document het volgende onderscheid in hoofdlijnen als uitgangspunt worden genomen:

-       Sterke wederkerigheid  + verspreiding van een ‘derivative work’ = zeer hoog risico

-       Sterke wederkerigheid  + geen verspreiding van een ‘derivative work’ = gemiddeld risico

-       Gemiddelde wederkerigheid + verspreiding van een ‘derivative work’ =  hoog risico

-       Gemiddelde wederkerigheid + geen verspreiding van een ‘derivative work’ = laag risico

-       Weinig wederkerigheid + verspreiding van een ‘derivative work’ = laag risco

-       Weinig wederkerigheid + geen verspreiding van een ‘derivative work’ = zeer laag risico

Gebruikers zullen moeten nagaan of hun interne beleid, procedures en tools overeenstemmen met deze risico’s. Effectief gebruik daarvan is cruciaal om risico’s die gepaard gaan met open source software te managen.

Zodra derde partijen worden ingeschakeld voor de ontwikkeling van de software, spelen er nog meer risico’s. Het is aan te raden om daar contractueel goede afspraken over te maken.

Het document geeft vervolgens nog een tabel waarin voorbeelden van risico beperkende maatregelen worden besproken, om nakoming van (open source) software licenties in het algemeen na te gaan. Het gaat te ver voor de strekking van dit bericht om daarop in te gaan – ik verwijs de geïnteresseerde daarom gemakshalve naar het document (p. 29-30) of laat het mij even weten.



PAGINA DOORSTUREN

DEZE PAGINA IS SUCCESVOL DOORGESTUURD!

REACTIE (1)

Anastasia Da paxiao maandag 12 augustus 2013 17:23

hallo, meneer / mevrouw, er is business Ik wil dat we together.can je antwoord terug naar mij?
Thanks jouwe Anastasia.

EEN REACTIE PLAATSEN

UW E-MAIL ADRES WORDT NIET GETOOND AAN ANDERE BEZOEKERS.

  1. NAAM
  2. E-MAILADRES
  3. BERICHT
  4. WANNEER U DEZE REGEL KUNT LEZEN, VUL HET VOLGENDE VELD DAN NIET IN!
  5.