Checklist di conformità delle licenze: cosa verificare prima di condividere la prova

Una pagina solida identifica il prodotto rilasciato, elenca i componenti di terze parti con licenze riviste, include il testo completo delle licenze o link affidabili, e mostra l'attribuzione dove le licenze la richiedono. Gli acquisti e i revisori si aspettano più di un semplice elenco di pacchetti npm.

Se la tua pagina dice solo "usiamo open source" senza inventario, testo delle licenze o un ambito chiaro, non soddisferà una richiesta di divulgazione delle licenze di terze parti. Questo vale anche se l'ingegneria ha superato una revisione di sicurezza interna.

L'esigenza è diffusa: l'Open Source Security and Risk Analysis 2025 di Black Duck ha rilevato che il 97% delle codebase controllate conteneva open source, quindi quasi ogni prodotto porta con sé obblighi di terze parti, che siano documentati o meno.

• Nome e versione del prodotto (o canale di release) coperti dalla pagina.
• Inventario dei componenti di terze parti e open source, diretti e transitivi dove il tuo processo lo richiede.
• Identificatori di licenza in stile SPDX o equivalenti, dopo la revisione umana, non solo ipotesi del registro.
• Testo completo della licenza per ogni componente, o link stabili che portano al testo completo.
• Blocchi di attribuzione e avviso dove le licenze MIT, Apache, BSD, GPL o personalizzate li richiedono.
• Etichettatura chiara se la pagina è di esempio, beta o di produzione, dove pertinente.

La conformità delle licenze inizia con l'inventario: ogni componente nella tua pagina di conformità dovrebbe corrispondere alla build attualmente rilasciata, non a un branch di sviluppo, non allo staging, non a una linea di prodotto che non stai ancora vendendo.

I team spesso perdono di vista font, pacchetti di icone, SDK di analitici, JavaScript incorporato nei siti marketing e dipendenze transitive introdotte da una singola importazione diretta. La conformità fallisce silenziosamente quando l'inventario è incompleto. L'OSSRA 2025 di Black Duck riporta che le dipendenze transitive hanno causato quasi il 30% dei conflitti di licenza rilevati, quindi una checklist che si ferma alle importazioni dirette perde una grande parte del rischio.

• Ogni componente nella pagina corrisponde alla build che i clienti ricevono oggi.
• Le dipendenze transitive npm, pnpm, yarn, Go, Rust, Python, Java, .NET, PHP o Ruby sono incluse secondo la tua policy.
• Font, icone, immagini con condizioni di licenza e SDK commerciali non vengono saltati.
• I layer di base dei container e le librerie native incluse sono in ambito se le distribuisci.
• Le voci contrassegnate come sconosciute o da rivedere sono risolte oppure escluse esplicitamente con una motivazione documentata.
• La fonte dell'inventario (lockfile, SBOM CycloneDX, voce manuale) è tracciabile fino alla release.

Richiede che i revisori possano leggere la licenza reale, non un riassunto: la divulgazione delle licenze di terze parti significa testo completo della licenza per ogni componente. Acquisti e legale confrontano la tua pagina con gli obblighi previsti da GPL, LGPL, Apache, MIT e accordi SDK proprietari.

L'attribuzione è separata dall'avviso ed è separata dal testo completo della licenza. Una pagina che elenca "MIT" senza il testo della licenza MIT o l'avviso di copyright richiesto è incompleta per la maggior parte delle revisioni enterprise.

• Ogni componente ha una licenza identificata, rivista da un essere umano, non copiata ciecamente dai metadati del pacchetto.
• Il testo completo della licenza è presente nella pagina o collegato senza barriere di accesso o URL in scadenza.
• I componenti copyleft (GPL, AGPL, LGPL, ecc.) hanno superato le tue barriere di revisione interne.
• La formulazione dell'attribuzione corrisponde a quanto richiesto da ciascuna licenza, non un footer generico "licenze open source".
• I componenti a doppia licenza o personalizzati hanno una decisione esplicita registrata.
• Nessun componente viene pubblicato come approvato finché il testo della licenza non è allegato o collegato.

Una pagina di conformità delle licenze è un registro vivo. L'URL che gli acquisti hanno salvato nel loro fascicolo fornitori dovrebbe essere ancora accurato dopo la tua prossima release. La conformità si rompe quando la pagina diverge da quello che viene rilasciato.

Le barriere di pubblicazione (revisione prima della pubblicazione) impediscono ai team di dichiarare una conformità che non hanno verificato. Le esportazioni (JSON, file di attribuzione, pacchetti di divulgazione) dovrebbero corrispondere allo stesso inventario rivisto dell'URL pubblico.

• Un responsabile nominato ha approvato la pubblicazione per questo prodotto e questa release.
• L'URL della pagina di conformità è stabile, pubblico e raggiungibile senza autenticazione.
• Le esportazioni e i pacchetti di release corrispondono all'inventario pubblicato.
• I controlli di deriva o della pipeline segnalano i nuovi pacchetti prima del prossimo audit del cliente.
• Hai un processo documentato per aggiornare la pagina delle licenze quando le dipendenze cambiano.
• Non lasci intendere un'approvazione legale a meno che un legale non abbia rivisto. La pagina è un registro operativo.

Apri la pagina di conformità delle licenze in una finestra in incognito. Conferma che si carichi, identifica il prodotto, e controlla a campione cinque componenti casuali rispetto al tuo inventario interno. Se gli acquisti chiedono una prova, è esattamente questo che faranno.

Quando la checklist è superata, invia qualsiasi formato ti abbiano chiesto (URL, esportazione o allegato) dalla stessa istantanea di pubblicazione rivista. Indica il prodotto e la release o la data a cui si riferisce. Il tipo di file conta meno del fatto che l'inventario sia stato rivisto e approvato prima di inviarlo.

No. Una checklist SBOM conferma l'identità dei componenti in un formato machine-readable. Una checklist di conformità delle licenze conferma licenze revisionate, testo completo, attribuzione e uno stato di pubblicazione che siete disposti a condividere. Spesso servono entrambe, in quell'ordine.

Rieseguila prima di qualsiasi condivisione esterna, e di nuovo quando le dipendenze cambiano su un branch di release monitorato. Il drift tra l'ultima pubblicazione approvata e il lockfile attuale è la modalità di errore abituale.

Scegliete un owner responsabile per prodotto, di solito engineering con revisione legale sulle licenze ad alto rischio. Ownership condivisa senza un gate di pubblicazione è il modo in cui URL obsoleti finiscono nei file dei vendor.