Sådan gennemgår I pakker fra tredjeparter 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.

Kontroltrinnene findes, så I ikke kan udgive en URL om licensoverholdelse, der påstår mere, end 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 licenssider eller tydeligt adskilte afsnit for hvert 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 ledende udviklere.
• 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 kontroltrinnene er bestået: Ingen ikke-gennemgåede rækker, fuld licenstekst vedhæftet, klart produktomfang og en stabil URL. Den offentlige licensside bygger på de samme data som jeres eksporter. Én gennemgået oversigt, flere resultater.

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.

Licensoverholdelse er ikke noget, man gør én gang for alle. Nye afhængigheder, versionsopdateringer og licensændringer kommer hver sprint. Afvigelsestjek sammenligner aktuelle lockfiler eller SBOM'er med jeres senest godkendte udgivelse og markerer forskelle, før kunderne bemærker dem.

Når oversigten ændrer sig, skal I gennemgå kontroltrinnene igen. Opdatér licenssiden. Send først opdaterede URL'er til indkøb, 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.