Checklista för licensefterlevnad: vad ni ska verifiera innan ni delar bevis

En stark sida identifierar den levererade produkten, listar tredjepartskomponenter med granskade licenser, innehåller fullständig licenstext eller tillförlitliga länkar, och visar attribuering där licenserna kräver det. Inköp och revisorer förväntar sig mer än en lista med npm-paket.

Om din sida bara säger “vi använder open source” utan förteckning, licenstext eller ett tydligt omfång, uppfyller den inte en begäran om redovisning av tredjepartslicenser. Det gäller även om utvecklingsteamet klarat en intern säkerhetsgranskning.

Behovet är brett: Black Ducks rapport 2025 Open Source Security and Risk Analysis (OSSRA) fann att 97 % av granskade kodbaser innehöll open source, så nästan varje produkt bär tredjepartsskyldigheter, oavsett om de är dokumenterade eller inte.

• Produktnamn och version (eller releasekanal) som sidan omfattar.
• Förteckning över tredjeparts- och open source-komponenter, direkta och transitiva där din process kräver det.
• Licensidentifierare i SPDX-format eller motsvarande, efter mänsklig granskning, inte enbart registrets gissningar.
• Fullständig licenstext för varje komponent, eller stabila länkar som leder till fullständig text.
• Attribuerings- och meddelandeblock där MIT, Apache, BSD, GPL eller egna licenser kräver dem.
• Tydlig märkning om sidan är exempel, beta eller produktion, där det är relevant.

Licensefterlevnad börjar med förteckningen: Varje komponent på din licenssida ska matcha det aktuellt levererade bygget, inte en dev-branch, inte staging, inte en produktlinje du inte säljer än.

Team missar ofta typsnitt, ikonpaket, analys-SDK:er, inbäddad JavaScript på marknadsföringssajter, och transitiva beroenden som dras in av en enda direkt import. Efterlevnaden brister tyst när förteckningen är ofullständig. Black Ducks OSSRA 2025 rapporterar att transitiva beroenden orsakade nästan 30 % av licenskonflikterna som hittades, så en checklista som stannar vid direkta importer missar en stor del av risken.

• Varje komponent på sidan matchar det bygge kunderna får idag.
• Transitiva beroenden från npm, pnpm, yarn, Go, Rust, Python, Java, .NET, PHP eller Ruby ingår enligt din policy.
• Typsnitt, ikoner, bilder med licensvillkor och kommersiella SDK:er hoppas inte över.
• Containrars bas-lager och medföljande native-bibliotek ingår i omfånget om du distribuerar dem.
• Poster märkta som “okänd” eller “väntar på granskning” är antingen lösta eller uttryckligen undantagna med dokumenterad anledning.
• Förteckningens källa (lockfile, CycloneDX SBOM, manuell post) går att spåra till releasen.

Det kräver att granskare kan läsa den faktiska licensen, inte en sammanfattning: Redovisning av tredjepartslicenser innebär fullständig licenstext per komponent. Inköp och juridik jämför din sida mot skyldigheterna i GPL, LGPL, Apache, MIT och proprietära SDK-avtal.

Attribuering är skilt från meddelande och skilt från fullständig licenstext. En sida som anger “MIT” utan MIT-licensens text eller obligatoriskt upphovsrättsmeddelande är ofullständig för de flesta enterprise-granskningar.

• Varje komponent har en identifierad licens, granskad av en människa, inte blint kopierad från paketmetadata.
• Fullständig licenstext finns på sidan eller länkad, utan inloggningskrav eller URL:er som slutar gälla.
• Copyleft-komponenter (GPL, AGPL, LGPL med flera) har passerat dina interna granskningsgrindar.
• Attribueringstexten matchar vad varje licens kräver, inte en generisk sidfot om “open source-licenser”.
• Dubbellicensierade eller egna komponenter har ett uttryckligt beslut dokumenterat.
• Ingen komponent publiceras som godkänd förrän licenstext är bifogad eller länkad.

En licenssida är en levande redovisning. URL:en som inköp sparade i sin leverantörsfil ska fortfarande stämma efter din nästa release. Efterlevnaden brister när sidan glider isär från det som levereras.

Publiceringsgrindar (granskning före publicering) hindrar team från att påstå efterlevnad de inte har verifierat. Exporter (JSON, attribueringsfiler, redovisningspaket) ska matcha samma granskade förteckning som den offentliga URL:en.

• En namngiven ägare godkände publiceringen för den här produkten och releasen.
• Licenssidans URL är stabil, offentlig och nåbar utan autentisering.
• Exporter och releasepaket matchar den publicerade förteckningen.
• Avvikelsekontroller eller pipelinekontroller flaggar nya paket före nästa kundrevision.
• Du har en dokumenterad process för att uppdatera licenssidan när beroenden ändras.
• Du antyder inte juridiskt godkännande om inte en jurist har granskat det. Sidan är en operativ redovisning.

Öppna licenssidan i ett inkognitofönster. Bekräfta att den laddas, identifiera produkten, och stickprovskontrollera fem slumpmässiga komponenter mot din interna förteckning. Om inköp ber om bevis är det här vad de kommer att göra.

När checklistan är godkänd, skicka vilket format de än bad om (URL, export eller bilaga) från samma granskade publiceringsögonblicksbild. Namnge produkten och den release eller det datum den speglar. Filtypen spelar mindre roll än om förteckningen granskades och godkändes innan du skickade den.

Nej. En SBOM-checklista bekräftar komponentidentitet i ett maskinläsbart format. En checklista för licensefterlevnad bekräftar granskade licenser, fulltext, attribution och ett publiceringsläge ni är villiga att dela. Ni behöver ofta båda, i den ordningen.

Kör den igen före varje extern delning, och igen när beroenden ändras på en övervakad release-branch. Drift mellan den senast godkända publiceringen och aktuell lockfil är det vanliga felfallet.

Välj en ansvarig ägare per produkt, vanligtvis engineering med juridisk granskning av högrisklicenser. Delat ägarskap utan en publiceringsgate är hur föråldrade URL:er hamnar i vendor-filer.