“Software developer, let op de (open source) licenties die kleven aan dependencies”!

Na maanden van zwoegen - en meerdere malen de neiging hebben moeten onderdrukken om je laptop uit het raam te gooien -, is je nieuwe JavaScript project dan toch echt eindelijk klaar. Uiteraard heb je niet alle code zelf geschreven (waarom het wiel opnieuw willen uitvinden als het ook makkelijk kan?) en jouw project steunt dan ook op tientallen npm dependencies. Alhoewel je heus wel eens termen als “MIT-license” of “GPL-licence“ voorbij hebt zien komen, zegt het je allemaal eigenlijk niet zoveel. In deze blog leggen we je uit waarom het toch echt belangrijk is dat je even een kijkje neemt naar de licenties van jouw dependencies. Indien het bijvoorbeeld de bedoeling is dat jouw JavaScript project als “proprietary software” op de markt wordt gebracht, wil je liever geen gebruik maken van dependencies waaraan een “strong copyleft” licentie kleeft. In andere woorden: een “verkeerde” licentie van een dependency kan het je verdomd moeilijk maken om geld te verdienen met je software project.  

Het liefst check je natuurlijk alle relevante licenties voordat je project al helemaal af is (wel zo handig). Tegenwoordig zijn er gelukkig veel tools (zoals deze of deze) aanwezig die het je een stuk makkelijker maken om alle “dependencies licenties” op te sporen.

Wat zijn dependencies?

Voor de tech-leken onder ons toch even een korte introductie alvorens we de juridische kant belichten. Een ‘dependency’ (afhankelijkheid) is - in de wereld van programmeren - een apart programma of een stukje code dat nodig is om jouw software-programma te laten werken. De werking van jouw programma is dus afhankelijk (“dependent”) van andere stukjes software. Je kan natuurlijk zelf alle code schrijven die nodig is om jouw software te laten werken, maar in de praktijk gebeurt dit nog maar zelden. In plaats van “from scratch” te coderen, maken developers gebruik van stukjes code die al door andere developers zijn geschreven. Stel je eens voor dat je een e-mail applicatie wilt programmeren en (gelet op de nieuwe privacywetgeving) je het belangrijk vindt dat de berichten versleuteld (‘ecnrypted’) zijn. Je kunt natuurlijk zelf een manier proberen te verzinnen om dit te verwezenlijken, maar je kan ook gewoon gebruik maken van code die iemand anders al eens eerder heeft geschreven. Wel zo makkelijk, toch?

Veel developers maken voor hun software project gebruik van open source “dependencies”. Dit heeft een aantal redenen. Allereerst is open source software gratis beschikbaar en daardoor erg aantrekkelijk. Daarnaast speelt ook het gegeven dat de code “open” is (je kan de code gewoon inzien en lezen) een belangrijke rol. Je kunt zo zelf bekijken of de geschreven code wel klopt en geschikt is voor jouw project. Maar zoals we al eens eerder in een blog waarschuwden:

gratis betekent nog niet dat er geen regels zijn. Ook open source code geniet auteursrechtelijke bescherming en het is dan ook geen overbodige luxe om de licentievoorwaarden eens te bestuderen.

Auteursrecht op open source software

Again, ook open source software geniet auteursrechtelijke bescherming. Computerprogramma’s worden als ‘werk’ onder de Auteurswet (Aw) beschermd. De maker van software (de developer) heeft als auteursrechthebbende bepaalde rechten waarmee zijn positie als maker beschermd wordt. Zo biedt het auteursrecht de maker van een werk het alleenrecht om het openbaar te maken en / of te verveelvoudigen (exploitatierechten). Hiermee kan je als maker tegen derden optreden die zonder jouw toestemming gebruik maken van de door jou ontwikkelde software.

In een licentie kan je als auteursrechthebbende aan derden toestemming geven om jouw werk te mogen gebruiken. Ook bij open source software komen licenties om de hoek kijken. Voordat je besluit open source software te gebruiken, is het dus echt essentieel dat je even goed nagaat welke licentie op de software van toepassing is. Juist omdat de voorwaarden in open source licenties afwijken van die in ‘proprietary licenses’ kan je soms voor verrassingen komen te staan. Het is natuurlijk niet zonder reden dat sommige Open Source Licenties enigszins berucht zijn geworden door hun ‘copyleft-karakter’.

Code van anderen gebruiken? Check de licenties van jouw dependencies!

Oké, even terug naar jouw net afgeronde JavaScript project. Je denkt ongeveer tientallen dependencies te hebben gebruikt. Het “gebruiken” van 3rd party libraries gebeurt normaliter via “linking” (static linking vs dynamic linking). Laten we ervan uitgaan dat elke ‘library’ waarvan het functioneren van jouw programma afhankelijk is, een open source licentie heeft. Moet je je nu bezig houden met deze licenties? Antwoord: ja, in principe wel! Je maakt immers gebruik van auteursrechtelijk beschermd materiaal van een derde partij en moet hierbij de rechten en verplichtingen (licentievoorwaarden), zoals opgenomen in de bijbehorende licentie, gewoon respecteren.

Note: linking is op zichzelf niet voldoende om de licentievoorwaarden te “activeren”. Meestal is het zo dat de licentievoorwaarden pas hoeven te worden nageleefd op het moment dat er sprake is van “distributie” van de software.

Enfin, afhankelijk van het type licentie (permissive of met een copyleft-karakter), kan dit o.a. betekenen dat je:

  • Zorgvuldig een licentie moet uitkiezen voor jouw eigen project, welke niet conflicteert met de licentie(s) van jouw dependencies;

  • De namen van de auteurs van de dependencies moet vermelden (copyright notice);

  • De originele broncode van de dependencies beschikbaar moet stellen (soms inclusief jouw bewerkingen daarvan);

  • Jouw project onder dezelfde licentie als dat van een dependency moet verspreiden.


Tip: check dus onder welke licenties de dependencies die jij gebruikt zijn uitgegeven. Neem de licentievoorwaarden van deze verschillende licenties goed door en ga na of je actie moet ondernemen om aan deze voorwaarden te voldoen.