Open source-licenscompliance

Denne side er generel information, ikke juridisk rådgivning. Tal med en advokat om beslutninger om et bestemt produkt.

Typer af open source-licenser

Type	Eksempler	Hvad den som regel kræver
Permissiv	MIT, BSD, Apache-2.0	Bevar copyright- og licensmeddelelserne. Apache-2.0 har også patentvilkår.
Svag copyleft	LGPL, MPL-2.0	Del ændringer i selve den licenserede komponent
Stærk copyleft	GPL-2.0, GPL-3.0	Software, der distribueres med den, skal tilbydes under de samme vilkår, med kildekode
Netværks-copyleft	AGPL-3.0	Som stærk copyleft, og den gælder også, når brugere interagerer med softwaren over et netværk
Source-available	BUSL, SSPL	Ikke open source: Kildekoden er synlig, men brugen er begrænset

Hvad er en copyleft-licens?

En copyleft-licens lader dig bruge, ændre og dele software på betingelse af, at det, du distribuerer, forbliver under de samme vilkår. Den holder open source åben. Risikoen for et kommercielt produkt er, at en stærk copyleft-komponent, der er linket ind i din kode, kan rejse spørgsmålet om, hvorvidt din egen kode også skal frigives.

Om det gælder, afhænger af, hvordan komponenten bruges, og hvordan produktet leveres. Software, du distribuerer til kunder, er mere udsat end et internt værktøj, og et SaaS-produkt undgår som regel GPL's distributionsvilkår, men ikke AGPL's.

Almindelige compliance-risici

• Transitive licenser. En permissiv pakke kan afhænge af en copyleft-pakke. Tjekker du kun direkte afhængigheder, overser du det.
• Manglende licensmeddelelser. De fleste licenser beder dig bevare attribution, og en glemt fil med licensmeddelelser er den mest almindelige fejl.
• Ændrede licenser. Et projekt kan skifte licens i en ny version, så en opgradering kan ændre dine vilkår.
• Deklareret vs. faktisk. En pakkes metadata kan være forkerte eller ufuldstændige, og vendoret kode kan have sin egen licens.
• Due diligence. Opkøbere og store kunder beder om en licensfortegnelse, som regel med kort varsel.

Sådan forbliver du compliant

1. Skriv en policy. Afgør pr. produkttype, hvilke licenser der er tilladt, hvilke der kræver gennemgang, og hvilke der er forbudt.
2. Byg en fortegnelse. En SBOM viser hver komponent med dens licens, inklusive transitive afhængigheder.
3. Tjek automatisk. Håndhæv policyen i CI, så en ny afhængighed fejler, når den tilføjes, og ikke ved en audit.
4. Opfyld forpligtelserne. Generér filer med licensmeddelelser, og stil kildekode til rådighed, hvor en licens kræver det.
5. Behold registreringerne. Gem fortegnelsen pr. release, fordi spørgsmålet som regel handler om en version, du allerede har leveret.

Hvad software til licenscompliance gør

Licenscompliance er en fast del af software composition analysis. Værktøjer identificerer komponenter, rapporterer deres licenser og markerer brud på din policy. De varierer i dybde:

• Deklarerede licenser: De fleste værktøjer læser, hvad hver pakke deklarerer i sine metadata. Det er hurtigt og dækker det almindelige tilfælde.
• Dyb licensscanning: FOSSA og Black Duck analyserer også licenstekst i koden og hjælper med attributionsrapporter og juridisk gennemgang. Se CRACI vs. FOSSA og CRACI vs. Black Duck.
• Gratis værktøjer: Mange SBOM-generatorer og SCA-scannere rapporterer deklarerede licenser uden beregning. Se de bedste SCA-værktøjer.

Hvor CRACI passer ind

CRACI håndterer deklarerede licenser i buildet. Som din GitHub Actions-runner registrerer det hver pakke, et job trækker ind, og hver af dem har sin deklarerede licens med, så copyleft-licenser bliver fanget, før de ender i produktet. Licenspolicy-regler kan blokere et build på grund af en licens, og SBOM-eksporter i CycloneDX og SPDX indeholder hver komponents deklarerede licens. CRACI arbejder ud fra, hvad pakker deklarerer. Har du brug for workflows til juridisk gennemgang eller analyse af licenstekst, så brug et specialiseret værktøj ved siden af.

Open source-licenscompliance: ofte stillede spørgsmål

Hvad er open source-licenscompliance?

Det betyder, at du ved, hvilke open source-licenser der gælder for den software, du bruger, og opfylder deres betingelser, for eksempel ved at bevare licensmeddelelser eller dele kildekode.

Hvad er en copyleft-licens?

En licens, der lader dig bruge og ændre software på betingelse af, at det, du distribuerer, forbliver under de samme vilkår. GPL er det bedst kendte eksempel.

Kan du bruge GPL-kode i kommerciel software?

Ja, men hvis du distribuerer software, der indeholder den, kan du blive nødt til at tilbyde den softwares kildekode under GPL. Det har betydning, hvordan koden kombineres, så få juridisk rådgivning til din situation.

Gælder copyleft for SaaS?

GPL's vilkår udløses generelt af distribution, som SaaS som regel undgår. AGPL lukker det hul ved at udvide betingelserne til brugere, der interagerer med softwaren over et netværk.

Hvad er den sikreste open source-licens til kommerciel brug?

Permissive licenser som MIT, BSD og Apache-2.0 kræver mindst. Du skal stadig bevare deres licensmeddelelser.

Hvordan tjekker du licenserne på dine afhængigheder?

Generér en SBOM, der inkluderer transitive afhængigheder og deklarerede licenser, eller brug et SCA-værktøj. Håndhæv din policy i CI, så nye overtrædelser får buildet til at fejle.