Sådan gennemgår I en tredjepartsoversigt før udgivelse

Fordi import kun fortæller jer, hvad der er der, ikke om licensmetadataene er pålidelige: Pakkeregistre fejlmærker licenser, leverandører ændrer vilkår, og transitive afhængigheder introducerer copyleft, I ikke forventede. En tredjeparts-oversigtsfil er input, ikke en færdig compliance-side.

Omfanget er dokumenteret, og det er præcis den type sager, automatisk import ikke kan løse på egen hånd.

Gennemgangs-gates findes, så I ikke kan udgive en licens-compliance-URL, der overdriver, hvad jeres team har verificeret. Indkøb og revisorer betragter den offentlige side som jeres udsagn om tredjepartslicensforpligtelser.

Start fra artefakter knyttet til den build, I sender i produktion: package-lock.json, pnpm-lock.yaml, yarn.lock, go.mod, Cargo.lock, pom.xml, Gemfile.lock, en CycloneDX SBOM fra CI, eller eksporter fra jeres eksisterende SBOM-værktøj. Markér hver række skal gennemgås, indtil nogen bekræfter licensen.

Afgræns importen til ét produkt. Virksomheder med flere produkter har brug for separate licens-compliance-sider, eller tydeligt adskilte afsnit, pr. produkt i produktion. At blande oversigter skaber fejl i oplysningen.

• Importér lockfiles eller SBOM'er fra release-branchen, ikke main, hvis den afviger.
• Inkludér skrifttyper, ikoner, SDK'er og indlejrede assets, som jeres politik kræver.
• Flag dubletter, og flet poster, der refererer til den samme komponent.
• Registrér importdato og kildefilens hash til revisionssporet.
• Udgiv ikke automatisk. Hver post starter ikke-gennemgået.

For hver linje, bekræft at licens-id'et matcher den faktiske brug, ikke kun package.json-metadata. Læs copyleft-udløsere. Vedhæft fuld licenstekst. Dokumentér udelukkelser udtrykkeligt.

Bedømmere fokuserer på GPL, LGPL, AGPL, proprietære SDK'er og komponenter med manglende eller modstridende licensdata. Disse rækker spærrer udgivelse, indtil de er afklaret.

• Match licensen til kilden: Repoets LICENSE-fil, leverandøraftale eller SPDX-id bekræftet af et menneske.
• Tilføj fuld licenstekst til registreringen, før den markeres godkendt.
• Flag copyleft, netværks-copyleft (AGPL) og specialtilpassede licenser til gennemgang hos jura eller senior engineering.
• Afklar konflikter (registret siger MIT, repoet siger Apache), før godkendelse.
• Dokumentér komponenter, der er udelukket fra produktet i produktion, og hvorfor.
• Kræv en anden godkender til højrisikolicenser, hvis jeres politik definerer én.

Udgiv kun, når gates er bestået: Ingen ikke-gennemgåede rækker, fuld licenstekst vedhæftet, produktomfang klart, URL stabil. Den offentlige licens-compliance-side er de samme data som jeres eksporter. Én gennemgået oversigt, flere output.

Sider med oplysning om tredjepartslicenser bør indlæses uden godkendelse, liste komponenter tydeligt og inkludere fuld licenstekst, som indkøb kan søge i og kopiere. Det er, hvad enterprise-gennemgange kigger efter.

• Spær udgivelse, hvis en omfattet komponent mangler godkendt licenstekst.
• Generér den offentlige URL, og verificér i inkognitotilstand, før I deler den eksternt.
• Eksportér JSON-, attribution- og oplysningspakker fra det samme godkendte snapshot.
• Registrér, hvem der godkendte udgivelsen, og hvilken release-tag den matcher.

Licens-compliance er ikke noget, man gør én gang for alle. Nye afhængigheder, versionsopdateringer og licensændringer kommer hver sprint. Afvigelsestjek sammenligner aktuelle lockfiles eller SBOM'er med jeres sidst godkendte udgivelse og flager forskelle, før kunder bemærker det.

Når oversigten ændrer sig, så kør gennemgangs-gates igen. Opdatér licens-compliance-siden. Send opdaterede URL'er til indkøb først, når den nye udgivelse er godkendt, ikke når importen er færdig.

• Kør pipeline- eller CI-tjek ved pull request, tag eller release.
• Flag nye, ikke-gennemgåede pakker før udgivelse, i henhold til jeres politik.
• Godkend copyleft-komponenter igen, når linking- eller distributionsmodellen ændrer sig.
• Bevar revisionsspor: Import-, gennemgangs-, udgivelses- og afvigelseshændelser.