Licens-compliance-tjekliste: hvad I skal verificere, før I deler bevis

En stærk side identificerer produktet i produktion, lister tredjepartskomponenter med gennemgåede licenser, inkluderer fuld licenstekst eller pålidelige links, og viser kildeangivelse, hvor licenser kræver det. Indkøb og revisorer forventer mere end en liste over npm-pakker.

Hvis jeres side blot siger “vi bruger open source” uden oversigt, licenstekst eller et klart omfang, vil den ikke opfylde en anmodning om oplysning om tredjepartslicenser. Det gælder, selv når engineering har bestået en intern sikkerhedsgennemgang.

Behovet er udbredt: Black Ducks Open Source Security and Risk Analysis fra 2025 fandt, at 97 % af de reviderede kodebaser indeholdt open source, så næsten ethvert produkt bærer tredjepartsforpligtelser, uanset om de er dokumenteret.

• Produktnavn og version (eller udgivelseskanal), som siden dækker.
• Oversigt over tredjeparts- og open source-komponenter, direkte og transitive, hvor jeres proces kræver det.
• SPDX-stil eller tilsvarende licens-id'er, efter menneskelig gennemgang, ikke kun registrets gæt.
• Fuld licenstekst for hver komponent, eller stabile links, der fører til fuld tekst.
• Kildeangivelses- og notice-blokke, hvor MIT, Apache, BSD, GPL eller specialtilpassede licenser kræver dem.
• Tydelig mærkning af, om siden er eksempel, beta eller produktion, hvor det er relevant.

Licens-compliance starter med oversigten: Hver komponent på jeres compliance-side bør matche den aktuelle build i produktion, ikke en dev-branch, ikke staging, ikke en produktlinje, I ikke sælger endnu.

Teams overser ofte skrifttyper, ikonpakker, analytics-SDK'er, indlejret JavaScript på marketingsider og transitive afhængigheder, der trækkes med af en enkelt direkte import. Compliance svigter stille, når oversigten er ufuldstændig. Black Ducks OSSRA-rapport fra 2025 viser, at transitive afhængigheder forårsagede næsten 30 % af de licenskonflikter, den fandt, så en tjekliste, der stopper ved direkte importer, overser en stor del af risikoen.

• Hver komponent på siden matcher den build, kunder modtager i dag.
• Transitive npm-, pnpm-, yarn-, Go-, Rust-, Python-, Java-, .NET-, PHP- eller Ruby-afhængigheder er inkluderet i henhold til jeres politik.
• Skrifttyper, ikoner, billeder med licensvilkår og kommercielle SDK'er er ikke sprunget over.
• Container-basislag og bundlede native biblioteker er inden for omfanget, hvis I distribuerer dem.
• Elementer markeret ukendt eller skal gennemgås er afklaret eller udtrykkeligt udelukket med en dokumenteret begrundelse.
• Oversigtens kilde (lockfile, CycloneDX SBOM, manuel post) kan spores til udgivelsen.

Det kræver, at bedømmere kan læse selve licensen, ikke et resumé: Oplysning om tredjepartslicenser betyder fuld licenstekst pr. komponent. Indkøb og jura sammenligner jeres side med forpligtelserne i GPL, LGPL, Apache, MIT og proprietære SDK-aftaler.

Kildeangivelse er adskilt fra notice og adskilt fra fuld licenstekst. En side, der blot lister “MIT” uden MIT-licensteksten eller den påkrævede copyright-notice, er ufuldstændig for de fleste enterprise-gennemgange.

• Hver komponent har en identificeret licens, gennemgået af et menneske, ikke kopieret blindt fra pakkens metadata.
• Fuld licenstekst er til stede på siden eller linket uden loginmur eller URL'er, der udløber.
• Copyleft-komponenter (GPL, AGPL, LGPL osv.) er kommet igennem jeres interne gennemgangs-gates.
• Kildeangivelsens formulering matcher det, hver licens kræver, ikke en generisk “open source-licenser”-footer.
• Dobbeltlicenserede eller specialtilpassede komponenter har en udtrykkelig beslutning registreret.
• Ingen komponent udgives som godkendt, før licenstekst er vedhæftet eller linket.

En licens-compliance-side er en levende registrering. Den URL, indkøb har gemt i deres leverandørfil, bør stadig være korrekt efter jeres næste udgivelse. Compliance bryder sammen, når siden afviger fra det, der leveres.

Publish-gates (gennemgang før udgivelse) forhindrer teams i at påstå compliance, de ikke har verificeret. Eksporter (JSON, attribution-filer, oplysningspakker) bør matche den samme gennemgåede oversigt som den offentlige URL.

• En navngiven ejer godkendte udgivelsen for dette produkt og denne release.
• Compliance-sidens URL er stabil, offentlig og tilgængelig uden godkendelse.
• Eksporter og release-pakker matcher den udgivne oversigt.
• Afvigelsestjek eller pipeline-tjek flager nye pakker før næste kundeaudit.
• I har en dokumenteret proces til at opdatere licenssiden, når afhængigheder ændrer sig.
• I antyder ikke juridisk godkendelse, medmindre en advokat har gennemgået den. Siden er en operationel registrering.

Åbn licens-compliance-siden i et inkognitovindue. Bekræft, at den indlæses, identificér produktet, og stikprøvekontrollér fem tilfældige komponenter mod jeres interne oversigt. Hvis indkøb beder om bevis, er det dette, de vil gøre.

Når tjeklisten er bestået, så send det format, de bad om (URL, eksport eller vedhæftet fil), fra det samme gennemgåede udgivelses-snapshot. Navngiv produktet og den udgivelse eller dato, det afspejler. Filtypen betyder mindre end, om oversigten blev gennemgået og godkendt, før I sendte den.

Nej. En SBOM-tjekliste bekræfter komponentidentitet i et maskinlæsbart format. En licens-compliance-tjekliste bekræfter gennemgåede licenser, fuld tekst, attribution og en udgivelsestilstand, I er villige til at dele. I har ofte brug for begge, i den rækkefølge.

Kør den igen før enhver ekstern deling, og igen når afhængigheder ændrer sig på en overvåget release-branch. Afvigelse mellem den sidst godkendte udgivelse og den aktuelle lockfil er den sædvanlige fejltilstand.

Vælg én ansvarlig ejer pr. produkt, typisk engineering med juridisk gennemgang af højrisikolicenser. Delt ejerskab uden en udgivelsesgate er, hvordan forældede URL'er ender i vendor-filer.