MIT, GPL of Apache: kies de licentie die jouw open-source avontuur niet torpedeert

Je hebt weken, misschien maanden, gewerkt aan een project waar je trots op bent. De code staat op GitHub, het README-bestand is strak geschreven, en je vingers jeuken om op die grote groene knop 'Make public' te drukken. Maar dan: welke licentie kies je eigenlijk?

Voor veel Nederlandse developers is dit het moment waarop het enthousiasme even stokt. Licenties voelen als juridische fijndruk — iets voor advocaten, niet voor mensen die gewoon coole software willen bouwen. Toch is het een beslissing die verstrekkende gevolgen heeft voor wie er met jouw werk aan de slag gaat, en hoe. Gelukkig hoef je geen jurist te zijn om de juiste keuze te maken.

Waarom een licentie eigenlijk verplicht is

Zonder licentie is jouw code technisch gezien volledig gesloten, ook al staat het publiek op internet. Iemand die jouw repo forkt zonder expliciete toestemming, beweegt zich in juridisch grijs gebied. Door een licentie toe te voegen geef je de wereld duidelijkheid: dit zijn de spelregels.

De open-source wereld heeft gelukkig een handvol beproefde standaarden ontwikkeld. Je hoeft het wiel niet opnieuw uit te vinden. De drie die je het vaakst tegenkomt — MIT, GPL en Apache 2.0 — dekken samen een enorm spectrum aan wensen en doelstellingen.

MIT: de vriendelijkste licentie in de klas

Als open-source licenties een persoonlijkheid hadden, zou MIT de ontspannen collega zijn die zegt: 'Doe maar wat je wil, als je mijn naam maar niet vergeet.' En dat is eigenlijk precies de kern.

Met de MIT-licentie mag iedereen jouw code gebruiken, kopiëren, aanpassen, samenvoegen, publiceren, verspreiden, sublicentiëren en zelfs verkopen — mits ze de originele copyright-vermelding intact laten. Dat is het. Meer vraagt MIT niet.

Wanneer kies je MIT?

• Je wil maximale adoptie van je project.
• Je vindt het prima als bedrijven jouw code in commerciële producten verwerken zonder broncode terug te geven.
• Je bouwt een library of framework dat zo breed mogelijk ingezet moet worden.

Denk aan projecten zoals React of jQuery — beide MIT-gelicentieerd, beide massaal omarmd door de industrie. De keerzijde: een groot bedrijf kan jouw werk oppakken, er een dikke laag proprietary software omheen bouwen en er geld mee verdienen zonder ooit iets terug te geven aan de community. Vind je dat geen probleem? Dan is MIT je vriend.

GPL: de licentie met een missie

De GNU General Public License (GPL) is de ideologische tegenhanger van MIT. Waar MIT loslaat, houdt GPL vast aan een principe: vrijheid moet zich voortplanten. Dit noem je ook wel 'copyleft'.

Als iemand jouw GPL-code in een groter project verwerkt en dat project distribueert, moet het volledige project ook onder GPL uitgebracht worden — inclusief de broncode. Dit voorkomt dat bedrijven open-source bouwstenen gebruiken als fundament voor gesloten software.

Wanneer kies je GPL?

• Je gelooft in het principe dat open code open moet blijven.
• Je wil voorkomen dat commerciële partijen profiteren zonder bij te dragen.
• Je bouwt iets dat echt een community-gedreven ecosysteem moet worden.

Linux is het bekendste voorbeeld. Niemand kan een aangepaste Linux-kernel distribueren zonder de wijzigingen ook vrij te geven. Dat heeft ervoor gezorgd dat het ecosysteem enorm rijk en transparant is gebleven.

Eén aandachtspunt voor Nederlandse developers die met bedrijven samenwerken: de GPL kan zakelijke partners afschrikken. Een opdrachtgever die jouw GPL-library wil integreren in zijn SaaS-product, kan daarmee problemen krijgen. Wil je zakelijk flexibel blijven, dan kan LGPL (Lesser GPL) een tussenweg zijn — die staat toe dat proprietary software de library aanroept zonder de GPL-verplichting te triggeren.

Apache 2.0: het zakelijke midden

Apache 2.0 is een soort volwassen broer van MIT. Permissief, maar met wat extra bescherming ingebouwd. Het grote verschil zit in de patentclausule: wanneer je bijdraagt aan een Apache-project, verleen je automatisch een patentlicentie aan alle gebruikers. Omgekeerd verlies je die licentie als je een patentclaim indient tegen het project.

Dit klinkt technisch, maar het is in de praktijk heel relevant voor bedrijfsomgevingen waar patenten een rol spelen. Apache 2.0 is daardoor de go-to licentie voor veel grote infrastructuurprojecten.

Wanneer kies je Apache 2.0?

• Je werkt aan een project dat ook door enterprises gebruikt gaat worden.
• Je wil patentbescherming voor bijdragers en gebruikers.
• Je wil permissieve vrijheid, maar met iets meer juridische robuustheid dan MIT.

Kubernetes, TensorFlow en de meeste Apache Software Foundation-projecten draaien op Apache 2.0. Het is de licentie die zegt: 'Wij zijn serieus bezig, maar we heten iedereen welkom.'

Snel kiezen: een praktische beslisboom

Nog steeds twijfel? Stel jezelf deze drie vragen:

1. Wil je dat afgeleid werk ook open-source blijft?

   • Ja → kijk naar GPL of LGPL
   • Nee → ga door naar vraag 2

2. Werk je in een omgeving waar patenten een rol spelen?

   • Ja → Apache 2.0
   • Nee → ga door naar vraag 3

3. Wil je maximale eenvoud en adoptie?

   • Ja → MIT
   • Nee → verdiep je in minder gangbare licenties zoals MPL of EUPL

De EUPL (European Union Public License) is trouwens een interessante optie voor Nederlandse overheidsprojecten of Europees gefinancierde initiatieven — het is de enige licentie die expliciet rekening houdt met Europese wetgeving.

Licenties combineren en afhankelijkheden checken

Een valkuil die veel developers over het hoofd zien: de licenties van je dependencies. Als jouw project afhankelijk is van een GPL-library, heeft dat consequenties voor de licentie van jouw eigen code. MIT en Apache 2.0 zijn onderling goed combineerbaar, maar GPL mengen met permissieve licenties kan lastig worden.

Gebruik tools zoals FOSSA of de ingebouwde dependency-scanner van GitHub om een helder beeld te krijgen van je licentie-landschap. Zeker als je in teamverband werkt of van plan bent je project commercieel in te zetten, is dit geen stap die je wil overslaan.

Zet die licentie ook écht neer

Een licentie kiezen is één ding, maar vergeet niet hem ook daadwerkelijk toe te voegen. Dat betekent:

• Een LICENSE-bestand in de root van je repository
• Een vermelding in je README.md
• Optioneel: een SPDX-identifier bovenaan je bronbestanden

GitHub maakt het makkelijk: bij het aanmaken van een repository kun je direct een licentie kiezen uit een dropdown. Gebruik die functie.

Conclusie: de licentie als fundament van vertrouwen

Een open-source licentie is meer dan juridische formaliteit. Het is een signaal naar de wereld: dit zijn mijn waarden, dit is wat ik verwacht, en dit is hoe we samenwerken. Of je nu kiest voor de vrijgevigheid van MIT, de idealistische principes van GPL of de zakelijke robuustheid van Apache — elke keuze vertelt een verhaal over jouw project en de community die je wil bouwen.

Neem de tijd om die keuze bewust te maken. Jouw toekomstige bijdragers zullen je er dankbaar voor zijn.