Stap 9: Kies een open source licentie

Een open source licentie bepaalt wat anderen met jullie code mogen doen. Het is de juridische basis van jullie open source samenwerking. De keuze van licentie heeft grote consequenties voor hergebruik, doorontwikkeling en commercieel gebruik.

Deze stap helpt je een weloverwogen keuze te maken tussen de belangrijkste licenties die voor gemeentelijke software relevant zijn.

Wat doet een open source licentie?

Een open source licentie geeft iedereen (binnen en buiten de samenwerking) het recht om:

• Te gebruiken: De software voor elk doel inzetten
• Te bestuderen: De broncode inzien en begrijpen hoe het werkt
• Te wijzigen: Aanpassingen maken voor eigen gebruik
• Te verspreiden: Kopiëren en delen met anderen (al dan niet met aanpassingen)

Maar licenties kunnen wel voorwaarden stellen aan hoe dit mag. En daar zit het verschil tussen licenties.

Twee hoofdtypen: Permissief vs Copyleft

Open source licenties vallen uiteen in twee families:

Permissieve licenties (vrijgevige aanpak)

Principe:

Doe ermee wat je wilt, ook commercieel. Je mag de code zelfs in gesloten producten verwerken.

Voorbeelden:

MIT, Apache 2.0, BSD

Effect:

Maximale vrijheid, maar ook maximaal risico dat anderen de code commercieel exploiteren zonder iets terug te geven aan de community.

Copyleft licenties (reciproque aanpak)

Principe:

Je mag de code gebruiken en aanpassen, maar als je het verspreid moet je wijzigingen ook open source maken onder dezelfde licentie.

Voorbeelden:

GPL, EUPL, AGPL

Effect:

Beschermt tegen commerciële toe-eigening. Verbeteringen blijven beschikbaar voor de community. Maar kan drempel opwerpen voor gebruik door partijen die code willen sluiten.

Overzicht relevante licenties voor gemeenten

Hieronder de belangrijkste licenties, hun kenmerken en wanneer ze passen:

EUPL 1.2 (European Union Public License)

Type:

Copyleft (matige sterkte)

Kernpunten:

• Speciaal ontwikkeld voor Europese overheden
• Officieel beschikbaar in alle EU-talen
• Copyleft: wijzigingen moeten open source blijven
• Compatibel met GPL en andere belangrijke licenties
• Beschermt tegen patentclaims

Voordelen:

• Door en voor overheden gemaakt
• Nederlandse vertaling beschikbaar
• Voorkomt dat commerciële partijen code ‘dichtdoen’
• Balans tussen openheid en bescherming

Nadelen:

• Minder bekend buiten Europa
• Leveranciers moeten begrijpen wat het betekent
• Copyleft kan drempel zijn voor sommige gebruikers

Geschikt voor: Gemeentelijke samenwerking waarbij je wilt voorkomen dat leveranciers de code sluiten. Standaardkeuze voor veel Nederlandse gemeenten.

MIT License

Type:

Permissief

Kernpunten:

• Zeer korte en simpele licentie
• Minimale restricties
• Mag in commerciële producten verwerkt worden
• Geen verplichting om wijzigingen te delen

Voordelen:

• Zeer breed geaccepteerd
• Makkelijk te begrijpen
• Geen drempels voor gebruik
• Maximale verspreiding mogelijk

Nadelen:

• Geen garantie dat verbeteringen terugkomen
• Commerciële partijen kunnen afgeleide producten sluiten
• Geen patentbescherming

Geschikt voor: Wanneer maximale verspreiding en adoptie belangrijker is dan bescherming. Kleine tools, bibliotheken, of als je commercieel hergebruik wilt stimuleren.

Apache License 2.0

Type:

Permissief (met patentbescherming)

Kernpunten:

• Lijkt op MIT maar met expliciete patentclausule
• Beschermt tegen patentclaims
• Commercieel gebruik toegestaan
• Geen verplichting om wijzigingen te delen

Voordelen:

• Breed geaccepteerd in tech-industrie
• Betere patentbescherming dan MIT
• Duidelijk over contributie-rechten

Nadelen:

• Complexer dan MIT
• Geen copyleft (verbeteringen kunnen privé blijven)

Geschikt voor: Wanneer patentbescherming belangrijk is maar copyleft niet gewenst. Vaak gebruikt bij infrastructuur-software.

GNU GPL 3.0 (General Public License)

Type:

Sterke copyleft

Kernpunten:

• Strikte copyleft: alle afgeleide werken moeten GPL zijn
• Beschermt sterk tegen commerciële toe-eigening
• Patentbescherming inbegrepen
• Meest gebruikte copyleft licentie wereldwijd

Voordelen:

• Maximale bescherming: verbeteringen blijven open
• Wereldwijd bekend en getest
• Sterke community van gebruikers

Nadelen:

• Kan drempel zijn voor bedrijfsleven
• ‘Virale’ werking: code die GPL-code gebruikt moet ook GPL worden
• Engelse tekst (geen officiële NL-versie)

Geschikt voor: Wanneer je wilt garanderen dat alle verbeteringen open blijven. Bijvoorbeeld bij strategische software waar lock-in voorkomen moet worden.

GNU AGPL 3.0 (Affero GPL)

Type:

Zeer sterke copyleft (inclusief SaaS)

Kernpunten:

• Zoals GPL, maar ook voor webservices
• Als je de software als dienst aanbiedt, moet je de code delen
• Sluit ‘SaaS loophole’ van GPL

Voordelen:

• Maximale bescherming ook tegen SaaS-exploitatie
• Voorkomt dat bedrijven de code als gesloten dienst aanbieden

Nadelen:

• Zeer restrictief, grote drempel voor commerciële partijen
• Kan adoptie belemmeren
• Complex in de praktijk

Geschikt voor: Webapplicaties waar je wilt voorkomen dat partijen er een gesloten SaaS-dienst van maken. Vooral relevant bij cloud-based software.

Vergelijkingstabel

Beslishulp: welke licentie past bij jullie?

Doorloop deze vragen om tot een keuze te komen:

Vraag 1: Is het belangrijk dat verbeteringen open blijven?

• Ja, absoluut: Kies copyleft (EUPL, GPL, AGPL)
• Nee, maximale verspreiding belangrijker: Kies permissief (MIT, Apache)

Vraag 2: Willen jullie specifiek voorkomen dat leveranciers de code sluiten?

• Ja: EUPL of GPL
• Nee: MIT of Apache

Vraag 3: Is het een webapplicatie die als dienst aangeboden kan worden?

• Ja, en we willen SaaS-exploitatie voorkomen: AGPL
• Ja, maar dat mag: MIT of Apache
• Nee, geen webapp: EUPL, GPL, MIT of Apache

Vraag 4: Is patentbescherming belangrijk?

• Ja: Apache, EUPL, GPL of AGPL (alle hebben patentclausule)
• Nee/niet relevant: MIT kan ook

Vraag 5: Hecht je waarde aan Europese context?

• Ja, Nederlandse/Europese voorkeur: EUPL (officiële NL-vertaling)
• Nee, internationale standaard: MIT, Apache of GPL

Aanbevelingen per scenario

Scenario 1: Gemeente-applicatie voor dienstverlening

Bijvoorbeeld: zaaksysteem, vergunningensysteem, participatieplatform

Aanbeveling: EUPL 1.2 - Voorkomt vendor lock-in, houdt verbeteringen open, geschikt voor overheden.

Scenario 2: Kleine tool of bibliotheek

Bijvoorbeeld: validatie-tool, API-client, herbruikbare component

Aanbeveling: MIT - Maximale adoptie, eenvoudig, breed geaccepteerd.

Scenario 3: Strategische infrastructuur-software

Bijvoorbeeld: burgerzaken-platform, gemeentelijk dataplatform

Aanbeveling: GPL 3.0 of EUPL 1.2 - Sterke bescherming tegen toe-eigening, waarborgt continuïteit.

Scenario 4: Cloud-based webapplicatie

Bijvoorbeeld: online formulieren, digitaal loket, meldsysteem

Aanbeveling: AGPL 3.0 - Voorkomt dat partijen een gesloten SaaS-variant maken.

Scenario 5: Willen commerciële sector stimuleren

Bijvoorbeeld: innovatieve technologie die je breed wilt verspreiden

Aanbeveling: Apache 2.0 - Permissief maar met patentbescherming, aantrekkelijk voor bedrijven.

Praktische tips

Beslis vroeg, maar niet te vroeg

Kies de licentie voordat je code publiceert. Maar als je nog experimenteert, wacht dan totdat je weet wat je gaat bouwen.

Je kunt later niet meer veranderen

Een eenmaal gekozen licentie is moeilijk te wijzigen. Je hebt toestemming nodig van alle contributors. Kies dus zorgvuldig.

LICENTIE-bestand in repository

Plaats altijd een LICENSE of LICENTIE.txt bestand in de root van je repository met de volledige licentietekst.

Copyright notices in broncode

Voeg aan elk bronbestand een korte copyright notice toe die verwijst naar de licentie.

Betrek juridische afdeling, maar…

Laat juridische adviseur meekijken, maar laat het geen jarenlang proces worden. De licenties die hier staan zijn bewezen en veilig te gebruiken.

Bij twijfel tussen permissief en copyleft

Voor gemeentelijke software: kies copyleft (EUPL). Het voorkomt vervelende verrassingen en past bij publieke waarden.

Tip: Kijk wat vergelijkbare projecten doen. Als er al een ecosysteem is van open source gemeente-software, kies dan een compatibele licentie.