Er is een moment dat vroeg of laat in bijna elk grootschalig project komt. Iemand — meestal een jurist of een zenuwachtige inkoper — vraagt: „Onder welke licentie moet dit eigenlijk komen?"

Tot dan ging alles prachtig. Code geschreven, tests groen, repository gepusht. En plotseling discussiëren mensen over copyleft, patentclausules en afgeleide werken alsof alles daarvan afhangt.

Op een bepaalde manier hangt daar ook alles vanaf.

Licenties zijn geen formaliteiten. Ze zijn de spelregels waaronder software bestaat. Wie ze negeert speelt toch — volgens regels die iemand anders kiest.

Waarom er zoveel licenties zijn

Het korte antwoord: omdat vrije software twee bewegingen kende die nooit helemaal dezelfde waren.

Aan de ene kant Richard Stallman en de in 1985 opgerichte Free Software Foundation met een heldere ethische positie: software die je niet kunt bestuderen, wijzigen of herdistribueren, ontnemt haar gebruikers fundamentele vrijheden. Daaruit ontstond de GPL — sterk copyleft, besmettelijk, zonder compromissen.

Aan de andere kant de pragmatici uit de Berkeley-Unix-traditie en later de in 1998 opgerichte Open Source Initiative (OSI), die vrije software eerder als een efficiënt ontwikkelingsmodel beschouwden dan als een morele plicht. Daaruit kwamen de permissieve licenties — MIT, BSD — kort, liberaal, commerciëringsvriendelijk.

Tussen deze polen ontstond een spectrum. Daarbij kwamen advocaten, bedrijfsbelangen, patenten, compatibiliteitsnood en de constante drang om het wiel opnieuw uit te vinden. Vandaag lijst SPDX meer dan driehonderd geldige licentiecodes. Niemand kent ze allemaal. Dat hoeft ook niet. Maar iedereen zou de belangrijke moeten kennen.

Twee families, één kernvraag

In de kern beantwoordt elke licentie dezelfde vraag: Wat mag een ander met mijn code doen — en wat moet hij ervoor teruggeven?

Permissieve licenties geven bijna alles vrij. Gebruiken, wijzigen, verkopen, inbraaien in propriëtaire producten — zolang mijn naam in de copyrightvermelding blijft. Geef mij erkenning, hou de rest.

Copyleft-licenties eisen daarentegen wederkerigheid. Wie mijn code wijzigt en herdistribueert, moet zijn versies onder dezelfde licentie vrijgeven. Wat je ontvangt, geef je door.

Zwakke-copyleft-licenties zitten daartussenin: ze besmetten enkel de bibliotheek, niet het programma dat haar gebruikt. Een compromis dat bibliotheekauteurs beschermt zonder consumenten te vervreemden.

Met dit rooster laten de bekende licenties zich netjes ordenen.

De licenties die je moet kennen

MIT. De kortste serieuze licentie ter wereld. Ongeveer 170 woorden. Staat vrijwel alles toe, eist slechts de copyrightvermelding. React, Ruby on Rails, jQuery, Kubernetes-clientbibliotheken — allemaal MIT. Wie maximale verspreiding wil, kiest MIT.

BSD. Bestaat in drie relevante varianten. De 2-clausuleversie komt in de praktijk overeen met MIT. De 3-clausuleversie verbiedt bovendien gebruik van de auteursnaam om eigen derivaten te adverteren. De historische 4-clausulevariant eiste zelfs een vermelding in elke productadvertentie — wat bij honderden afhankelijkheden tot absurde copyrightvermeldingen leidde en BSD-code lange tijd onbruikbaar maakte binnen GPL-projecten. FreeBSD, nginx, PostgreSQL gebruiken BSD-varianten.

Apache 2.0. Het volwassen lid van de permissieve familie. Gepubliceerd in 2004, voegt MIT en BSD drie dingen toe die in de praktijk tellen: een expliciete patentverlening (wie code bijdraagt, verleent gebruikers zijn patenten), een retaliatieclausule (wie over patenten procedeert, verliest zijn rechten) en het bijhouden van een NOTICE-bestand voor attributies. Apache Kafka, de Kubernetes-kern, TensorFlow staan onder Apache 2.0. Vaak de beste keuze voor commerciële stacks.

GPL v2. Sinds 1991 de lijm van de Linux-kernel. Sterk copyleft: wie derivaten distribueert, moet ook hun volledige broncode onder GPL v2 vrijgeven. Bewust bondig, bewust zonder patentclausule. De beroemdste bepaling wordt „Liberty or Death" genoemd — als je niet aan de voorwaarden kunt voldoen, mag je helemaal niet distribueren.

GPL v3. Herzien in 2007 nadat patenten, DRM en vergrendelde apparaten („tivoisatie") nieuwe aanvalslijnen tegen vrije software hadden geopend. Voegde de patentverlening toe, eiste installatie-informatie voor apparaten, codificeerde anti-omzeilingsclausules en verbeterde compatibiliteit met andere licenties. Politiek omstreden, juridisch schoner. Veel vlaggenschipprojecten bleven op v2 (Linux), andere migreerden (Bash, GCC, Samba).

LGPL v2.1 en v3. De „Lesser"-varianten. Zwak copyleft voor bibliotheken: wie de bibliotheek wijzigt en herdistribueert, moet wijzigingen onder LGPL plaatsen — maar programma’s die slechts tegen de bibliotheek linken, mogen propriëtar blijven. De klassieke ruil: bescherm de bibliotheek, laat de consument vrij. glibc, GTK, Qt (tijdelijk) zijn LGPL.

MPL 2.0. De huislicentie van Mozilla, januari 2012. Zwak copyleft op bestandsniveau: wie afzonderlijke MPL-bestanden wijzigt en herdistribueert, moet die bestanden onder MPL vrijgeven — de rest van een programma mag propriëtar blijven. Heldere formulering, pragmatisch, populair bij bedrijfsconsortia. Firefox, Thunderbird en talrijke Rust-crates gebruiken MPL.

AGPL v3. De netwerk-GPL. Sluit de zogenaamde ASP-loophole: klassiek copyleft treedt pas in bij distributie van software. Wie haar echter alleen als online dienst aanbiedt, distribueert niets — en was tot dusver geen broncode verplicht prijs te geven. AGPL draaide dat om: netwerkgebruik zelf activeert de prijsgevingsplicht. Geliefd bij SaaS-aanbieders die concurrenten willen weerhouden ongevraagd hun werk te hosten. Mastodon, Nextcloud, Plausible Analytics, MinIO.

EPL. De Eclipse Public License, geworteld in IBM-traditie, momenteel in versie 2.0. Zwak copyleft zoals MPL, met duidelijke patentverlening en expliciete commerciëringsvriendelijkheid. Eclipse IDE, Jakarta EE, de meeste Java-stichtingsprojecten, Adoptium/Temurin-JDK’s. Vaak het pragmatische alternatief wanneer GPL commercieel riskant voelt maar BSD te permissief lijkt.

Unlicense en CC0. De radicalen. Beide doen volledig afstand van auteursrecht — voor zover dat in sommige rechtsgebieden mogelijk is. Unlicense (2010) richt zich direct op software, CC0 (2009, Creative Commons) oorspronkelijk op data, kunstwerken en teksten. Beide delen een zwakte: waar het auteursrecht onvervreemdbaar is (Duitsland bijvoorbeeld), blijft juridische onzekerheid bestaan. Bovendien bevat CC0 geen patentclausule. Voor robuuste productiesystemen is MIT daarom meestal aan te bevelen boven CC0.

Wat licenties beperken of mogelijk maken

Concreet sturen licenties vijf assen:

  1. Gebruik — Mag ik dit commercieel inzetten? Bij alle hier besproken licenties: ja.
  2. Wijziging — Mag ik de code aanpassen? Ja, overal.
  3. Distributie — Onder welke voorwaarden? Hier scheurt de kudde.
  4. Patenten — Krijg ik een expliciete patentverlening? Slechts Apache 2.0, GPLv3, MPL 2.0, EPL 2.0, AGPL v3.
  5. Netwerkgebruik — Activeert hosting een prijsgevingsplicht? Slechts AGPL.

Daarnaast komen nevenpunten: merkrechten (altijd bij het oorspronkelijke project), aansprakelijkheidsuitsluiting (overal), attributie (overal) en onderlinge compatibiliteit — een heel veld waarin hele advocatenkantoren hun brood verdienen. De bittere waarheid: licenties zijn niet noodzakelijkerwijs onderling combineerbaar. GPLv2-code kan niet met Apache-2.0-code gemengd worden zonder een vrijstellingsregel. CDDL en GPL gelden als incompatibel — de basis van jarenlange conflicten rond ZFS-on-Linux.

Verhalen die je moet kennen

De BusyBox-slachting. Vanaf 2007 achtervolgden Erik Andersen, de Software Freedom Law Center en later de Software Freedom Conservancy ongeveer veertien elektronicafabrikanten — Verizon, Samsung, Best Buy, Westinghouse — omdat zij routers, videorecorders en camera’s met ingebouwde BusyBox leverden zonder de aangepaste broncode toegankelijk te maken. De procedures eindigden in schikkingen en richtinggevende verbodsverbintenissen. Ze bewezen: de GPL is handhaafbaar. Wie copyleft-code neemt en de voorwaarden negeert, loopt een reëel juridisch risico.

De Linksys WRT54G en de geboorte van OpenWrt. In 2003 ontdekten hobbyisten dat de enorm populaire wifi-router Linksys WRT54G intern op Linux en BusyBox draaide — beiden onder GPL. Linksys, inmiddels eigendom van Cisco, had de broncode niet gepubliceerd. Na contact door de Free Software Foundation en Bradley Kuhn publiceerde Cisco uiteindelijk de volledige bronboom. Wat begon als een compliance-gebeurtenis werd een van de vruchtbaarste momenten in consumenten-IT: uit de bevrijde code ontstonden OpenWrt, DD-WRT, Tomato en een hele generatie open-bronrouterfirmware. Miljoenen apparaten die hun fabrikanten allang zijn vergeten, worden tot op heden door een community onderhouden. Les: gehandhaafd copyleft levert niet alleen naleving — het kan een heel ecosysteem ontketenen.

De React BSD-plus-Patenten-affaire. Facebook bracht React in 2013 eerst onder Apache 2.0 uit en stapte in 2014 over naar een gewijzigde BSD-licentie met een gekoppelde patentrider: wie Facebook wegens octrooischending proceedings aandeed, verloor onmiddellijk zijn React-rechten. In juli 2017 bestempelde de Apache Software Foundation, gevolgd door Jenkins, WordPress en anderen, dit als onhoudbaar. Binnen enkele weken verloor React een flink deel van institutionele vertrouwen. In september 2017 capituleerde Facebook en plaatste React, Jest, GraphQL en Immutable.js onder puur MIT. Les: een licentie die asymmetrische clausules verbergt, kan een heel ecosysteem in gevaar brengen.

HashiCorps ommezwaai. In augustus 2023 kondigde HashiCorp aan dat Terraform, Vault, Consul en verdere projecten zouden overstappen van MPL 2.0 naar de Business Source License (BSL) — een bron-beschikbare licentie die concurrenten verbiedt concurrerende managed services aan te bieden. Jarenlang hadden gebruikers en bijdragers de projecten onder MPL vertrouwd. De community reageerde met OpenTofu, een MPL-fork nu beheerd door de Linux Foundation. HashiCorp heeft zijn reputatie als open-source-pionier grotendeels verspeeld.

Redis’ abrupte wending. In maart 2024 veranderde Redis Ltd. de licentie van zijn naamgevende database van de ene dag op de andere van BSD 3-Clause naar een dubbelllicentiemodel met RSALv2 en SSPL. Geen van beide kwalificeert nog als open source in de zin van de OSI. Grote cloudproviders — AWS, Google, Oracle, Snap — reageerden binnen dagen met Valkey, een BSD 3-Clause-fork nu gehost door de Linux Foundation. Binnen weken verloor Redis een aanzienlijk deel van zijn enterprise-marktaandeel.

MinIO’s bewuste AGPL-stap. In tegenstelling tot HashiCorp en Redis koos MinIO, de S3-compatibele objectopslag, in 2021 een pad dat binnen open source bleef. Het bedrijf stapte van permissieve Apache 2.0 naar AGPL v3 — een echte, door de OSI erkende licentie. Doel: cloudproviders weerhouden MinIO als managed service aan te bieden zonder wijzigingen bekend te maken. AGPL activeert precies daar waar klassiek copyleft machteloos is: bij netwerkgebaseerd gebruik. Wie MinIO als dienst aanbiedt en aanpast, moet zijn wijzigingen onder AGPL vrijgeven. Het beslissende verschil met BSL of SSPL: MinIO bleef open source. Bijdragers werden niet buitengesloten, forks bleven legitiem, de licentie blijft verenigbaar met het bredere GPL-ecosysteem. Les: bescherming tegen commerciële kannibalisatie vereist niet het verlaten van open source — het vereist de juiste licentie kiezen.

CentOS en de grenzen van het gelicenseerde. Het beroemdste verhaal speelt zich af in 2020/2023. Sinds 2004 was CentOS een community-rebuild van Red Hat Enterprise Linux — RHEL zonder branding, gratis, binair compatibel. In 2014 nam Red Hat het project in huis, huurde maintainers, bracht het onder eigen dak. Alles leek in goede orde. Het keerpunt kwam in december 2020: Red Hat kondigde het einde van CentOS Linux 8 aan per eind 2021 en verving het door CentOS Stream — een rollend upstream-kanaal dat RHEL voedt in plaats van een stabiele downstream-distributie. Duizenden productieopzetten die op CentOS als gratis RHEL-substituut waren gebouwd, stonden voor migratie. De community antwoordde met Rocky Linux (geïnitieerd door Gregory Kurtzer, een van de oorspronkelijke CentOS-oprichters) en AlmaLinux. In juni 2023 volgde de volgende slag: RHEL-broncode werd niet langer als vrij downloadbare tarballs gepubliceerd, maar alleen nog voor klanten toegankelijk via de Red Hat Customer Portal. De GPL werd niet geschonden — de code bleef open voor gerechtigden. Maar de mogelijkheid die kloon-distributies mogelijk maakte, was gesloten. Les: een correcte licentie alleen beschermt niet tegen strategische koerswijzigingen. Wie op een project bouwt, moet naast de licentie ook de governance, financiering en belangen van de houder lezen.

Kannibalisatie onder het mom van bescherming

Deze episoden zijn geen geïsoleerde gevallen. Ze horen bij een trend die sinds 2018 vaart pakt: MongoDB (SSPL, oktober 2018), Elastic (Elasticsearch en Kibana van Apache 2.0 naar SSPL, januari 2021), Sentry, Cockroach Labs, Confluent — de lijst laat zich voortzetten. Het gemeenschappelijke patroon: projecten bouwen gedurende jaren een bijdragerraam en merk op onder een permissieve of zwakke-copyleft-licentie. Zodra echter een grote cloudprovider het winstgevender managed-services-bedrijf gaat domineren, wisselt de houder de licentie voor een model dat precies dat bedrijf afschermt.

Soms is dat legitiem. Maintainers hebben recht op economische duurzaamheid, en open source was nooit synoniem met onbetaalde exploitatie. Maar de manier van uitvoering telt: contributies aannemen onder de oude licentie en vervolgens dezelfde bijdragers onder de nieuwe licentie buitensluiten, breekt een impliciet sociaal contract. Het resultaat is geen open source meer — en het ecosysteem leert dat zulke projecten op elk moment risicofactoren kunnen worden.

Voor inkopers betekent dit: licentiestabiliteit is een selectiecriterium geworden, geen voetnoot.

Wat dit voor libcom.de betekent

Al een kwart eeuw werk ik — Jochen Demmer, libcom.de — met open-source-producten. Begonnen in 2001, toen Linux zich als serverbesturingssysteem begon te vestigen. Vandaag drijft het wereldwijde bankinfrastructuur, telecommunicatienetwerken, ziekenhuis-IT en industriële installingen.

Uit die ervaring komen oordelen die geen whitepaper geeft: welke licenties houdbaar zijn in gereguleerde omgevingen, waar copyleft echt bijt, wanneer AGPL een waarschuwingsvlag is in plaats van een aanbeveling, hoe je rugtrekkingsrisicoën vroegtijdig herkent door governance, financiering en bijdragerstructuur te lezen — niet alleen de README. Of je nu een compliancesstrategie nodig hebt, een stack-audit, aanbestedingsformulering of begeleiding van migratieplanning — dit zijn taken waarbij licentiekennis het verschil maakt tussen rustige meerjarige planning en verrassende heronderhandeling.

En ik zie geen levensvatbare toekomst meer voor puur propriëtaire licenties in de brede IT-infrastructuur. De redenen zijn empirisch: de belangrijkste besturingssystemen, databanken, webservers, container-runtimes, orchestratoren, bouwsystemen en taalcompilers zijn open source. Zelfs de grootste propriëtaire aanbieders bouwen nu op open source — Apples Darwin-wortels, de Linux-kernel van Android, de basis van Visual Studio Code bij Microsoft. Wie anno 2026 nog gelooft dat closed source veiliger zou zijn, vergeet dat zijn zogenaamd veilige keten allang uit vrije software bestaat. Propriëtaire licenties zullen in nauwe specialisaties blijven bestaan. Op breedte zijn ze niet meer tijdsgewricht.

Open source is de nieuwe de-factostandaard. Niet uit ideologie. Uit prestatie, transparantie, controleerbaarheid en langetermijnhoud.

Als je je afvraagt of jouw IT-stacks licentechnisch robuust zijn, of een bepaalde afhankelijkheid een risico vormt, of hoe een compliancesstrategie voor jouw omgeving eruit zou zien: schrijf naar contact@libcom.de. Wij maken een eerlijke inventarisatie. Zonder verkoopdruk. Met de blik op wat op lange termijn houdbaar is.

Vrije software is niet de oplossing voor elk probleem. Maar het is de enige categorie oplossingen waarvan de spelregels leesbaar blijven — ook over twintig jaar.

Disclaimer: Dit artikel biedt algemene oriëntatie en vervangt geen juridisch advies. Licentievragen kunnen afhankelijk zijn van het individuele geval; alle informatie wordt verstrekt zonder garantie.