Soorten licenties in applicatieontwikkeling en hun verschillen

Wat is een softwarelicentie?

Een softwarelicentie is een set regels die uitlegt hoe een applicatie of broncode door anderen mag worden gebruikt.

Via een licentie kan de maker van de applicatie bepalen of anderen:

• De applicatie gratis mogen gebruiken.
• De broncode mogen wijzigen.
• De applicatie mogen doorverkopen.
• De code mogen gebruiken voor commerciële projecten.
• Afgeleide werken mogen maken.
• De broncode mogen sluiten na wijziging.
• De gewijzigde broncode moeten delen.

Dus zelfs als broncode openbaar beschikbaar is op GitHub, betekent dat niet dat de code vrijelijk zonder beperkingen kan worden gebruikt.

Zonder licentie zijn automatisch de auteursrechtregels van toepassing. Dit betekent dat de code-eigenaar alle rechten behoudt en anderen in feite geen toestemming hebben om de code te kopiëren, te wijzigen of te verspreiden.

Open source betekent niet gratis zonder regels

Veel mensen denken dat open source betekent dat broncode voor alles zonder voorwaarden kan worden gebruikt. In werkelijkheid heeft elke open-sourcelicentie verschillende regels.

Over het algemeen staan open-sourcelicenties toe dat de software wordt gebruikt, bestudeerd, gewijzigd en gedeeld. Sommige licenties verlenen echter zeer ruime vrijheden, terwijl andere vereisen dat afgeleide applicaties open source blijven.

Softwarelicenties worden meestal in een aantal hoofdgroepen verdeeld:

1. Permissieve licentie
2. Copyleft-licentie
3. Zwakke copyleft-licentie
4. Propriëtaire licentie
5. Publiek domein-licentie

Vergelijkingstabel softwarelicenties

Licentie	Type	Commercieel gebruik toegestaan	Wijziging toegestaan	Kan closed source worden gemaakt	Moet broncode openbaar zijn	Octrooibescherming	Geschikt voor
MIT	Permissief	Ja	Ja	Ja	Nee	Niet expliciet vermeld	Bibliotheken, applicaties, persoonlijke projecten
Apache 2.0	Permissief	Ja	Ja	Ja	Nee	Ja	Bedrijfsprojecten en technologie
BSD 2-Clause	Permissief	Ja	Ja	Ja	Nee	Niet expliciet vermeld	Systemen, bibliotheken en applicaties
BSD 3-Clause	Permissief	Ja	Ja	Ja	Nee	Niet expliciet vermeld	Projecten die naam bescherming van maker nodig hebben
ISC	Permissief	Ja	Ja	Ja	Nee	Niet expliciet vermeld	Kleine projecten en JavaScript-bibliotheken
GNU GPL	Sterke copyleft	Ja	Ja	Nee voor afgeleide werken	Ja, bij distributie	Afhankelijk van versie	Volledig open source applicaties
GNU LGPL	Zwakke copyleft	Ja	Ja	Ja, met bepaalde voorwaarden	Alleen specifieke bibliotheekonderdelen	Afhankelijk van versie	Open source bibliotheken
GNU AGPL	Sterke netwerk-copyleft	Ja	Ja	Over het algemeen nee	Ja, inclusief netwerkservice	Ja op AGPLv3	Servers, SaaS en webapplicaties
MPL 2.0	Bestandsniveau-copyleft	Ja	Ja	Ja, voor afzonderlijke bestanden	Alleen gewijzigde MPL-gelicentieerde bestanden	Ja	Gemengde open source en propriëtaire projecten
Unlicense	Publiek domein-stijl	Ja	Ja	Ja	Nee	Nee	Eenvoudige code bedoeld om vrij te geven
Propriëtair	Gesloten bron	Met toestemming eigenaar	Meestal niet	Ja	Nee	Per overeenkomst	Interne applicaties en betaalde producten

1. MIT-licentie

De MIT-licentie is een van de eenvoudigste en meest flexibele open-sourcelicenties.

Deze licentie staat anderen toe om:

• De software te gebruiken.
• De broncode te kopiëren.
• De broncode te wijzigen.
• De software te verkopen.
• De code op te nemen in betaalde applicaties.
• De applicatie om te zetten naar closed source.

De belangrijkste vereiste is dat de copyrightvermelding en de MIT-licentietekst moeten worden opgenomen in alle kopieën of substantiële delen van de software.

Voordelen van de MIT-licentie

• Licentietekst is kort.
• Makkelijk te begrijpen.
• Vriendelijk voor commercieel gebruik.
• Kan worden gebruikt in closed source applicaties.
• Veel gebruikt in bibliotheken en frameworks.

Nadelen van de MIT-licentie

• Anderen kunnen de code nemen, wijzigen en vervolgens verkopen als een closed source applicatie.
• Heeft geen octrooibescherming die zo duidelijk is als Apache 2.0.
• De code-eigenaar kan niet vereisen dat gewijzigde versies open source blijven.

Geschikt wanneer

MIT is geschikt voor ontwikkelaars die willen dat hun broncode zo breed mogelijk wordt gebruikt zonder veel beperkingen op te leggen.

2. Apache-licentie 2.0

De Apache-licentie 2.0 heeft vergelijkbare kenmerken als MIT. De software kan worden gebruikt, gewijzigd, gedistribueerd en opgenomen in commerciële applicaties.

Het belangrijkste verschil is dat Apache 2.0 bepalingen bevat over octrooiverlening. Deze licentie vereist ook naamsvermelding via bestanden zoals LICENSE en, indien beschikbaar, NOTICE.

Voordelen van Apache 2.0

• Kan worden gebruikt voor commerciële projecten.
• Kan worden opgenomen in closed source applicaties.
• Heeft duidelijkere octrooibescherming en -bepalingen.
• Geschikt voor bedrijfsprojecten.
• Gebruikers zijn verplicht om belangrijke wijzigingen te documenteren.

Nadelen van Apache 2.0

• Licentietekst is langer in vergelijking met MIT.
• Beheer van naamsvermelding en het NOTICE-bestand kan complexer zijn.
• Vereist niet dat afgeleide werken open source zijn.

Geschikt wanneer

Apache 2.0 is geschikt voor professionele projecten of bedrijven die een flexibele licentie met duidelijkere octrooibescherming willen.

3. BSD-licentie

De BSD-licentie is een permissieve licentie vergelijkbaar met MIT. Het heeft verschillende versies, maar de meest voorkomende zijn BSD 2-Clause en BSD 3-Clause.

Beide staan gebruik, wijziging en distributie toe in zowel broncode als binaire vorm.

BSD 2-Clause

BSD 2-Clause wordt ook wel de Vereenvoudigde BSD-licentie genoemd.

De belangrijkste vereisten:

• De copyrightvermelding moet behouden blijven.
• De licentietekst en disclaimer moeten behouden blijven.

BSD 3-Clause

BSD 3-Clause heeft een extra regel: de namen van de makers of bijdragers mogen niet worden gebruikt om afgeleide producten te promoten zonder toestemming.

Voordelen van de BSD-licentie

• Eenvoudig en flexibel.
• Kan commercieel worden gebruikt.
• Kan worden opgenomen in closed source applicaties.
• Geschikt voor bibliotheken en systeemsoftware.

Nadelen van de BSD-licentie

• Codewijzigingen hoeven niet te worden gedeeld.
• Heeft geen octrooibepalingen die zo duidelijk zijn als Apache 2.0.
• Anderen kunnen propriëtaire producten maken met behulp van de code.

4. ISC-licentie

De ISC-licentie is een zeer beknopte permissieve licentie. Functioneel is deze bijna identiek aan MIT en BSD 2-Clause.

Gebruikers mogen de software gebruiken, kopiëren, wijzigen en distribueren zolang de copyrightvermelding en de toestemmingstekst behouden blijven.

Voordelen van de ISC-licentie

• Zeer korte tekst.
• Gemakkelijk toe te passen.
• Toegestaan voor commercieel gebruik.
• Kan worden gebruikt in closed source applicaties.

Nadelen van de ISC-licentie

• Vereist niet dat gewijzigde versies open source zijn.
• Octrooibepalingen zijn niet zo duidelijk als Apache 2.0.
• Minder geschikt wanneer de maker de openheid van afgeleide code wil behouden.

ISC komt vrij veel voor in pakketten en bibliotheken binnen het JavaScript-ecosysteem.

5. GNU General Public License of GPL

GNU is niet één licentienaam. GNU heeft verschillende soorten licenties, zoals:

• GNU GPL
• GNU LGPL
• GNU AGPL

De GNU General Public License of GPL is een sterke copyleft-licentie. Dit betekent dat wanneer GPL-software wordt gewijzigd en gedistribueerd als een afgeleid werk, de broncode van die applicatie ook beschikbaar moet worden gesteld onder een compatibele GPL-licentie.

GPL verbiedt commercieel gebruik niet. Ontwikkelaars mogen GPL-software nog steeds verkopen. Ontvangers van de software moeten echter de rechten krijgen die door de GPL worden verleend, inclusief toegang tot de broncode onder de door de licentie vereiste voorwaarden.

Voordelen van GNU GPL

• Houdt software en zijn afgeleiden open.
• Verbeteringen en ontwikkelingen kunnen terugvloeien naar de gemeenschap.
• Voorkomt dat anderen de code nemen en de bron van afgeleide werken sluiten.
• Geschikt voor community-gebaseerde projecten.

Nadelen van GNU GPL

• Moeilijk te gebruiken in propriëtaire producten.
• Voorzichtigheid geboden bij combineren met andere gelicentieerde code.
• Minder geschikt voor bedrijven die de broncode van hun product gesloten willen houden.

Moet interne code worden geopend?

Niet altijd.

Als een GPL-applicatie alleen intern wordt gebruikt en niet aan anderen wordt gedistribueerd, hoeft de broncode over het algemeen niet automatisch openbaar te worden gemaakt.

De belangrijkste verplichting van GPL ontstaat meestal wanneer de software of afgeleide werken worden gedistribueerd.

6. GNU Lesser General Public License of LGPL

LGPL is een flexibelere copyleft-versie in vergelijking met GPL.

Deze licentie wordt meestal gebruikt voor bibliotheken. Propriëtaire applicaties mogen LGPL-bibliotheken gebruiken of koppelen zolang ze voldoen aan de licentievoorwaarden. GNU stelt dat LGPL-bibliotheken kunnen worden gekoppeld met propriëtaire applicaties, in tegenstelling tot GPL die een sterker copyleft-effect heeft op afgeleide werken.

Voordelen van GNU LGPL

• Geschikt voor open source bibliotheken.
• Kan worden gebruikt door closed source applicaties.
• Wijzigingen aan de LGPL-bibliotheek moeten nog steeds voldoen aan LGPL-regels.
• Vergroot het gebruik van de bibliotheek zonder alle copyleft-beschermingen op te geven.

Nadelen van GNU LGPL

• Integratieregels zijn complexer dan MIT.
• Koppelings- en distributiemethoden vereisen aandacht.
• Directe wijzigingen aan de bibliotheek kunnen verplichtingen tot het delen van de bibliotheekbroncode activeren.

Geschikt wanneer

LGPL is geschikt wanneer u een bibliotheek maakt die u bruikbaar wilt maken voor zowel open source als propriëtaire applicaties.

7. GNU Affero General Public License of AGPL

AGPL is een copyleft-licentie speciaal ontworpen voor software die via een netwerk wordt gebruikt, zoals:

• Webapplicaties.
• Software as a Service of SaaS.
• API's.
• Servers.
• Online platforms.

Met gewone GPL kan een bedrijf de software wijzigen en op een server draaien zonder de applicatie te distribueren. In een dergelijke situatie is de distributieverplichting van de GPL-broncode mogelijk niet van toepassing.

AGPL voegt verplichtingen toe met betrekking tot softwaregebruik via een netwerk. Gebruikers die via een netwerk communiceren met een gewijzigde versie van de software moeten de mogelijkheid hebben om de bijbehorende broncode te openen.

Voordelen van GNU AGPL

• Geschikt om SaaS-applicaties open source te houden.
• Voorkomt dat anderen een serverapplicatie wijzigen en de code sluiten.
• Biedt sterkere copyleft-bescherming.

Nadelen van GNU AGPL

• Moeilijk te gebruiken in propriëtaire applicaties.
• Vaak vermeden door bedrijven die de broncode van de server niet willen openen.
• Integratie moet zorgvuldig worden bekeken.

8. Mozilla Public License 2.0

De Mozilla Public License of MPL 2.0 is een copyleft op bestandniveau-licentie.

Dit betekent dat bestanden die al onder MPL vallen en later worden gewijzigd, beschikbaar moeten blijven onder MPL. Deze bestanden kunnen echter nog steeds worden gecombineerd met andere propriëtaire bestanden in een enkele applicatie.

Daarom zit MPL tussen permissieve licenties zoals MIT en sterke copyleft-licenties zoals GPL in. MPL 2.0 is ook een open-sourcelicentie die wordt erkend door het Open Source Initiative.

Voordelen van MPL 2.0

• Flexibeler dan GPL.
• Gewijzigde open source bestanden blijven open.
• Kan worden gecombineerd met closed source code.
• Geschikt voor projecten met zowel open als propriëtaire modules.

Nadelen van MPL 2.0

• Complexer dan MIT of BSD.
• Ontwikkelaars moeten weten welke bestanden onder MPL vallen.
• Minder geschikt als u de volledige afgeleide applicatie open source wilt houden.

9. Unlicense

De Unlicense wordt gebruikt wanneer een maker code in het publieke domein wil vrijgeven voor zover de wet toestaat.

Over het algemeen mogen gebruikers:

• De code kopiëren.
• De code wijzigen.
• De code verkopen.
• De code distribueren.
• De code gebruiken zonder naamsvermelding.

De Unlicense legt zeer weinig voorwaarden op aan gebruikers.

Voordelen van Unlicense

• Zeer vrij.
• Bijna geen naamsvermeldingsverplichtingen.
• Geschikt voor kleine codefragmenten of voorbeeldcode.

Nadelen van Unlicense

• Het concept van publiek domein kan per land anders worden behandeld.
• Niet ideaal voor bedrijfsprojecten.
• Biedt geen duidelijke octrooibescherming.
• Bedrijfsbijdragers geven mogelijk de voorkeur aan MIT of Apache 2.0.

10. Propriëtaire licentie

Een propriëtaire licentie is een licentie voor closed source applicaties. De rechten om de software te gebruiken worden volledig bepaald door de applicatie-eigenaar.

Gebruikers krijgen meestal alleen toestemming om de applicatie te gebruiken, niet om de broncode te bezitten of te wijzigen.

Voorbeelden:

• Abonnementsapplicaties.
• Interne bedrijfssoftware.
• Betaalde kassa-applicaties.
• Hotelmanagementsystemen.
• Klantspecifieke applicaties.
• Betaalde desktopsoftware.

Algemene regels

• De applicatie mag niet worden gekopieerd.
• Accounts mogen niet worden gedeeld.
• De broncode mag niet worden bekeken of gewijzigd.
• De applicatie mag niet worden doorverkocht.
• Gebruik is beperkt per apparaat, gebruiker, bedrijf of tijd.
• Gebruiksrechten eindigen wanneer het abonnement stopt.

Geschikt wanneer

Een propriëtaire licentie is geschikt wanneer de applicatie een bedrijfsproduct is en de broncode gesloten moet blijven.

11. Dubbele licentieverlening

Dubbele licentieverlening is een methode om twee licentie-opties voor dezelfde software aan te bieden.

Voorbeelden:

• Gratis met GPL voor open source projecten.
• Betaling met een commerciële licentie voor bedrijven die de software willen gebruiken zonder GPL te volgen.

Dit model stelt softwaremakers in staat om te profiteren van de open source community terwijl ze ook commerciële licenties verkopen.

Dubbele licentieverlening is echter gemakkelijker te implementeren wanneer de broncode-auteursrechten volledig eigendom zijn van één bedrijf of entiteit. Als er veel bijdragers zijn, moet het beheer van bijdragerechten duidelijk worden vastgesteld.

Kan Creative Commons worden gebruikt voor broncode?

Creative Commons of CC is meer geschikt voor:

• Artikelen.
• Afbeeldingen.
• Video's.
• Muziek.
• Documentatie.
• Leermateriaal.
• Ontwerpen en creatieve inhoud.

Creative Commons raadt het gebruik van CC-licenties voor software en hardware af omdat er specifieke softwarelicenties zijn die zaken als broncode, distributie en wijziging beter adresseren.

In een enkel applicatieproject kunt u gebruiken:

• MIT, Apache of GPL voor broncode.
• Creative Commons voor documentatie, afbeeldingen of ander materiaal.

Zorg ervoor dat elk onderdeel apart wordt uitgelegd om verwarring bij gebruikers te voorkomen.

Verschillen tussen permissief en copyleft

Aspect	Permissieve licentie	Copyleft-licentie
Voorbeelden	MIT, Apache 2.0, BSD, ISC	GPL, AGPL
Commercieel gebruik	Toegestaan	Toegestaan
Codewijziging	Toegestaan	Toegestaan
Kan closed source worden	Over het algemeen toegestaan	Over het algemeen niet voor afgeleide werken
Moet wijzigingen delen	Nee	Ja onder bepaalde voorwaarden
Mate van beperking	Eenvoudiger	Strenger
Geschikt voor bedrijven	Zeer geschikt	Afhankelijk van bedrijfsmodel
Geschikt voor open source community	Geschikt	Zeer geschikt
Bescherming van code-openheid	Laag	Hoog

Welke licentie moet u kiezen?

Gebruik MIT wanneer

• U een eenvoudige licentie wilt.
• U wilt dat de code zo breed mogelijk wordt gebruikt.
• Het u niet uitmaakt of de code wordt gebruikt in closed source applicaties.
• U een bibliotheek of persoonlijk project maakt.

Gebruik Apache 2.0 wanneer

• U de vrijheid van MIT wilt.
• U duidelijkere octrooibepalingen nodig heeft.
• U een bedrijfsproject maakt.
• U van plan bent veel bijdragen te accepteren.

Gebruik BSD wanneer

• U een eenvoudige permissieve licentie wilt.
• U systeemsoftware of een bibliotheek maakt.
• U niet wilt dat de naam van de maker wordt gebruikt voor promotie van afgeleide producten.

Gebruik GPL wanneer

• U wilt dat afgeleide applicaties open source blijven.
• U niet wilt dat bedrijven de code nemen en de bron sluiten.
• U een communityproject maakt.

Gebruik LGPL wanneer

• U een bibliotheek maakt.
• U wilt dat de bibliotheek bruikbaar is voor propriëtaire applicaties.
• U wilt dat wijzigingen aan de bibliotheek open blijven.

Gebruik AGPL wanneer

• U een SaaS- of serverapplicatie maakt.
• U wilt dat wijzigingen via een netwerk worden gedeeld.
• U niet wilt dat bedrijven gewijzigde versies privé op hun servers draaien.

Gebruik MPL 2.0 wanneer

• U wilt dat een deel van de code open blijft.
• U code nog steeds wilt combineren met propriëtaire modules.
• U een middenweg nodig heeft tussen MIT en GPL.

Gebruik een propriëtaire licentie wanneer

• De broncode niet kan worden geopend.
• De applicatie voor zakelijke doeleinden is gemaakt.
• U het softwaregebruik wilt beperken.
• De applicatie wordt verkocht via een licentie- of abonnementssysteem.

Voorbeeld van licentietoepassing op GitHub

Meestal wordt de licentietekst opgeslagen in het volgende bestand:

LICENSE

of:

LICENSE.md

Dat bestand wordt in de hoofdmap of rootmap van de repository geplaatst. GitHub raadt ook aan om het licentiebestand rechtstreeks in de repository op te nemen, zodat het beschikbaar is wanneer het project wordt gekloond, gedownload of gedistribueerd.

Voorbeeld projectstructuur:

app-name/
├── app/
├── public/
├── src/
├── README.md
├── LICENSE
└── package.json

Korte informatie kan ook worden toegevoegd aan README.md:

## Licentie

Dit project is gelicentieerd onder de MIT-licentie.
Zie het LICENSE-bestand voor meer informatie.

Dingen om te controleren voordat u een licentie kiest

Overweeg het volgende voordat u een licentie kiest:

1. Mag de applicatie commercieel worden gebruikt?
2. Mogen anderen de broncode wijzigen?
3. Moeten wijzigingen worden gedeeld?
4. Kunnen afgeleide werken closed source zijn?
5. Wordt de applicatie gebruikt als SaaS?
6. Maakt het project gebruik van bibliotheken van derden?
7. Zijn de licenties van elke afhankelijkheid compatibel?
8. Is er code van andere bijdragers?
9. Is octrooibescherming nodig?
10. Wordt de applicatie aan klanten verkocht?

Kies niet zomaar een licentie omdat deze populair is. Kies een licentie op basis van de doelen van het project en hoe de applicatie zal worden gebruikt.

Conclusie

Elke softwarelicentie biedt verschillende rechten en verplichtingen.

MIT, BSD en ISC zijn geschikt voor projecten die gebruikers ruime vrijheden willen geven. Apache 2.0 biedt vergelijkbare vrijheid met duidelijkere octrooibepalingen.

GPL is geschikt om afgeleide applicaties open source te houden. LGPL is geschikter voor bibliotheken, terwijl AGPL extra bescherming biedt voor webapplicaties, servers en SaaS.

MPL 2.0 kan een middenweg zijn omdat het alleen vereist dat bepaalde bestanden open blijven. Een propriëtaire licentie is daarentegen geschikter voor zakelijke applicaties waarvan de broncode gesloten moet blijven.

Licentiekeuze moet vroeg in de ontwikkeling worden gedaan. Naast het beschermen van de applicatiemaker, helpt een duidelijke licentie ook gebruikers en bijdragers om te begrijpen wat wel en niet is toegestaan.

Opmerking: Dit artikel geeft een algemene uitleg en is geen juridisch advies. Raadpleeg voor grootschalige commerciële applicaties, intensief gebruik van afhankelijkheden of projecten met veel bijdragers iemand die verstand heeft van intellectueel eigendomsrecht voor de licentiekeuze.