123% fler rapporterade CVE:er per dag 2026 än förra året.

Beroenden

Licensefterlevnad för open source

Open source är fritt att använda, men inte fritt från villkor. Varje paket kommer med en licens, och licensefterlevnad för open source innebär att veta vilka licenser som finns i din produkt och att uppfylla det de kräver av dig. De flesta av de licenserna kommer in via beroenden som ingen i ditt team har valt.

Uppdaterad

Den här sidan är allmän information, inte juridisk rådgivning. Tala med en jurist om beslut som gäller en specifik produkt.

Typer av open source-licenser

Typ Exempel Vad den oftast kräver
Tillåtande MIT, BSD, Apache-2.0 Behåll upphovsrätts- och licensmeddelandena. Apache-2.0 har också patentvillkor.
Svag copyleft LGPL, MPL-2.0 Dela ändringar i själva den licensierade komponenten
Stark copyleft GPL-2.0, GPL-3.0 Programvara som distribueras med den måste erbjudas under samma villkor, med källkod
Nätverks-copyleft AGPL-3.0 Som stark copyleft, och gäller även när användare interagerar med programvaran över ett nätverk
Source-available BUSL, SSPL Inte open source: källkoden är synlig, men användningen är begränsad

Vad är en copyleft-licens?

En copyleft-licens låter dig använda, ändra och dela programvara, under förutsättning att det du distribuerar förblir under samma villkor. Det håller open source öppet. Risken för en kommersiell produkt är att en komponent med stark copyleft som länkas in i din kod kan väcka frågan om din egen kod också måste släppas.

Om det gäller beror på hur komponenten används och hur produkten levereras. Programvara som du distribuerar till kunder är mer utsatt än ett internt verktyg, och en SaaS-produkt undviker oftast GPL:s distributionsvillkor men inte AGPL:s.

Vanliga risker för efterlevnaden

  • Transitiva licenser. Ett paket med tillåtande licens kan vara beroende av ett med copyleft. Om du bara kontrollerar direkta beroenden missar du det.
  • Saknade licensmeddelanden. De flesta licenser kräver att du behåller attribueringen, och en bortglömd notices-fil är det vanligaste felet.
  • Ändrade licenser. Ett projekt kan byta licens i en ny version, så en uppgradering kan ändra dina villkor.
  • Deklarerat kontra faktiskt. Metadata för ett paket kan vara fel eller ofullständiga, och vendorerad kod kan ha en egen licens.
  • Due diligence. Förvärvare och stora kunder ber om en licensförteckning, oftast med kort varsel.

Så följer du licensvillkoren

  1. Skriv en policy. Bestäm vilka licenser som är tillåtna, vilka som kräver granskning och vilka som är förbjudna, per typ av produkt.
  2. Bygg en förteckning. En SBOM listar varje komponent med dess licens, inklusive transitiva beroenden.
  3. Kontrollera automatiskt. Upprätthåll policyn i CI, så att ett nytt beroende stoppas när det läggs till i stället för vid en revision.
  4. Uppfyll skyldigheterna. Generera notices-filer och tillhandahåll källkod där en licens kräver det.
  5. Spara registreringarna. Lagra förteckningen per release, eftersom frågan oftast gäller en version du redan har levererat.

Vad programvara för licensefterlevnad gör

Licensefterlevnad är en standarddel av software composition analysis. Verktygen identifierar komponenter, rapporterar deras licenser och flaggar brott mot din policy. De skiljer sig i djup:

  • Deklarerade licenser: de flesta verktyg läser vad varje paket deklarerar i sina metadata. Det går snabbt och täcker det vanliga fallet.
  • Djup licensskanning: FOSSA och Black Duck analyserar också licenstext i koden och hjälper till med attribueringsrapporter och juridisk granskning. Se CRACI vs FOSSA och CRACI vs Black Duck.
  • Gratisverktyg: många SBOM-generatorer och SCA-skannrar rapporterar deklarerade licenser utan kostnad. Se de bästa SCA-verktygen.

Var CRACI passar in

CRACI hanterar deklarerade licenser i bygget. Som din GitHub Actions-runner registrerar CRACI varje paket som ett jobb drar in, och vart och ett har sin deklarerade licens, så copyleft-licenser fångas innan de hamnar i produkten. Regler för licenspolicy kan blockera ett bygge på grund av en licens, och SBOM-exporter i CycloneDX och SPDX inkluderar varje komponents deklarerade licens. CRACI utgår från vad paketen deklarerar, så om du behöver arbetsflöden för juridisk granskning eller analys av licenstext, använd ett specialistverktyg vid sidan av.

Licensefterlevnad för open source: vanliga frågor

Vad är licensefterlevnad för open source?

Det innebär att veta vilka open source-licenser som gäller för programvaran du använder och att uppfylla deras villkor, till exempel att behålla licensmeddelanden eller dela källkod.

Vad är en copyleft-licens?

En licens som låter dig använda och ändra programvara under förutsättning att det du distribuerar förblir under samma villkor. GPL är det mest kända exemplet.

Får du använda GPL-kod i kommersiell programvara?

Ja, men om du distribuerar programvara som innehåller den kan du behöva erbjuda den programvarans källkod under GPL. Det spelar roll hur koden kombineras, så skaffa juridisk rådgivning för ditt fall.

Gäller copyleft för SaaS?

GPL:s villkor utlöses i allmänhet av distribution, som SaaS oftast undviker. AGPL täpper till den luckan genom att utvidga villkoren till användare som interagerar med programvaran över ett nätverk.

Vilken är den säkraste open source-licensen för kommersiell användning?

Tillåtande licenser som MIT, BSD och Apache-2.0 kräver minst. Du måste ändå behålla deras licensmeddelanden.

Hur kontrollerar du licenserna för dina beroenden?

Generera en SBOM som innehåller transitiva beroenden och deklarerade licenser, eller använd ett SCA-verktyg. Upprätthåll din policy i CI, så att nya överträdelser får bygget att misslyckas.

Fånga copyleft före leverans

Se den deklarerade licensen för varje paket som ett GitHub Actions-jobb drog in, och blockera ett bygge utifrån din policy.

Boka en demo