Så granskar du en tredjepartsförteckning före publicering

Eftersom import bara talar om vad som finns där, inte om licensmetadatan går att lita på: Paketregister felmärker licenser, leverantörer ändrar villkor, och transitiva beroenden introducerar copyleft du inte förväntade dig. En tredjepartsförteckning är underlag, inte en färdig licenssida.

Omfattningen är dokumenterad, och det är precis den typen av fall automatiserad import inte kan lösa på egen hand.

Granskningsgrindar finns så att du inte kan publicera en licens-URL som överdriver vad ditt team har verifierat. Inköp och revisorer betraktar den offentliga sidan som din utfästelse om tredjepartslicensskyldigheter.

Börja med artefakter kopplade till bygget du levererar: package-lock.json, pnpm-lock.yaml, yarn.lock, go.mod, Cargo.lock, pom.xml, Gemfile.lock, en CycloneDX SBOM från CI, eller exporter från ditt befintliga SBOM-verktyg. Markera varje rad som “väntar på granskning” tills någon bekräftar licensen.

Avgränsa importen till en produkt. Företag med flera produkter behöver separata licenssidor, eller tydligt separerade avsnitt, per levererad produkt. Att blanda förteckningar skapar redovisningsfel.

• Importera lockfiles eller SBOM:er från release-branchen, inte main om den avviker.
• Inkludera typsnitt, ikoner, SDK:er och inbäddade tillgångar din policy kräver.
• Flagga dubbletter och slå samman poster som avser samma komponent.
• Registrera importdatum och källfilens hash för granskningsspår.
• Publicera inte automatiskt. Varje post börjar oreviderad.

För varje rad, bekräfta att licensidentifieraren matchar den faktiska användningen, inte bara metadata i package.json. Läs copyleft-utlösande villkor. Bifoga fullständig licenstext. Dokumentera undantag uttryckligen.

Granskare fokuserar på GPL, LGPL, AGPL, proprietära SDK:er och komponenter med saknad eller motstridig licensdata. De raderna blockerar publicering tills de är lösta.

• Matcha licensen mot källan: Repots LICENSE-fil, leverantörsavtal, eller SPDX-identifierare bekräftad av en människa.
• Lägg till fullständig licenstext i redovisningen innan du markerar godkänd.
• Flagga copyleft, nätverkscopyleft (AGPL) och egna licenser för granskning av juridik eller senior utvecklare.
• Lös konflikter (registret säger MIT, repot säger Apache) innan godkännande.
• Dokumentera komponenter som undantagits från den levererade produkten, och varför.
• Kräv en andra godkännare för högriskslicenser om din policy definierar en sådan.

Publicera bara när grindarna passeras: Inga oreviderade rader, fullständig licenstext bifogad, tydligt produktomfång, stabil URL. Den offentliga licenssidan är samma data som dina exporter. En granskad förteckning, flera utdata.

Sidor för redovisning av tredjepartslicenser ska laddas utan autentisering, lista komponenter tydligt, och innehålla fullständig licenstext som inköp kan söka i och kopiera. Det är vad enterprise-granskningar letar efter.

• Blockera publicering om någon komponent inom omfånget saknar godkänd licenstext.
• Generera den offentliga URL:en och verifiera i inkognitoläge innan du delar den externt.
• Exportera JSON-, attribuerings- och redovisningspaket från samma godkända ögonblicksbild.
• Registrera vem som godkände publiceringen och vilken releasetagg den matchar.

Licensefterlevnad är inte en engångsinsats. Nya beroenden, versionsuppdateringar och licensändringar dyker upp varje sprint. Avvikelsekontroller jämför aktuella lockfiles eller SBOM:er med din senast godkända publicering och flaggar skillnader innan kunderna märker det.

När förteckningen ändras, kör granskningsgrindarna igen. Uppdatera licenssidan. Skicka uppdaterade URL:er till inköp först när den nya publiceringen är godkänd, inte när importen är klar.

• Kör pipeline- eller CI-kontroller vid pull request, tagg eller release.
• Flagga nya oreviderade paket före release, enligt din policy.
• Godkänn copyleft-komponenter på nytt när länknings- eller distributionsmodellen ändras.
• Håll ett granskningsspår: Import, granskning, publicering, avvikelsehändelser.