Sjekkliste for lisensetterlevelse: hva dere må verifisere før dere deler bevis

En god side identifiserer det leverte produktet, lister opp tredjepartskomponenter med gjennomgåtte lisenser, inkluderer fullstendig lisenstekst eller pålitelige lenker, og viser navngivelse der lisensene krever det. Innkjøp og revisorer forventer mer enn en liste over npm-pakker.

Hvis siden din bare sier "vi bruker open source" uten oversikt, lisenstekst eller et tydelig omfang, vil den ikke tilfredsstille en forespørsel om offentliggjøring av tredjepartslisenser. Det gjelder selv om ingeniørene har bestått en intern sikkerhetsgjennomgang.

Behovet er bredt: Black Ducks Open Source Security and Risk Analysis fra 2025 fant at 97 % av reviderte kodebaser inneholdt open source, så nesten alle produkter har tredjepartsforpliktelser, uansett om de er dokumentert eller ikke.

• Produktnavn og versjon (eller utgivelseskanal) siden dekker.
• Oversikt over tredjeparts- og open source-komponenter, direkte og transitive der prosessen din krever det.
• SPDX-stil eller tilsvarende lisensidentifikatorer, etter menneskelig gjennomgang, ikke bare registergjetninger.
• Fullstendig lisenstekst for hver komponent, eller stabile lenker som fører til fullstendig tekst.
• Navngivelses- og notice-blokker der MIT, Apache, BSD, GPL eller egendefinerte lisenser krever dem.
• Tydelig merking dersom siden er eksempel, beta eller produksjon, der det er relevant.

Lisensetterlevelse starter med oversikten: Hver komponent på etterlevelsessiden din bør stemme med den nåværende leverte byggeversjonen, ikke en dev-branch, ikke staging, ikke en produktlinje du ikke selger ennå.

Team går ofte glipp av fonter, ikonpakker, analyse-SDK-er, innebygd JavaScript på markedsføringsnettsteder, og transitive avhengigheter som følger med én enkelt direkte import. Etterlevelsen svikter stille når oversikten er ufullstendig. Black Ducks OSSRA 2025 rapporterer at transitive avhengigheter forårsaket nesten 30 % av lisenskonfliktene den fant, så en sjekkliste som stopper ved direkte importer, går glipp av en stor del av risikoen.

• Hver komponent på siden stemmer med byggeversjonen kundene mottar i dag.
• Transitive npm-, pnpm-, yarn-, Go-, Rust-, Python-, Java-, .NET-, PHP- eller Ruby-avhengigheter er inkludert i tråd med retningslinjene deres.
• Fonter, ikoner, bilder med lisensvilkår og kommersielle SDK-er blir ikke hoppet over.
• Container-basislag og medfølgende native biblioteker er inkludert i omfanget hvis dere distribuerer dem.
• Elementer merket ukjent eller trenger gjennomgang, er avklart eller uttrykkelig utelatt med dokumentert begrunnelse.
• Kilden til oversikten (lockfile, CycloneDX SBOM, manuell oppføring) kan spores tilbake til utgivelsen.

Det krever at de som gjennomgår, kan lese selve lisensen, ikke et sammendrag: Offentliggjøring av tredjepartslisenser betyr fullstendig lisenstekst per komponent. Innkjøp og juridisk sammenligner siden din med forpliktelsene i GPL, LGPL, Apache, MIT og proprietære SDK-avtaler.

Navngivelse er atskilt fra notice og atskilt fra fullstendig lisenstekst. En side som bare lister "MIT" uten MIT-lisensteksten eller den påkrevde opphavsrettsmerknaden, er ufullstendig for de fleste enterprise-gjennomganger.

• Hver komponent har en identifisert lisens, gjennomgått av et menneske, ikke blindt kopiert fra pakkemetadata.
• Fullstendig lisenstekst finnes på siden eller er lenket til, uten innloggingskrav eller utløpende URL-er.
• Copyleft-komponenter (GPL, AGPL, LGPL osv.) har passert de interne godkjenningssperrene deres.
• Navngivelsesteksten samsvarer med det hver lisens krever, ikke en generisk "open source-lisenser"-bunntekst.
• Komponenter med dobbel lisens eller egendefinerte lisenser har en uttrykkelig beslutning registrert.
• Ingen komponent publiseres som godkjent før lisensteksten er lagt ved eller lenket til.

En lisensetterlevelsesside er et levende dokument. URL-en innkjøp lagret i leverandørfilen sin, bør fortsatt være korrekt etter din neste utgivelse. Etterlevelsen brytes når siden avviker fra det som faktisk leveres.

Publiseringssperrer (gjennomgang før publisering) hindrer team i å hevde etterlevelse de ikke har verifisert. Eksporter (JSON, navngivelsesfiler, offentliggjøringspakker) bør stemme med den samme gjennomgåtte oversikten som den offentlige URL-en.

• En navngitt eier godkjente publiseringen for dette produktet og denne utgivelsen.
• URL-en til etterlevelsessiden er stabil, offentlig og tilgjengelig uten innlogging.
• Eksporter og utgivelsespakker stemmer med den publiserte oversikten.
• Avvikssjekker eller pipeline-sjekker flagger nye pakker før neste kunderevisjon.
• Dere har en dokumentert prosess for å oppdatere lisenssiden når avhengigheter endres.
• Dere antyder ikke juridisk godkjenning med mindre juridisk faktisk har gjennomgått det. Siden er et operativt dokument.

Åpne lisensetterlevelsessiden i et inkognitovindu. Bekreft at den laster, identifiser produktet, og stikkprøvekontroller fem tilfeldige komponenter mot den interne oversikten deres. Hvis innkjøp ber om dokumentasjon, er det nettopp dette de vil gjøre.

Når sjekklisten er bestått, send det formatet de ba om (URL, eksport eller vedlegg) fra det samme gjennomgåtte publiseringsøyeblikksbildet. Navngi produktet og utgivelsen eller datoen det gjenspeiler. Filtypen betyr mindre enn om oversikten var gjennomgått og godkjent før du sendte den.

Nei. En SBOM-sjekkliste bekrefter komponentidentitet i et maskinlesbart format. En sjekkliste for lisensetterlevelse bekrefter gjennomgåtte lisenser, full tekst, attribusjon og en publiseringstilstand dere er villige til å dele. Dere trenger ofte begge, i den rekkefølgen.

Kjør den på nytt før enhver ekstern deling, og igjen når avhengigheter endres på en overvåket release-branch. Drift mellom siste godkjente publisering og gjeldende lockfil er den vanlige feiltilstanden.

Velg én ansvarlig eier per produkt, vanligvis engineering med juridisk gjennomgang av høyrisikolisenser. Delt eierskap uten en publiseringsgate er hvordan utdaterte URL-er ender i vendor-filer.