GitHub-code in een commercieel product: licenties en wat je moet controleren

Je bouwt een product en vindt op GitHub iets dat al klaar is: een bibliotheek, een sjabloon of een heel project dat precies doet wat je nodig hebt. Claude stelt voor om het aan je project toe te voegen. En dan aarzel je: de code lijkt openbaar beschikbaar, maar mag je die eigenlijk wel gebruiken, laat staan een product verkopen waarin die is opgenomen? Kan de auteur later verhaal op je komen halen?

Ik bespreek het stap voor stap: waarom open code op GitHub op zichzelf geen toestemming betekent, met welke licenties je code mag gebruiken en een product mag verkopen, welke copyleftvoorwaarden overeenkomstige broncode voor een gedekt werk kunnen vereisen en hoe je een licentie in een minuut controleert voordat je de code gebruikt. Geen “dat hangt van de situatie af”.

Praktische informatie over werken met Ailoot staat in de documentatie.

Klopt het dat je code gratis mag gebruiken als die op GitHub staat?#

De grootste valkuil is hier het woord ‘open’. Je kunt de broncode zien, dus het lijkt alsof je die mag gebruiken omdat hij niet verborgen is. Die redenering klopt niet. ‘Open om te lezen’ en ‘gelicentieerd voor gebruik’ zijn twee verschillende dingen.

Standaard is elk creatief werk, waaronder code, vanaf het moment van ontstaan auteursrechtelijk beschermd. Totdat de auteur uitdrukkelijk toestemming geeft, mag je het niet gebruiken. Zo beschrijft GitHub het op zijn eigen pagina met informatie over licenties.

De tweede laag is GitHub zelf. Mensen denken dat ze, omdat ze door code te publiceren akkoord zijn gegaan met de regels van GitHub, ook code van anderen daar mogen gebruiken. De regels zeggen precies het tegenovergestelde. Door een repository openbaar te maken, staat de auteur anderen alleen toe die te bekijken en te forken — dat wil zeggen, er binnen GitHub zelf een kopie van te maken. Dat geeft geen toestemming om de code in je eigen werk te gebruiken.

De belangrijkste woorden staan in de laatste zin: ‘binnen de functies van GitHub’ en ‘aanvullende rechten komen voort uit een licentie’. Een fork blijft binnen GitHub. Zodra je de code in je eigen product wilt gebruiken, laat staan het product wilt verkopen, heb je een aparte licentie van de auteur nodig. Geen licentie, geen recht — ook al staat de code daar voor iedereen zichtbaar.

Wat bepaalt of je code van iemand anders mag gebruiken?#

Alles draait om één bestand. Een goed onderhouden repository bevat een licentiebestand — meestal LICENSE, soms LICENSE.md, of een vermelding rechtstreeks in de README. Dit is de toestemming van de auteur, waarin staat onder welke voorwaarden je de code mag gebruiken. GitHub toont de naam van de licentie meestal in de zijbalk van de repositorypagina, voordat je het bestand zelf opent.

Om niet te verdwalen in juridisch taalgebruik, is het handig om de licentie te lezen aan de hand van drie vragen over jouw situatie:

1. Mag je deze code gebruiken in een commercieel product waarvoor mensen betalen?
2. Mag je de code aanpassen aan je behoeften?
3. Moet je daarna de broncode van je product openbaar maken, of mag je die gesloten houden?

Bijna alle verschillen tussen licenties komen neer op verschillende antwoorden op de derde vraag. Op de eerste twee antwoorden populaire open licenties meestal met ‘ja’: gebruik de code, wijzig die, verkoop het product. Mensen lopen vast op de vraag of de licentie vereist dat je je eigen code openbaar maakt. Hierna bespreken we de belangrijkste soorten aan de hand van deze drie vragen.

Met welke licenties mag je code gebruiken en een product verkopen?#

We beginnen met goed nieuws. Voor iemand die een product bouwt om het te verkopen, is de beste keuze een groep licenties die permissieve licenties wordt genoemd. Er zijn er verschillende, maar drie komen het meest voor: MIT, Apache 2.0 en BSD. Alle drie beantwoorden de eerste twee vragen met ‘ja’ en staan toe dat je je eigen broncode gesloten houdt.

De meest voorkomende en eenvoudigste is MIT. De tekst past in één alinea.

Eenvoudiger gezegd: MIT staat je toe bijna alles met de code te doen, waaronder het product verkopen en je eigen broncode gesloten houden. De enige verplichting is om de licentietekst en de regel met de naamsvermelding op te nemen. Zo zijn Babel, .NET en Rails bijvoorbeeld uitgebracht onder MIT, dus je hebt vrijwel zeker al code onder deze licentie gebruikt.

Apache 2.0 werkt op vergelijkbare wijze, maar voegt twee belangrijke punten toe. Ten eerste expliciete bescherming tegen patentclaims: de auteurs van de code beloven je niet aan te klagen vanwege patenten op deze code. Ten tweede zijn er enkele aanvullende formele vereisten voor het gebruik.

BSD (in de versies met 2 en 3 clausules) is in wezen vergelijkbaar met MIT: gebruik de code, wijzig die, verkoop het product en behoud de auteursrechtvermelding. Ik heb ze alle drie in een tabel gezet, zodat je het verschil in één oogopslag ziet.

Zo kun je dit op je eigen situatie toepassen: zie je MIT, Apache 2.0 of BSD bij code van iemand anders, dan kun je gerust zijn: je mag die in een commercieel product gebruiken, wijzigen en je eigen broncode gesloten houden. Je moet alleen voorkomen dat je het licentiebestand en de naamsvermelding verwijdert uit het deel dat je hebt overgenomen.

Hoe gelden broncodeverplichtingen van GPL en AGPL?#

Copyleft houdt een gedekt werk en afgeleiden onder dezelfde licentie wanneer de relevante voorwaarden gelden. Bij GPLv3 vereist verspreiding van bron- of objectcodekopieën van een gedekt of gecombineerd afgeleid werk naleving van de licentie en verplichtingen voor overeenkomstige broncode. Dat geldt niet automatisch voor elk onafhankelijk programma in hetzelfde product of op dezelfde server.

Neem het webdienstvoorbeeld. Een GPL-bibliotheek op je eigen server hosten zonder gebruikers kopieën te geven vereist op zichzelf niet publicatie van de hele dienst. Een gedekte gecombineerde applicatie aan klanten verspreiden kan GPL-plichten activeren; controleer integratie en licentie voordat je bepaalt welke broncode moet worden meegeleverd. Een browserclient die gebruikers ontvangen is een aparte verspreidingsvraag.

AGPLv3 voegt een netwerkvoorwaarde toe: wijzig je het programma en gebruiken mensen die versie op afstand, dan moet het hun duidelijk de overeenkomstige broncode aanbieden. Dat is preciezer dan stellen dat elk gehost AGPL-onderdeel alle onafhankelijke delen van een dienst openbaar maakt.

Onderzoek voor een gesloten product het gedekte werk, hoe componenten combineren, of kopieën worden verspreid en of AGPL-netwerkinteractie geldt. Kies een passende permissieve vervanger of verkrijg aparte toestemming als je niet aan verplichtingen kunt voldoen. Commercieel gebruik zelf is toegestaan; het gaat om naleving van de echte licentie en integratie.

Wat moet je doen als de repository helemaal geen licentiebestand heeft?#

Een veelgemaakte fout is aannemen dat er geen beperkingen zijn als er geen licentie is en dat je de code dus vrij mag gebruiken. Het tegenovergestelde is waar. Geen licentie betekent geen toestemming; standaard is er dus geen toestemming. Code zonder licentie blijft volledig beschermd door het auteursrecht van de auteur en je mag die niet aanraken.

De regel waarmee we begonnen, geldt opnieuw: standaard is code auteursrechtelijk beschermd en zonder uitdrukkelijke toestemming mag je die niet kopiëren, wijzigen of verspreiden. De mogelijkheid om de code binnen GitHub te bekijken en te forken doorbreekt die barrière niet — ze geeft je niet het recht om de code in je eigen product te gebruiken.

Dit kun je in de praktijk doen als de code geen licentie heeft maar je die echt nodig hebt:

1. Schrijf de auteur. Vraag rechtstreeks in de discussiesectie van de repository of per e-mail of je de code mag gebruiken en onder welke voorwaarden. Soms is de auteur gewoon vergeten een licentie toe te voegen en doet die dat alsnog als je erom vraagt.
2. Zoek een vervanging. Voor bijna elke taak zijn er een tweede, derde en tiende vergelijkbare repository — daartussen vind je er een met een passende MIT- of Apache-licentie.
3. Gebruik de code niet. Zonder toestemming en zonder vervanging is de code niet van jou en mag je die niet opnemen in een product dat je wilt verkopen. De verleiding om te denken ‘wie komt daar nou achter?’ loopt slecht af zodra het product geld begint op te leveren en aandacht trekt.

Wat als Claude zelf code van iemand anders aan het project heeft toegevoegd?#

Hier is nog een laag die makkelijk met de eerste wordt verward. Het is één ding om naar een repository te gaan en er een bestand uit te kopiëren: dan ben je rechtstreeks verplicht je aan alles hierboven over de licentie te houden. Het is iets anders wanneer Claude code voor je schrijft als antwoord op een verzoek.

In gewone gevallen produceert AI eigen tekst, samengesteld voor jouw taak, in plaats van een kopie van het bestand van iemand anders. De vraag verschuift dan naar een ander onderwerp: van wie is de gegenereerde code en mag je die verkopen? Dat is een groot onderwerp op zich, dat ik heb behandeld in een artikel over wie eigenaar is van code die door AI is geschreven.

Er is wel een uitzondering om in gedachten te houden. Soms produceert AI een herkenbaar deel van iemands code bijna woord voor woord — een complete functie uit een bekende bibliotheek. In dat geval geldt de licentie van de bibliotheek nog steeds, ongeacht wie de toetsen fysiek heeft ingedrukt. Grote kant-en-klare codeblokken die Claude in hun geheel heeft toegevoegd, moet je daarom controleren alsof je ze zelf had gekopieerd.

Een licentie controleren voordat je code gebruikt: stappen om te volgen#

Laten we alles samenvatten in een korte checklist om code van derden te controleren voordat je die aan je project toevoegt. Werk de stappen van boven naar beneden af.

1. Zoek de licentienaam op de repositorypagina

   Open de repository op GitHub. De licentienaam is meestal zichtbaar in de rechterkolom of onder de lijst met bestanden — bijvoorbeeld ‘MIT License’, ‘Apache-2.0’ of ‘GPL-3.0’. Als daar niets staat en er geen licentiebestand is, is dat al een waarschuwingssignaal; kom er in de laatste stap op terug.

2. Open het licentiebestand zelf

   Zoek LICENSE, LICENSE.md of COPYING in de bestandenlijst en open het. Controleer of de naam overeenkomt met wat in de zijbalk staat en of de licentie geldt voor de code die je gebruikt, en niet alleen voor een afzonderlijk deel van de repository.

3. Bepaal het type: permissief of copyleft

   MIT, Apache 2.0 en BSD zijn permissief; je mag de code gebruiken in een gesloten commercieel product. GPL en AGPL zijn copyleft; controleer gedekt werk, verspreiding en eventuele AGPL-netwerkvoorwaarden voordat je broncodeverplichtingen bepaalt. Alleen de naam stelt niet vast welke onafhankelijke onderdelen zijn gedekt.

4. Vergelijk de licentie met jouw situatie

   Beantwoord drie vragen: verkoop je het product, wijzig je de code en wil je de broncode gesloten houden? MIT, Apache en BSD zijn geschikt voor een gesloten product dat je verkoopt. Bepaal bij GPL en AGPL voor welk gedekt of gecombineerd werk overeenkomstige broncode nodig is en wanneer die plicht ontstaat; beoordeel of je eraan kunt voldoen.

5. Geen licentie betekent: niet gebruiken

   Als er geen licentiebestand is en de README niets over toestemming vermeldt, mag je de code niet gebruiken. Schrijf de auteur en vraag toestemming, of zoek een gelijkwaardig alternatief met een passende licentie. ‘Het is openbaar beschikbaar’ betekent niet dat je toestemming hebt.

Deze controle lijkt omslachtig, totdat je product groeit, geld begint op te leveren en iemand voor het eerst vraagt naar de code van derden die erin zit. Twee minuten aan het begin kosten minder dan een geschil later afhandelen. Ik bespreek afzonderlijk wat je daarna met je product kunt doen, zodat het na de lancering niet stilvalt: Ik heb met AI een product gebouwd; wat nu.

Ailoot openen.