GPL, MIT of Apache: welke licentie moet u kiezen?

GPL versus MIT versus Apache: wat elke licentie van u verlangt

GPL, MIT en Apache 2.0 beantwoorden dezelfde vraag op verschillende manieren: wat bent u aan anderen verschuldigd wanneer u de software doorgeeft? MIT vraagt enkel om een copyrightvermelding en niets meer. Apache 2.0 vraagt om die vermelding plus een patentafspraak tussen iedereen die met de code werkt. De GPL verplicht u om de broncode van wat u daarop voortbouwt, onder dezelfde licentie als die u heeft ontvangen, te publiceren.

Dat lijkt een vraag voor juristen totdat de dag aanbreekt dat een project dat u beheert van licentie verandert en in tweeën splitst. Dan wordt het een operationele kwestie. U moet kiezen tussen twee pakketrepositories en clientbibliotheken die niet langer met elkaar communiceren. Deze handleiding gaat over de licenties en de werking ervan, niet over de beweging die ze heeft voortgebracht. Daarom eindigt elke sectie waar het u raakt: de persoon die de upgrade moet uitvoeren.

Waarom de GPL bestaat: een printer die niemand mocht repareren

Rond 1980 ontving het MIT Artificial Intelligence Lab een Xerox 9700 laserprinter. Het lab had de software voor een eerdere printer aangepast zodat deze aangaf wanneer een taak vastliep. Voor de nieuwe printer was geen broncode beschikbaar en het verzoek daartoe werd afgewezen vanwege een geheimhoudingsverklaring. Richard Stallman, destijds programmeur in het lab, beschouwde die weigering als de algemene regel in plaats van een incident en kondigde op 27 september 1983 het GNU-project aan.

Copyleft is gebouwd op het auteursrecht, niet ertegenin. Standaard heeft u helemaal geen recht om de code van iemand anders te kopiëren. De GPL verleent dat recht onder één voorwaarde: als u het programma aan iemand anders geeft, moet u de broncode verstrekken onder dezelfde voorwaarden, zodat zij kunnen doen wat het lab niet kon. De voorwaarde is afdwingbaar omdat u zonder de licentie in de eerste plaats geen toestemming had.

Stallman schreef eerst een licentie voor GNU Emacs en generaliseerde deze vervolgens tot GPL versie 1 op 25 februari 1989. GPL versie 2 volgde in juni 1991 en dit is nog steeds de licentie van de meeste systeemsoftware die u draait. De Lesser GPL werd geïntroduceerd voor bibliotheken, zodat een copyleft-bibliotheek gekoppeld kon worden door een programma onder elke willekeurige licentie, zonder dat dat programma onder de GPL viel.

Eén detail bepaalt hoe de GPL invloed heeft op een self-hoster. De verplichting treedt in werking bij distributie, niet bij gebruik. U kunt een GPL-programma aanpassen, op uw eigen server draaien en het publiek ermee bedienen zonder iemand iets verschuldigd te zijn, omdat u nooit een kopie heeft weggegeven. Dat gat is de reden dat de AGPL bestaat.

De permissieve traditie: BSD, daarna MIT

Berkeley koos een andere route. De Computer Systems Research Group bracht zijn Unix-werk uit onder een licentie die vereiste dat de copyrightvermelding behouden bleef en die elke garantie uitsloot. De oorspronkelijke versie bevatte vier clausules. De vierde, de reclameclausule, vereiste een vermelding van de universiteit in al het reclamemateriaal waarin functies van de software werden genoemd. Dat is niet schaalbaar. Stallman telde 75 afzonderlijke vermeldingen in een versie van NetBSD uit 1997. UC Berkeley trok de clausule in op 22 juli 1999, in een brief van William Hoskins van het Office of Technology Licensing.

Wat overblijft is de 3-clause BSD licentie, die een verbod toevoegt op het gebruik van de namen van bijdragers om uw product te onderschrijven, en de 2-clause versie, die zelfs dat laat vallen. De MIT licentietekst kwam in de jaren 80 voort uit MIT, waar deze het X Window System dekte, en in de praktijk doet deze hetzelfde als de 2-clause BSD.

De motieven waren verschillend. Een universiteit die met publiek geld werd gefinancierd, wilde dat haar werk overal werd gebruikt, ook door bedrijven. Het GNU project wilde een publiek domein dat niet kon worden afgesloten. Beide standpunten zijn oprecht en beide hebben een faalwijze. Permissieve code kan privaat worden gemaakt, waardoor u niets terugkrijgt. Copyleft-code wordt geweigerd door bedrijven waarvan de juristen de voorwaarde niet accepteren.

Er is een tweede les van Berkeley, en dat is de les waar dit bericht steeds naar terugkeert. AT&T's Unix System Laboratories klaagde Berkeley Software Design in 1992 aan over de BSD-code, en de zaak werd begin 1994 geschikt. Twee jaar lang kon niemand er zeker van zijn dat BSD veilig was om op voort te bouwen, en de adoptie stagneerde terwijl Linux groeide. Juridische onzekerheid stopt adoptie sneller dan een ontbrekende functie dat doet.

Waarom Apache 2.0 een patentlicentie toevoegde

De eerste licentie van de Apache Group was een afgeleide van de BSD 4-clause licentie, met hetzelfde probleem wat betreft reclameverplichtingen. Versie 1.1, uitgebracht in 2000, verwijderde die clausule. Versie 2.0, gepubliceerd in januari 2004, was een volledige herschrijving in plaats van een patch.

De belangrijke toevoeging betreft patenten. MIT en BSD zeggen hier niets over. Een bijdrager kan u expliciet toestemming geven voor het auteursrecht op hun code, maar tegelijkertijd een patent bezitten op de werking van die code, om vervolgens gebruikers van de software aan te klagen. Apache 2.0 dicht dit gat: elke bijdrager verleent een patentlicentie voor hun bijdrage, en iedereen die een rechtszaak aanspant met de claim dat het werk inbreuk maakt op hun patenten, verliest direct de eigen licentie op het werk. De dreiging is wederzijds, waardoor in de praktijk niemand tot actie overgaat.

De rest van 2.0 is administratief van aard, en dat is waarom bedrijven de licentie waarderen. Er is een gedefinieerd NOTICE-bestand, waardoor naamsvermelding op één centrale plek staat in plaats van verspreid door de hele broncode. De licentie kan via een verwijzing worden toegepast in plaats van in elk bronbestand te worden geplakt. Bijdragen vallen onder expliciete voorwaarden. Handelsmerken zijn uitgesloten. Een juridische beoordeling van een Apache 2.0-afhankelijkheid beantwoordt alle vragen die een jurist zou hebben al in de tekst zelf. Hierdoor wordt goedkeuring een routineklus, wat grotendeels is wat wordt bedoeld met de "corporate default".

Wat GPLv3 veranderde en waarom Linux bij GPLv2 bleef

TiVo leverde een videorecorder met Linux en publiceerde de kernelbroncode, precies zoals GPLv2 vereist. De hardware controleerde vervolgens bij het opstarten een cryptografische handtekening en weigerde een kernel uit te voeren die het niet herkende. U kon de broncode lezen, wijzigen en compileren. U kon deze echter niet uitvoeren op het apparaat waar het vandaan kwam. Aan de letter van de licentie was voldaan, maar het doel ervan werd tenietgedaan; deze praktijk kreeg de naam tivoisation.

GPL versie 3, gepubliceerd op 29 juni 2007, geeft hier direct antwoord op. Wanneer u het binaire bestand in een consumentenapparaat levert, moet u ook de "Installatie-informatie" verstrekken: de sleutels of instructies die nodig zijn om een gewijzigde versie te installeren en deze te laten draaien. Versie 3 voegde ook een expliciete patentverlening toe, voorwaarden geschreven als reactie op de patentovereenkomst tussen Microsoft en Novell van november 2006, en een eenzijdige compatibiliteit met Apache 2.0.

Linux volgde niet. De kernel is uitsluitend GPL versie 2, zonder "of enige latere versie"-ontsnappingsclausule, en het COPYING-bestand vermeldt dit expliciet. Linus Torvalds maakte publiekelijk bezwaar tegen de anti-tivoisation-voorwaarden voor hardware met handtekeningcontrole. De praktische barrière is groter dan het meningsverschil: de kernel heeft duizenden auteursrechthebbenden, dus niemand zou de toestemmingen kunnen verzamelen die nodig zijn voor een herlicentiëring, zelfs als iedereen dat zou willen. Dat enkele feit is de sterkste bescherming die een project kan hebben, en het is de moeite waard om dit te onthouden wanneer u kijkt naar een project dat eigendom is van één bedrijf.

De andere licentie uit 2007 is belangrijker voor u. De GNU Affero GPL versie 3, gepubliceerd in november van hetzelfde jaar, breidt de broncodeverplichting uit naar mensen die via een netwerk met het programma interageren. Draai een gewijzigde AGPL-service voor het publiek en u bent de broncode verschuldigd aan die gebruikers. Dat is de reden waarom zoveel zelfgehoste websoftware AGPL is. Nextcloud is daar een voorbeeld van, en als u de zelfgehoste alternatieven voor Nextcloud vergelijkt, vertelt de licentieregel in de repository van elke kandidaat u meer over de komende vijf jaar dan de lijst met functies.

Welke licenties kunt u daadwerkelijk combineren?

Compatibiliteit werkt in één richting: van permissief naar copyleft.

• MIT- en BSD-code kunnen in elk project worden opgenomen, inclusief een gesloten product.
• Apache 2.0-code kan worden opgenomen in een GPLv3-project; het gecombineerde werk valt dan onder de GPLv3.
• Apache 2.0-code kan niet worden opgenomen in een project dat uitsluitend onder GPLv2 valt. De bepalingen voor patentbeëindiging en vrijwaring zijn extra voorwaarden die de GPLv2 niet toestaat. Zowel de FSF als de ASF publiceren deze conclusie.
• GPL-code kan door u niet worden omgezet naar een permissieve licentie. Alleen de auteursrechthebbenden kunnen dat doen, wat u terugbrengt bij de vraag wie zij zijn.

Het tijdperk van herlicentiëring: SSPL, BUSL en wat ze niet zijn

De aanleiding was commercieel. Een bedrijf bezit het auteursrecht op een product, een cloudprovider verkoopt dit op grote schaal als een beheerde dienst en draagt nauwelijks bij, waarna het bedrijf de licentie wijzigt om dit te stoppen. Redis Labs zette in augustus 2018 de eerste zichtbare stap door de Commons Clause toe te voegen aan Apache 2.0 voor diverse modules. MongoDB volgde op 16 oktober 2018 door over te stappen van AGPLv3 naar de Server Side Public License.

De SSPL is de AGPL met één herschreven sectie. Biedt u het programma aan derden aan als een dienst, dan moet u de broncode publiceren van alles wat u gebruikt om die dienst aan te bieden, inclusief de beheer- en orchestratiesoftware eromheen. Die verplichting heeft geen duidelijke grens en is nog niet door een rechter getoetst. De OSI heeft de licentie nooit goedgekeurd en MongoDB trok de aanvraag in maart 2019 in. Debian had in december 2018 al verklaard dat SSPL-software niet in hun archief thuishoorde, en Fedora oordeelde in januari 2019 dat de licentie niet vrij is, waarna Red Hat MongoDB uit Fedora en Red Hat Enterprise Linux verwijderde. Dat is het mechanische gevolg van een herlicentiëring: de distributie stopt met het verpakken van de software, waardoor uw updates voortaan uit een vendor-repository komen volgens het schema van de leverancier.

De Business Source License is een ander instrument. Het is afkomstig van de oprichters van MariaDB en versie 1.1 dateert uit 2017. Het is geen copyleft en het is geen open source. De broncode is openbaar, het gebruik is gratis behalve voor het gebruik dat de leverancier uitsluit – doorgaans het draaien van een concurrerende hosted dienst – en elke release wordt automatisch omgezet naar een echte open source-licentie op een wijzigingsdatum die maximaal vier jaar na die release ligt. De licentie waarnaar wordt omgezet, moet GPLv2-compatibel zijn. HashiCorp stapte op 10 augustus 2023 met Terraform en andere producten over naar BUSL 1.1. Outline gebruikt het ook, wat nuttig is om te weten als u een keuze maakt uit de zelf-gehoste Notion-alternatieven: het draaien voor uw eigen team is toegestaan, het bouwen van een dienst erop niet.

Geen van beide licenties is oneerlijk. Beide stellen duidelijk dat ze source available zijn. Geen van beide is open source volgens de definitie van de OSI, en het verschil raakt u eerder dan de cloudprovider waarop het was gericht.

OpenSearch: wat een licentiefork de beheerder kost

Elastic kondigde op 14 januari 2021 aan dat Elasticsearch en Kibana vanaf release 7.11 zouden overstappen van Apache 2.0 naar een keuze tussen de SSPL of de Elastic License. Versie 7.10.2 was de laatste release onder Apache 2.0. Ongeveer een week later maakte AWS bekend dat het een Apache 2.0-fork van beide zou creëren en onderhouden. De fork kreeg op 12 april 2021 de naam OpenSearch, waarbij Kibana werd hernoemd naar OpenSearch Dashboards. OpenSearch 1.0 werd algemeen beschikbaar op 12 juli 2021, gebouwd op basis van Elasticsearch 7.10.2 en Kibana 7.10.2.

Kijk naar wat dit de beheerders van clusters heeft gekost. Pakketnamen en repositories veranderden. Elke verwijzing naar Kibana in een draaiboek werd OpenSearch Dashboards. Plug-in-namen verplaatsten. Vervolgens bereikte de splitsing de applicatiecode: vanaf versie 7.13 van de officiële clientbibliotheken van Elastic controleert de client waarmee verbinding is gemaakt. Deze weigert door te gaan met alles wat geen Elasticsearch is en meldt dat de server een onbekend product is. Een licentiebesluit bij een bedrijf waar u niet werkt, resulteerde in een falende aanroep binnen uw eigen applicatie.

Het verhaal nam daarna nog twee wendingen. Elastic voegde op 29 augustus 2024 AGPLv3 toe als derde licentieoptie, waardoor de huidige Elasticsearch weer OSI-goedgekeurde open source is. Op 16 september 2024 droeg AWS OpenSearch over aan de OpenSearch Software Foundation, gehost door de Linux Foundation. Dit gaf de fork een bestuursstructuur die niet afhankelijk is van één enkel bedrijf. Vijf jaar na de splitsing zijn beide projecten open source, worden ze beide onderhouden en bevindt OpenSearch zich in augustus 2026 in de 3.x-serie.

De afloop is de les. De licentie kwam terug, maar de fork bleef. Zodra een ecosysteem van alles twee varianten heeft, zorgt het ongedaan maken van het papierwerk er niet voor dat ze weer samensmelten.

Het getal dat bepaalt hoeveel pijn een licentiewijziging doet, is de tijd tussen de aankondiging en een stabiele fork die u daadwerkelijk kunt implementeren.

[
  {
    "label": "Elasticsearch to OpenSearch 1.0",
    "gap_to_stable_fork": 179
  },
  {
    "label": "Terraform to OpenTofu 1.6.0",
    "gap_to_stable_fork": 153
  },
  {
    "label": "Redis to Valkey 7.2.5",
    "gap_to_stable_fork": 27
  }
]

Elke periode wordt geteld vanaf de publieke aankondiging van de leverancier tot de eerste stabiele release van de fork, gebruikmakend van de onderstaande data. OpenSearch 1.0 kostte 179 dagen, omdat de fork moest worden hernoemd en opnieuw opgebouwd zonder eerdere fork om van te kopiëren. OpenTofu kostte 153 dagen. Valkey kostte 27 dagen, omdat het Redis 7.2.4 forkte en het protocol en het on-disk formaat identiek hield. De trend is het meest leerzame aspect: een geloofwaardige fork verschijnt tegenwoordig binnen enkele weken, vanaf de eerste dag ondersteund door een stichting en betaalde beheerders.

Valkey en OpenTofu: hetzelfde patroon, sneller

Redis Ltd verplaatste Redis op 20 maart 2024 van de 3-clause BSD-licentie naar een keuze tussen RSALv2 of SSPLv1. Acht dagen later kondigde de Linux Foundation Valkey aan, een fork van Redis 7.2.4 die bij de BSD 3-clause licentie bleef. Valkey 7.2.5 verscheen op 16 april 2024 met hetzelfde protocol en dezelfde databestanden, waardoor de migratie voor de meeste beheerders slechts een wijziging van de pakketnaam inhield. Redis voegde in mei 2025 AGPLv3 toe als derde optie in Redis 8, wat het volgens de definitie van de OSI weer open source maakt, terwijl Valkey onder zijn eigen bestuur verdergaat. Het verloop komt nauw overeen met dat van Elasticsearch.

Terraform doorliep hetzelfde traject met één extra hoofdstuk. OpenTofu splitste zich af van de laatste release onder de Mozilla Public License 2.0, sloot zich in september 2023 aan bij de Linux Foundation en bracht op 10 januari 2024 versie 1.6.0 uit. Op 3 april 2024 stuurden de advocaten van HashiCorp een sommatiebrief naar het project, waarin zij beweerden dat code uit een Terraform-release onder de BUSL-licentie was gekopieerd naar de fork. OpenTofu publiceerde op 11 april 2024 een gedetailleerde reactie waarin dit werd ontkend, en herleidde de betwiste code naar de geschiedenis onder de MPL-licentie die beide projecten delen. Hierna volgde publiekelijk niets meer. Het werkelijke risico van die episode is wat men moet onthouden: een beschuldiging alleen kan de adoptie een kwartaal lang bevriezen, hetzelfde effect als de rechtszaak van Berkeley dertig jaar eerder had.

Niet elke fork begint bij een licentie. Forgejo splitste zich in 2022 af van Gitea nadat de ontwikkeling van Gitea onder een bedrijf kwam te vallen; dit was eerder een bestuursgeschil dan een licentiekwestie. Forgejo bleef MIT-gelicentieerd tot en met de versie 8-serie en stapte vanaf versie 9.0 in 2024 over op GPLv3 of later, zodat het werk niet kon worden teruggehaald naar een commercieel aangestuurd product. Als u de opties voor zelfgehoste Git-servers afweegt, is dat paar het duidelijkste actuele voorbeeld van één codebase met twee filosofieën.

De test die u moet uitvoeren voordat u iets adopteert

Vier vragen, liever voor de eerste installatie dan erna.

1. Wie bezit het auteursrecht? Voor het wijzigen van de licentie is toestemming nodig van elke auteursrechthebbende. Een project met honderden onafhankelijke bijdragers en zonder overdracht van rechten kan daarom in de praktijk niet van licentie veranderen. Een project dat volledig eigendom is van één bedrijf kan tijdens een bestuursvergadering van licentie worden gewijzigd.
2. Is er een CLA en wat verleent deze? Een Contributor Licence Agreement (CLA) die het bedrijf toestaat uw bijdrage onder elke gewenste voorwaarde opnieuw te licentiëren, is precies het mechanisme achter elke hierboven genoemde licentiewijziging. Een DCO (Developer Certificate of Origin), de 'sign-off'-regel die de Linux-kernel in 2004 adopteerde, draagt geen enkel recht over. Een CLA die wordt beheerd door een stichting is veiliger dan een CLA van een bedrijf, omdat een bedrijf verkocht kan worden.
3. Wie bezit het handelsmerk? Elastic behield de naam Elasticsearch, waardoor de fork zichzelf moest hernoemen en elk draaiboek waarin Kibana werd genoemd, moest worden herschreven.
4. Wat zou een licentiewijziging u specifiek kosten? Tel het dataformaat, de clientbibliotheken en de configuratie die u zou moeten herschrijven mee, en kijk of er al een compatibele fork bestaat.

Twee commando's beantwoorden een deel hiervan in seconden.

head -n 12 /usr/share/doc/bash/copyright
git log --oneline -- LICENSE COPYING LICENSE.md

Elk Debian- en Ubuntu-pakket levert een bestand op /usr/share/doc/<package>/copyright mee. Dit legt de licentie vast van de versie die u heeft geïnstalleerd, niet de licentie die het project vandaag de dag gebruikt. Voor bash op Ubuntu 24.04 vermeldt dat bestand de GNU General Public License version 3. Voer het tweede commando uit in een source checkout en u krijgt de geschiedenis van het licentiebestand zelf. Een commit in de afgelopen twee jaar is het lezen waard voordat u iets op het project bouwt. Als het commando niets weergeeft, heeft de repository het licentiebestand een andere naam gegeven; bekijk in dat geval de root-directory.

Geen enkele licentie beschermt u tegen elke uitkomst, en kiezen op basis van ideologie is de reden waarom mensen voor verrassingen komen te staan. Geef de voorkeur aan projecten waarvan het auteursrecht verspreid is over vele handen of wordt beheerd door een stichting, en bewaar uw data in een formaat dat u kunt exporteren. Zoek vervolgens uit naar welke fork u zou overstappen en noteer de naam voordat u deze nodig heeft. Deze controle uitvoeren voor elke kandidaat kost minder dan een uur, en het is wat een upgrade onderscheidt van een migratie wanneer u beslist wat u in 2026 zelf wilt hosten.

FAQ

Is de MIT-licentie hetzelfde als de BSD-licentie?

In de praktijk komt de MIT-licentie overeen met de 2-clause BSD-licentie: behoud de copyrightvermelding en de garantie-uitsluiting, en doe daarna wat u wilt, inclusief het bouwen van een gesloten product. De 3-clause BSD-licentie voegt één punt toe: een verbod op het gebruik van de namen van bijdragers om uw product aan te bevelen zonder toestemming. De oudere 4-clause versie vereiste ook een vermelding in reclamemateriaal; de UC Berkeley heeft die clausule op 22 juli 1999 ingetrokken, waardoor vrijwel geen enkele huidige licentie deze nog bevat.

Kan ik Apache 2.0-code in een GPLv2-project plaatsen?

Nee. Apache 2.0 voegt voorwaarden toe die GPLv2 niet toestaat, met name de clausule over patentbeëindiging, waardoor een gecombineerd werk niet aan beide licenties tegelijk kan voldoen. Zowel de FSF als de ASF publiceren deze conclusie. De andere richting werkt wel: Apache 2.0-code kan worden opgenomen in een GPLv3-project, en het resultaat is dan GPLv3. Dit is ook de reden waarom Apache 2.0-code niet kan worden samengevoegd in de Linux-kernel, die uitsluitend onder GPL versie 2 valt.

Is de SSPL een open source-licentie?

Nee, en dit antwoord heeft praktische gevolgen. De OSI heeft deze nooit goedgekeurd en MongoDB trok de aanvraag in maart 2019 in. Debian stelde in december 2018 dat SSPL-software niet in het archief thuishoorde, en Fedora oordeelde in januari 2019 dat de licentie niet vrij is, waarna Red Hat MongoDB uit Fedora en Red Hat Enterprise Linux verwijderde. Voor u betekent dit dat een pakket dat uw distributie voorheen onderhield, nu afkomstig is uit een leveranciersrepository, volgens het ondersteuningsschema van die leverancier. De Business Source License is eveneens 'source available' in plaats van open source, hoewel elke release binnen vier jaar wordt omgezet naar een open source-licentie.

Is een licentiewijziging van toepassing op de versie die ik al draai?

Nee. Een licentie die bij een release is verleend, kan niet worden ingetrokken voor kopieën die al zijn gepubliceerd; dit is precies de reden waarom forks mogelijk zijn. OpenSearch is gebouwd op basis van Elasticsearch 7.10.2, de laatste release die Elastic onder Apache 2.0 publiceerde. Wat u verliest is de toekomst, omdat de volgende beveiligingsupdate onder de nieuwe voorwaarden valt. Het vastzetten op de laatste versie met een permissieve licentie geeft u een paar maanden uitstel, maar het is geen structurele oplossing.