Naleving van open-sourcelicenties

Deze pagina bevat algemene informatie en is geen juridisch advies. Overleg voor beslissingen over een specifiek product met een advocaat.

Soorten open-sourcelicenties

Type	Voorbeelden	Wat het meestal vraagt
Permissief	MIT, BSD, Apache-2.0	Behoud de auteursrechtvermeldingen en licentieteksten. Apache-2.0 bevat ook patentvoorwaarden.
Zwakke copyleft	LGPL, MPL-2.0	Deel wijzigingen aan het gelicentieerde component zelf
Sterke copyleft	GPL-2.0, GPL-3.0	Software die ermee wordt gedistribueerd, moet onder dezelfde voorwaarden worden aangeboden, met broncode
Netwerk-copyleft	AGPL-3.0	Zoals sterke copyleft, en het geldt ook wanneer gebruikers via een netwerk met de software werken
Source-available	BUSL, SSPL	Geen open source: de broncode is zichtbaar, maar het gebruik is beperkt

Wat is een copyleftlicentie?

Met een copyleftlicentie mag u software gebruiken, wijzigen en delen, op voorwaarde dat wat u distribueert onder dezelfde voorwaarden blijft. Zo blijft open source open. Het risico voor een commercieel product is dat een component met sterke copyleft dat aan uw code is gelinkt, de vraag kan oproepen of uw eigen code ook moet worden vrijgegeven.

Of dat zo is, hangt af van hoe het component wordt gebruikt en hoe het product wordt geleverd. Software die u aan klanten distribueert, loopt meer risico dan een interne tool, en een SaaS-product ontkomt meestal aan de distributievoorwaarden van de GPL, maar niet aan die van de AGPL.

Veelvoorkomende compliancerisico's

• Transitieve licenties. Een permissief pakket kan afhankelijk zijn van een copyleftpakket. Wie alleen directe afhankelijkheden controleert, mist dit.
• Ontbrekende vermeldingen. De meeste licenties vragen u de naamsvermelding te behouden, en een vergeten notices-bestand is de meest voorkomende fout.
• Gewijzigde licenties. Een project kan in een nieuwe versie van licentie veranderen, dus een upgrade kan uw voorwaarden wijzigen.
• Gedeclareerd vs werkelijk. De metadata van een pakket kan onjuist of onvolledig zijn, en vendored code kan een eigen licentie hebben.
• Due diligence. Overnemende partijen en grote klanten vragen om een licentie-inventaris, meestal op korte termijn.

Hoe u compliant blijft

1. Schrijf een beleid. Bepaal per producttype welke licenties zijn toegestaan, welke een review nodig hebben en welke verboden zijn.
2. Stel een inventaris op. Een SBOM vermeldt elk component met zijn licentie, inclusief transitieve afhankelijkheden.
3. Controleer automatisch. Handhaaf het beleid in CI, zodat een nieuwe afhankelijkheid wordt afgewezen op het moment dat ze wordt toegevoegd en niet pas bij een audit.
4. Voldoe aan de verplichtingen. Genereer notices-bestanden en stel broncode beschikbaar waar een licentie dat vereist.
5. Bewaar de gegevens. Sla de inventaris per release op, want de vraag gaat meestal over een versie die u al hebt geleverd.

Wat software voor licentiecompliance doet

Licentiecompliance is een standaardonderdeel van software composition analysis. Tools identificeren componenten, rapporteren hun licenties en markeren overtredingen van uw beleid. Ze verschillen in diepgang:

• Gedeclareerde licenties: de meeste tools lezen wat elk pakket in zijn metadata declareert. Dat is snel en dekt het gangbare geval.
• Diepgaand licentiescannen: FOSSA en Black Duck analyseren ook licentietekst in de code, en helpen bij attributierapporten en juridische review. Zie CRACI vs FOSSA en CRACI vs Black Duck.
• Gratis tools: veel SBOM-generatoren en SCA-scanners rapporteren gedeclareerde licenties zonder kosten. Zie de beste SCA-tools.

De rol van CRACI

CRACI behandelt gedeclareerde licenties in de build. Als uw GitHub Actions-runner legt het elk pakket vast dat een job binnenhaalt, en elk pakket draagt zijn gedeclareerde licentie mee, zodat copyleftlicenties worden opgemerkt voordat ze in het product belanden. Licentiebeleidsregels kunnen een build op een licentie blokkeren, en SBOM-exports in CycloneDX en SPDX bevatten de gedeclareerde licentie van elk component. CRACI werkt met wat pakketten declareren, dus als u workflows voor juridische review of analyse van licentieteksten nodig hebt, gebruik dan een gespecialiseerde tool ernaast.

Naleving van open-sourcelicenties: veelgestelde vragen

Wat is naleving van open-sourcelicenties?

Het betekent weten welke open-sourcelicenties gelden voor de software die u gebruikt en voldoen aan hun voorwaarden, zoals het behouden van vermeldingen of het delen van broncode.

Wat is een copyleftlicentie?

Een licentie waarmee u software mag gebruiken en wijzigen, op voorwaarde dat wat u distribueert onder dezelfde voorwaarden blijft. De GPL is het bekendste voorbeeld.

Mag u GPL-code gebruiken in commerciële software?

Ja, maar als u software distribueert waarin die code zit, moet u de broncode van die software mogelijk onder de GPL aanbieden. Het maakt uit hoe de code wordt gecombineerd, dus vraag juridisch advies voor uw situatie.

Geldt copyleft voor SaaS?

De voorwaarden van de GPL gelden doorgaans bij distributie, en die vermijdt SaaS meestal. De AGPL dicht dat gat door de voorwaarden uit te breiden naar gebruikers die via een netwerk met de software werken.

Wat is de veiligste open-sourcelicentie voor commercieel gebruik?

Permissieve licenties zoals MIT, BSD en Apache-2.0 vragen het minst. Hun vermeldingen moet u nog steeds behouden.

Hoe controleert u de licenties van uw afhankelijkheden?

Genereer een SBOM met transitieve afhankelijkheden en gedeclareerde licenties, of gebruik een SCA-tool. Handhaaf uw beleid in CI, zodat nieuwe overtredingen de build laten mislukken.