Een pakketnaam is nog geen licentieonderzoek
Start met de versie die werkelijk in het product terechtkomt. Een project kan zijn voorwaarden wijzigen, meerdere licenties aanbieden of bestanden van derden bevatten. Een dependencylijst zonder versies en herkomst is daardoor onvoldoende. Neem ook transitieve afhankelijkheden, lettertypen, voorbeeldbestanden en meegeleverde hulpmiddelen op. Een ontwikkelaar kan een onderdeel hebben verwijderd uit de broncode terwijl een oude versie nog in het installatiepakket zit.
Koppel het overzicht aan het gebouwde product. Noteer welke component in de browser wordt geleverd, welke op de server draait en welke uitsluitend tijdens het bouwen wordt gebruikt. Deze plaatsing helpt bepalen welke distributie of beschikbaarstelling onderzocht moet worden. Een software bill of materials is hierbij een inventaris, geen juridische goedkeuring. De verantwoordelijke moet de gevonden licentie vergelijken met de geplande handeling en met eventuele wijzigingen aan het onderdeel.
Drie licentievragen die verschillende controles vragen
Bij de MIT-licentie ligt een belangrijke verplichting bij het behouden van de copyrightvermelding en toestemmingstekst in de beschreven kopieën of substantiële delen. Dat vraagt een controle van wat met uw product wordt meegeleverd. “Er staat ergens open source op de website” is daarvoor geen precieze uitvoeringsinstructie. Wijs een concrete locatie aan en test of de tekst ook in de uiteindelijke distributie aanwezig is.
Apache License 2.0 kent daarnaast bepalingen over onder meer gewijzigde bestanden, relevante vermeldingen en een eventueel NOTICE-bestand. De licentie bevat ook een octrooilicentie met voorwaarden en geeft niet algemeen het recht de merken van de oorspronkelijke aanbieder te gebruiken. Behandel een leverancierslogo in uw verkoopmateriaal daarom afzonderlijk van het recht om de code te verwerken.
Bij copyleftlicenties moet worden onderzocht welke verplichtingen voor broncode en verdere licentieverlening ontstaan in de concrete combinatie. De precieze tekst en architectuur zijn bepalend; het woord copyleft alleen beantwoordt dit niet. Ga evenmin automatisch ervan uit dat servergebruik iedere verplichting uitsluit. Leg de toepasselijke licentieversie, technische koppeling en manier van aanbieden naast elkaar voordat een definitieve productbelofte aan een klant wordt gedaan.
Ontwerp een releasecontrole met een aantoonbaar resultaat
Laat engineering een bevroren inventaris van de release opleveren. Een tweede beoordeling koppelt ieder onderdeel aan de vereiste notices, eventuele broncodelevering en openstaande vragen. De commerciële verantwoordelijke bekijkt vervolgens of contractuele beloften aan afnemers hiermee verenigbaar zijn. Een garantie dat alle geleverde software uitsluitend zelf is geschreven past bijvoorbeeld niet bij een product dat aantoonbaar externe componenten bevat.
Bewaar de uitkomst bij het releasenummer. Als later een klant vraagt welke rechten bij versie drie hoorden, is een actuele dependencylijst van versie vijf geen betrouwbaar antwoord. Archiveer daarom ook de bijbehorende licentieteksten en de feitelijk meegeleverde bestanden. Geef openstaande punten een eigenaar en een besluit: component vervangen, toepassing aanpassen, aanvullende toestemming onderzoeken of de release uitstellen. Een leeg risicoveld geldt niet als afhandeling.
Een interne proef wordt een klantinstallatie
Neem als fictieve illustratie een analysehulpmiddel dat maandenlang alleen intern is getest. De commerciële afdeling wil het vervolgens als kant-en-klaar installatiepakket aan klanten geven. De ontwikkelaars hebben de licenties tijdens de proef nog niet beoordeeld op externe levering. Het beslispunt is nu de veranderde verspreiding. Een eerdere interne goedkeuring kan niet zonder meer als toestemming voor de klantversie worden gebruikt.
Maak in deze situatie eerst een schoon installatiepakket en inventariseer precies wat daarin zit. Controleer daarna de benodigde teksten en eventuele broncodeverplichtingen. Als een onderdeel wordt vervangen, test ook of oude bestanden uit het pakket zijn verdwenen. Laat de verkoopdocumentatie pas daarna aansluiten op het werkelijke resultaat. Daarmee wordt een juridische correctie verbonden met een controleerbare technische wijziging, in plaats van alleen met een aangepaste contractzin.
Beheer uitzonderingen zonder het overzicht kwijt te raken
Soms wordt een commerciële licentie voor een anders problematisch onderdeel aangeboden. Controleer dan wie de overeenkomst sluit, welke versies zij omvat en of groepsmaatschappijen of klanten eronder vallen. Een betaalde licentie voor één ontwikkelaar is niet noodzakelijk dezelfde toestemming als distributie aan alle afnemers. Bewaar de overeenkomst bij het componentregister en noteer wat bij beëindiging of een volgende hoofdversie opnieuw moet worden bekeken.
De rechten op uw eigen programmatuur blijven een afzonderlijke vraag. Voor bijdragen van werknemers en externe ontwikkelaars is de gids over softwareauteursrecht en de rechtenketen relevant. Open source naleving bewijst niet dat alle zelfgeschreven code correct aan de onderneming toekomt. Een bruikbare productmap bevat beide controles, met een helder onderscheid tussen externe licentievoorwaarden en afspraken over eigen ontwikkeling.
Bronnen bij dit onderwerp
- Open Source Initiative — MIT LicenseGeraadpleegd op 2026-09-14
- Apache Software Foundation — Apache License 2.0Geraadpleegd op 2026-09-14
- Richtlijn 2009/24/EG — Rechtsbescherming computerprogramma’s