De MIT-licentie en de GPL-licentie zijn de twee uitersten van open source. MIT laat je alles doen met de code, ook in betaalde software, zolang je de copyrightvermelding en de licentietekst meelevert. GPL laat je ook alles doen, met één harde voorwaarde: verspreid je software die op GPL-code voortbouwt, dan moet het geheel onder de GPL vallen, met broncode erbij.
Voor een bureau is het verschil groot. MIT-afhankelijkheden zijn zelden een probleem. GPL-code in een module die je in licentie wilt geven of wilt verkopen, kan de deal blokkeren.
Wat mag je met MIT-code?
Bijna alles. De MIT-licentie staat toe dat je de software gebruikt, kopieert, aanpast, samenvoegt, publiceert, verspreidt, in sublicentie geeft en verkoopt. Er is één voorwaarde: de copyrightvermelding en de licentietekst moeten in alle kopieën of wezenlijke delen van de software staan.
In de praktijk betekent dat:
- je laat de
LICENSE-bestanden van afhankelijkheden staan; - je levert bij een product een overzicht van gebruikte open source componenten mee, bijvoorbeeld als bestand of in een ‘over’-scherm;
- je eigen code mag gesloten blijven.
De BSD-licenties werken vergelijkbaar. De Apache 2.0-licentie ook, met twee extra’s: je moet aangepaste bestanden als aangepast markeren en een eventueel NOTICE-bestand meeleveren (artikel 4 van die licentie). Apache 2.0 geeft daarnaast een octrooilicentie, die vervalt als je zelf een octrooizaak over de software begint (artikel 3).
Wat eist de GPL-licentie?
De GPL is een copyleft-licentie. Je mag GPL-code gebruiken, aanpassen en verspreiden.
Verspreid je een programma dat op GPL-code is gebaseerd, dan moet je het hele werk onder de GPL licentiëren (GPLv3, artikel 5 onder c). De ontvanger heeft dan recht op de broncode (artikel 6).
De sleutel is het woord verspreiden. Wat telt wel en wat niet:
| Situatie | Verspreiding onder de GPL? |
|---|---|
| Software intern gebruiken in je bureau | Nee |
| Software als SaaS draaien op je eigen servers | Nee, behalve bij de AGPL |
| Een installatiebestand of app leveren aan een klant | Ja |
| Broncode overdragen aan een klant na een project | Ja |
| Een module in licentie geven aan een ander bedrijf | Ja |
GPLv2 heeft dezelfde kern, met andere nummering. Ook daar moet een programma dat je verspreidt en dat van GPL-code is afgeleid als geheel onder de GPL vallen (GPLv2, artikel 2 onder b).
Wanneer raakt GPL je eigen code?
Als je eigen code en de GPL-code samen één programma vormen dat je verspreidt. Een bibliotheek die je meelinkt of een stuk GPL-code dat je in je module hebt geplakt, valt daar in de regel onder. Twee losse programma’s die naast elkaar draaien en via een netwerk of de commandoregel praten, meestal niet.
Waar de grens precies ligt, verschilt per geval. Ga uit van het voorzichtige antwoord: zit er GPL-code in de module, dan kun je die module niet onder gesloten voorwaarden verspreiden.
Wat zijn AGPL en LGPL?
Twee varianten die je in repo’s van bureaus vaak tegenkomt.
- AGPL. Werkt als de GPL, plus een netwerkregel. Pas je AGPL-software aan en laat je gebruikers er via een netwerk mee werken, dan moet je die gebruikers de broncode van jouw versie aanbieden (AGPLv3, artikel 13). Voor SaaS is dit de licentie om naar te zoeken.
- LGPL. Bedoeld voor bibliotheken. Je mag de bibliotheek gebruiken in gesloten software, zolang de gebruiker de bibliotheek kan vervangen door een aangepaste versie. Aanpassingen aan de bibliotheek zelf blijven onder de LGPL.
| Licentie | Eigen code mag gesloten blijven bij verspreiding? | Let op |
|---|---|---|
| MIT, BSD | Ja | Vermelding en licentietekst meeleveren |
| Apache 2.0 | Ja | Ook NOTICE en markering van wijzigingen |
| LGPL | Ja, bij koppeling | Bibliotheek moet vervangbaar zijn |
| GPL | Nee, het geheel gaat onder GPL | Broncode aan ontvanger |
| AGPL | Nee, ook bij gebruik via netwerk | Broncode aan gebruikers van de dienst |
Hoe controleer je de licenties in je repo?
Doe dit voor elke repo die je in licentie wilt geven of wilt verkopen. Een koper doet het anders voor je, en dan midden in de onderhandeling.
- Draai een licentiescanner over de repo en de lockfiles. Neem ook transitieve afhankelijkheden mee.
- Zoek handmatig naar gekopieerde code zonder pakketbeheer: mappen als
vendoroflib, en codeblokken met een vreemde copyrightregel. - Zet alles in een lijst: component, versie, licentie, hoe het gebruikt wordt.
- Markeer elke GPL- en AGPL-component en bepaal of hij verspreid wordt.
- Vervang wat de deal blokkeert, of kies een licentiemodel dat erbij past.
- Voeg de lijst als bijlage toe aan de licentie- of koopovereenkomst.
Wat betekent dit voor code die je bureau wil verzilveren?
Open source in de afhankelijkheden is normaal en verlaagt de waarde zelden. MIT, BSD en Apache 2.0 zijn geen bezwaar. GPL en AGPL bepalen welke licentievormen je kunt aanbieden.
Een schone licentielijst hoort daarom in het eigendomsdossier. Dat dossier bevat:
- de arbeidsovereenkomsten van je ontwikkelaars;
- de overdrachtsovereenkomsten en aktes van je zzp’ers;
- de lijst van open source componenten met hun licenties.
Hoe dat dossier eruitziet, lees je op wie is eigenaar van de code. Hoe je daarna een licentie opzet, staat op licentieovereenkomst software. Wat de code waard is, op wat is code waard.