Open Source met een addertje onder het gras: Wat auteursplicht echt betekent

Open source betekent niet altijd "doe wat je wilt" Copyleft licenties (zoals GPL en AGPL) geven je de vrijheid om code te gebruiken en aan te passen op voorwaarde dat je jouw wijzigingen ook deelt. Als je die voorwaarde mist, kun je per ongeluk je hele product "openstellen". Hier volgt een duidelijke uitleg over wat auteursplicht is, waarom het belangrijk is en hoe je onaangename verrassingen kunt vermijden.

Open Source met een addertje onder het gras: Wat auteursplicht echt betekent

Auteursplicht in één zin

Auteursplicht betekent: "Je hebt vrijheid gekregen - geef het door." Als je code met auteursplicht gebruikt of aanpast in je product, moet je je resulterende code beschikbaar stellen onder dezelfde voorwaarden.

Zie het als een recept: je krijgt een pizzarecept, verbetert het en verkoopt je versie - maar je publiceert ook je bijgewerkte recept zodat anderen er ook van kunnen profiteren.

Waarom dit bestaat

In de jaren tachtig begonnen bedrijven software te sluiten die gebouwd was op gemeenschapswerk. Copyleft (via de GNU GPL) draaide het script om: je mag de code gebruiken en verbeteren, maar je verbeteringen blijven open voor iedereen. Dit principe hielp Linux, WordPress, VLC, Blender en nog veel meer groeien.

Zakelijke impact: wat gebeurt er eigenlijk

  • Als je een product distribueert dat GPL-code bevat, moet je je broncode beschikbaar stellen aan gebruikers onder de GPL.
  • Als je een netwerkdienst (SaaS) draait die AGPL code gebruikt, dan moet je je aangepaste broncode aanbieden aan gebruikers die er interactie mee hebben via het netwerk.
  • Als je alleen naar een LGPL bibliotheek linkt, hoef je meestal niet je hele app open te stellen, alleen je wijzigingen aan de bibliotheek zelf.

Waar hetop neer komt: sterke auteursplicht (GPL/AGPL) kan je app in open source "trekken" als je hem nauw genoeg combineert. Daarom geven veel commerciële producten de voorkeur aan permissieve licenties (MIT, BSD, Apache) in hun afhankelijkheidsbomen.

Soorten licenties - snelle duidelijkheid

Type licentieWat vereistGebruikelijke licentiesTypisch gebruik
Sterke auteursplichtCode verspreiden → bron van het hele gecombineerde werk delenGPL, AGPLGemeenschapsprojecten die verbeteringen open willen houden
Zwakke auteursplichtWijzigingen aan de bibliotheek delen; app kan gesloten blijvenLGPL, MPLHerbruikbare bibliotheken bedoeld voor brede toepassing
ToegestaanMededelingen bewaren; verder bijna alles doenMIT, BSD, Apache-2.0Commerciële apps, frameworks, interne tools

Concrete scenario's (dus het is niet abstract)

1) WordPress plugin onder GPL

Je koopt een premium plugin (GPL). Je kunt het op onbeperkte sites gebruiken en zelfs de code die je hebt ontvangen delen. Verkopers verkopen vaak diensten - automatische updates en ondersteuning - gekoppeld aan een licentiesleutel. De code moet werken zonder sleutels; de diensten kunnen beperkt zijn.

2) SaaS + AGPL afhankelijkheid

Je backend gebruikt een AGPL component. Omdat gebruikers via een netwerk communiceren met je dienst, vereist de AGPL dat je je aangepaste broncode aanbiedt aan die gebruikers. Veel SaaS producten vermijden om deze reden de AGPL.

3) Desktop applicatie + GPL bibliotheek

Als je een desktop app uitbrengt die een GPL bibliotheek bevat (en niet alleen dynamisch linkt op een duidelijk gescheiden manier), dan moet je waarschijnlijk de broncode van je app vrijgeven onder de GPL wanneer je binaries distribueert.

4) Een LGPL bibliotheek gebruiken

LGPL staat linken toe zonder je hele app te openen, maar je moet gebruikers toestaan om de LGPL component te vervangen of opnieuw te linken en wijzigingen die je aanbrengt aan die component te publiceren.

Wat gebeurt er als je auteursplicht negeert

  • Juridisch risico: schending van auteursrecht, takedown verzoeken, gedwongen openbaarmaking of schikkingskosten.
  • Operationele kosten: nood refactors om componenten te verwijderen/vervangen; vertraagde releases.
  • Reputatierisico: openbare nalevingsproblemen schaden het aannemen van personeel, partnerschappen en het vertrouwen van de gemeenschap.

Hoe veilig te blijven (snelle checklist)

  • Controleer de licentie voordat je installeert. Voeg geen onbekende GPL/AGPL deps toe aan commerciële of closed source producten.
  • Geef de voorkeur aan permissieve licenties (MIT/BSD/Apache) voor bedrijfskritische paden.
  • Documenteer je afhankelijkheidsboom. Houd een materiaallijst (SBOM) bij en bekijk transitieve deps.
  • Scheid diensten van code. Als je plugins/tools verkoopt, koppel je inkomsten dan aan ondersteuning/updates, niet aan het beperken van de code zelf.
  • Heb een terugvalplan. Als er een copyleft dep insluipt, weet dan naar welk alternatief je kunt overschakelen.

Niet anti-zakelijk-alleen duidelijke regels

Copyleft gaat niet over het blokkeren van inkomsten; het gaat over het beschikbaar houden van gemeenschapsverbeteringen. Als je strategie open samenwerking omarmt, beschermt auteursplicht je investering. Als je propriëtaire producten levert, behandel auteursplicht dan als een contract: begrijp het voordat je integreert.

Afhaalmaaltijd

Open source ≠ licentievrij. Auteursplicht geeft vrijheid met een voorwaarde: deel vooruit. Lees de licentie, kies afhankelijkheden bewust en je voorkomt de verrassing van "we moeten onze hele codebase openstellen".


Neem contact op

Een externe audit van je project nodig?

Vertel ons je context en het resultaat dat je wilt, en wij stellen de eenvoudigste volgende stap voor.

Door te verzenden ga je ermee akkoord dat we je gegevens verwerken om op je aanvraag te reageren en, indien van toepassing, precontractuele stappen te nemen op jouw verzoek (AVG art. 6(1)(b)) of op basis van ons gerechtvaardigd belang (art. 6(1)(f)). Deel geen bijzondere persoonsgegevens. Zie ons Privacybeleid.
Reactie binnen 1 werkdag.