Lisensetterlevelse for åpen kildekode

Denne siden er generell informasjon, ikke juridisk rådgivning. For beslutninger om et bestemt produkt bør du snakke med en advokat.

Typer lisenser for åpen kildekode

Type	Eksempler	Hva den vanligvis krever
Tillatende	MIT, BSD, Apache-2.0	Behold opphavsretts- og lisensmerknadene. Apache-2.0 har også patentvilkår.
Svak copyleft	LGPL, MPL-2.0	Del endringer i selve den lisensierte komponenten
Sterk copyleft	GPL-2.0, GPL-3.0	Programvare som distribueres med den, må tilbys på samme vilkår, med kildekode
Nettverks-copyleft	AGPL-3.0	Som sterk copyleft, og gjelder også når brukere samhandler med programvaren over et nettverk
Source-available	BUSL, SSPL	Ikke åpen kildekode: Kildekoden er synlig, men bruken er begrenset

Hva er en copyleft-lisens?

En copyleft-lisens lar deg bruke, endre og dele programvare, på betingelse av at det du distribuerer, forblir under de samme vilkårene. Den holder åpen kildekode åpen. Risikoen for et kommersielt produkt er at en komponent med sterk copyleft som lenkes inn i koden din, kan reise spørsmålet om din egen kode også må frigis.

Om det gjelder, avhenger av hvordan komponenten brukes og hvordan produktet leveres. Programvare du distribuerer til kunder, er mer utsatt enn et internt verktøy, og et SaaS-produkt unngår vanligvis distribusjonsvilkårene i GPL, men ikke dem i AGPL.

Vanlige risikoer ved etterlevelse

• Transitive lisenser. En tillatende pakke kan være avhengig av en copyleft-pakke. Sjekker du bare direkte avhengigheter, går du glipp av dette.
• Manglende merknader. De fleste lisenser ber deg beholde kreditering, og en glemt fil med merknader er den vanligste feilen.
• Endrede lisenser. Et prosjekt kan bytte lisens i en ny versjon, så en oppgradering kan endre vilkårene dine.
• Deklarert vs faktisk. Metadataene til en pakke kan være feil eller ufullstendige, og vendor-kode kan ha sin egen lisens.
• Due diligence. Oppkjøpere og store kunder ber om en lisensoversikt, vanligvis på kort varsel.

Slik holder du deg innenfor lisensene

1. Skriv en policy. Bestem hvilke lisenser som er tillatt, hvilke som krever gjennomgang, og hvilke som er forbudt, etter produkttype.
2. Bygg en oversikt. En SBOM lister hver komponent med lisensen, inkludert transitive avhengigheter.
3. Sjekk automatisk. Håndhev policyen i CI, så en ny avhengighet feiler idet den legges til og ikke i en revisjon.
4. Oppfyll forpliktelsene. Generer filer med merknader, og gjør kildekoden tilgjengelig der en lisens krever det.
5. Ta vare på dokumentasjonen. Lagre oversikten per utgivelse, fordi spørsmålet vanligvis gjelder en versjon du allerede har levert.

Hva programvare for lisensetterlevelse gjør

Lisensetterlevelse er en standard del av software composition analysis. Verktøy identifiserer komponenter, rapporterer lisensene deres og flagger brudd på policyen din. De skiller seg i dybde:

• Deklarerte lisenser: De fleste verktøy leser det hver pakke deklarerer i metadataene sine. Dette går raskt og dekker det vanlige tilfellet.
• Dyp lisensskanning: FOSSA og Black Duck analyserer også lisenstekst i koden og hjelper med krediteringsrapporter og juridisk gjennomgang. Se CRACI vs FOSSA og CRACI vs Black Duck.
• Gratisverktøy: Mange SBOM-generatorer og SCA-skannere rapporterer deklarerte lisenser uten kostnad. Se de beste SCA-verktøyene.

Hvor CRACI passer inn

CRACI håndterer deklarerte lisenser i bygget. Som GitHub Actions-runneren din registrerer CRACI hver pakke en jobb trekker inn, og hver av dem tar med seg sin deklarerte lisens, så copyleft-lisenser fanges opp før de havner i produktet. Regler i lisenspolicyen kan blokkere et bygg på grunn av en lisens, og SBOM-eksporter i CycloneDX og SPDX inkluderer den deklarerte lisensen til hver komponent. CRACI arbeider ut fra det pakker deklarerer, så trenger du arbeidsflyter for juridisk gjennomgang eller analyse av lisenstekst, bør du bruke et spesialistverktøy ved siden av.

Lisensetterlevelse for åpen kildekode: ofte stilte spørsmål

Hva er lisensetterlevelse for åpen kildekode?

Det betyr å vite hvilke lisenser for åpen kildekode som gjelder for programvaren du bruker, og å oppfylle betingelsene deres, for eksempel å beholde merknader eller dele kildekode.

Hva er en copyleft-lisens?

En lisens som lar deg bruke og endre programvare på betingelse av at det du distribuerer, forblir under de samme vilkårene. GPL er det best kjente eksempelet.

Kan du bruke GPL-kode i kommersiell programvare?

Ja, men hvis du distribuerer programvare som inneholder den, kan du måtte tilby kildekoden til den programvaren under GPL. Hvordan koden kombineres, har betydning, så få juridisk rådgivning for ditt tilfelle.

Gjelder copyleft for SaaS?

Vilkårene i GPL utløses vanligvis av distribusjon, som SaaS som regel unngår. AGPL tetter det hullet ved å utvide betingelsene til brukere som samhandler med programvaren over et nettverk.

Hva er den tryggeste lisensen for åpen kildekode til kommersiell bruk?

Tillatende lisenser som MIT, BSD og Apache-2.0 krever minst. Du må likevel beholde merknadene deres.

Hvordan sjekker du lisensene til avhengighetene dine?

Generer en SBOM som inkluderer transitive avhengigheter og deklarerte lisenser, eller bruk et SCA-verktøy. Håndhev policyen din i CI, så nye brudd får bygget til å feile.