Gepubliceerd op 8 november 2025 · Laatst bijgewerkt op 14 oktober 2026
Open source software mag u als bedrijf vrij gebruiken, maar de licentie bepaalt onder welke voorwaarden u de software mag aanpassen en verspreiden. De belangrijkste uitzondering op die vrijheid zit bij copyleft-licenties zoals de GPL: verspreidt u software die op GPL-code is gebaseerd, dan moet u de broncode van dat werk onder dezelfde licentie beschikbaar stellen.
Die verplichtingen gelden dus niet zomaar voor al uw software. Ze ontstaan pas bij verspreiding, en alleen voor het werk dat op de open source code voortbouwt. In dit artikel leest u hoe open source licenties naar Nederlands recht werken, welke soorten er zijn en hoe u de risico’s beheerst.
Inhoudsopgave
Wat is een open source licentie naar Nederlands recht?
Een open source licentie is een licentie van de auteursrechthebbende die u toestemming geeft om software te gebruiken, te wijzigen en te verspreiden. Software is in Nederland beschermd door de Auteurswet; computerprogramma’s worden in artikel 10 lid 1 onder 12 Aw uitdrukkelijk genoemd.
Zonder licentie mag u een programma niet verveelvoudigen of openbaar maken. De open source licentie geeft die toestemming, maar alleen als u de voorwaarden naleeft. Naar Nederlands recht wordt een licentie in het algemeen gezien als een overeenkomst. Houdt u zich niet aan de voorwaarden, dan kan de rechthebbende u aanspreken wegens wanprestatie (artikel 6:74 BW) en, als u buiten de licentie handelt, wegens inbreuk op zijn auteursrecht. Meer over licenties in het algemeen leest u in ons artikel hoe een licentieovereenkomst uw IP laat werken.
Welke soorten open source licenties zijn er?
Er zijn grofweg twee soorten: permissieve licenties met weinig voorwaarden en copyleft-licenties die eisen dat afgeleide werken onder dezelfde licentie worden verspreid. Daartussen zitten zwakke copyleft-licenties.
| Soort | Voorbeelden | Belangrijkste voorwaarden |
|---|---|---|
| Permissief | MIT, BSD, Apache 2.0 | Copyrightvermelding en licentietekst meeleveren; bij Apache 2.0 ook wijzigingen vermelden en het NOTICE-bestand meeleveren |
| Zwakke copyleft | LGPL, MPL 2.0 | Wijzigingen in de open source component zelf onder dezelfde licentie; uw eigen code die de component alleen gebruikt, valt daar in beginsel buiten |
| Sterke copyleft | GPL v2, GPL v3 | Bij verspreiding van een werk dat op de code is gebaseerd: het hele werk onder de GPL en broncode beschikbaar stellen |
| Netwerk-copyleft | AGPL v3 | Als GPL v3, maar ook als gebruikers via een netwerk met de gewijzigde software werken |
Wanneer moet u onder de GPL uw broncode vrijgeven?
Alleen als u een werk dat op GPL-code is gebaseerd verspreidt, bijvoorbeeld door software aan klanten te leveren of in een apparaat in te bouwen. Intern gebruik binnen uw eigen organisatie is geen verspreiding en brengt geen plicht mee om broncode te delen.
Ook het aanbieden van software als online dienst (SaaS) is onder de GPL geen verspreiding. Daarvoor is juist de AGPL bedacht: wie AGPL-software wijzigt en via een netwerk aan gebruikers aanbiedt, moet die gebruikers toegang geven tot de broncode van de gewijzigde versie. Verder geldt de copyleft alleen voor het werk dat op de GPL-code voortbouwt. Programma’s die alleen naast elkaar draaien, zoals een eigen applicatie op een Linux-server, vallen daar in beginsel niet onder. Waar precies de grens van een afgeleid werk ligt, is technisch en juridisch niet altijd scherp; laat dat per geval beoordelen.
Kunnen verschillende licenties botsen?
Ja. Combineert u code onder licenties met tegenstrijdige voorwaarden in één werk, dan kunt u niet aan beide voldoen. Dat heet licentie-incompatibiliteit.
Een bekend voorbeeld: code onder Apache 2.0 mag worden gecombineerd met GPL v3-code, maar volgens de Free Software Foundation niet met code die alleen onder GPL v2 valt. Ook propriëtaire code combineren met GPL-code in één verspreid werk is problematisch. Breng daarom vóór het combineren in kaart welke licenties in uw software zitten.
Wat zijn de gevolgen als u een licentie schendt?
De rechthebbende kan een verbod vorderen, schadevergoeding (artikel 27 Aw) en afdracht van de winst die u met de inbreuk maakte (artikel 27a Aw). In een procedure over intellectueel eigendom moet de verliezende partij bovendien in beginsel de volledige proceskosten betalen (artikel 1019h Rv).
Onder de GPL v2 vervalt uw licentie automatisch bij een schending. De GPL v3 is milder: herstelt u de schending, dan krijgt u uw rechten terug. Bij een eerste melding van de rechthebbende gebeurt dat definitief als u binnen 30 dagen na de melding herstelt. In de praktijk zijn de grootste risico’s een gedwongen productstop, een verplichting tot het vrijgeven van broncode als u het afgeleide werk wilt blijven verspreiden, en problemen bij een due diligence. Lees ook ons artikel over intellectueel eigendom bij een bedrijfsovername.
Hoe houdt u open source compliance op orde?
Houd een actueel overzicht bij van alle open source componenten en hun licenties, een zogeheten software bill of materials (SBOM). Leg daarnaast in een intern beleid vast welke licenties ontwikkelaars zonder overleg mogen gebruiken.
- Laat scantools de licenties in uw codebasis en die van leveranciers vaststellen.
- Stel per licentiesoort een regel op: permissief vrij, copyleft alleen na toetsing.
- Lever bij verspreiding de vereiste licentieteksten, copyrightvermeldingen en, waar nodig, broncode mee.
- Neem in contracten met softwareleveranciers garanties op over gebruikte open source componenten.
Voor fabrikanten van producten met digitale elementen wordt een SBOM bovendien verplicht onder de Europese Cyber Resilience Act; de meeste verplichtingen daaruit gelden vanaf 11 december 2027. Bij clouddiensten is ook de verhouding met uw leverancier van belang; zie ons artikel over de risico’s van SaaS-contracten.
Wat kunnen wij voor u doen bij open source licenties?
Onze advocaten ICT-recht adviseren bedrijven over het gebruik en de verspreiding van open source software.
- Wij beoordelen welke verplichtingen uit de licenties in uw software volgen bij levering aan klanten of als online dienst.
- Wij toetsen of een combinatie van licenties verenigbaar is en welk werk onder een copyleft-licentie valt.
- Wij stellen een intern open source beleid op en controleren uw licentievermeldingen.
- Wij nemen garanties over open source op in uw contracten met leveranciers en afnemers.
- Wij begeleiden u bij een sommatie van een rechthebbende en beoordelen herstel binnen de termijn van de GPL v3.
Samengevat
- Software is beschermd door de Auteurswet; een open source licentie geeft gebruiksrechten onder voorwaarden.
- Permissieve licenties vragen vooral om vermelding van auteursrecht en licentietekst.
- De GPL verplicht alleen bij verspreiding van een afgeleid werk tot het vrijgeven van broncode; intern gebruik en SaaS vallen erbuiten, behalve onder de AGPL.
- Bij schending dreigen een verbod, schadevergoeding, winstafdracht en volledige proceskosten.
Veelgestelde vragen
Moet ik al mijn software openbaar maken als ik GPL-code gebruik?
Nee. De plicht geldt alleen voor het werk dat op de GPL-code is gebaseerd en alleen als u dat werk verspreidt. Andere programma’s en intern gebruik vallen erbuiten.
Mag ik open source software commercieel gebruiken?
Ja. Open source licenties staan commercieel gebruik toe, ook verkoop. U moet wel de voorwaarden van de licentie naleven, zoals vermelding van de auteursrechthebbende.
Geldt een Amerikaanse licentie als de GPL ook in Nederland?
Ja. Welk recht op de licentie van toepassing is, kan per geval verschillen, maar de licentievoorwaarden zijn ook in Nederland afdwingbaar. Het auteursrecht op de software geldt hier op grond van de Auteurswet en internationale verdragen.
Wat moet ik doen als ik een sommatie krijg wegens een licentieschending?
Neem de melding serieus en stel direct vast welke code en welke licentie het betreft. Onder de GPL v3 kunt u uw rechten definitief terugkrijgen als u een eerste schending binnen 30 dagen na de melding herstelt.
