Conformità delle licenze open source

Questa pagina contiene informazioni generali, non una consulenza legale. Per le decisioni su un prodotto specifico, si rivolga a un avvocato.

Tipi di licenze open source

Tipo	Esempi	Che cosa richiede di solito
Permissiva	MIT, BSD, Apache-2.0	Conservare gli avvisi di copyright e di licenza. Apache-2.0 contiene anche clausole sui brevetti.
Copyleft debole	LGPL, MPL-2.0	Condividere le modifiche apportate allo stesso componente in licenza
Copyleft forte	GPL-2.0, GPL-3.0	Il software distribuito con il componente deve essere offerto alle stesse condizioni, con il sorgente
Copyleft di rete	AGPL-3.0	Come il copyleft forte, e si applica anche quando gli utenti interagiscono con il software tramite una rete
Source-available	BUSL, SSPL	Non è open source: il sorgente è visibile, ma l'uso è limitato

Che cos'è una licenza copyleft?

Una licenza copyleft Le consente di usare, modificare e condividere il software, a condizione che ciò che distribuisce resti alle stesse condizioni. Mantiene aperto l'open source. Il rischio per un prodotto commerciale è che un componente con copyleft forte collegato al Suo codice può sollevare la questione se anche il Suo codice debba essere rilasciato.

Se ciò si applichi dipende da come viene usato il componente e da come viene fornito il prodotto. Il software che distribuisce ai clienti è più esposto di uno strumento interno, e un prodotto SaaS di solito evita le condizioni di distribuzione della GPL ma non quelle dell'AGPL.

Rischi comuni per la conformità

• Licenze transitive. Un pacchetto con licenza permissiva può dipendere da uno con licenza copyleft. Controllare solo le dipendenze dirette non lo rileva.
• Avvisi mancanti. La maggior parte delle licenze chiede di conservare l'attribuzione, e un file di avvisi dimenticato è l'errore più comune.
• Licenze cambiate. Un progetto può cambiare licenza in una nuova versione, quindi un aggiornamento può cambiare le Sue condizioni.
• Dichiarata o effettiva. I metadati di un pacchetto possono essere errati o incompleti, e il codice incluso direttamente nel repository può avere una licenza propria.
• Due diligence. Acquirenti e grandi clienti chiedono un inventario delle licenze, di solito con poco preavviso.

Come restare conformi

1. Scriva una policy. Decida quali licenze sono consentite, quali richiedono una revisione e quali sono vietate, in base al tipo di prodotto.
2. Crei un inventario. Una SBOM elenca ogni componente con la sua licenza, comprese le dipendenze transitive.
3. Controlli automaticamente. Applichi la policy in CI, così che una nuova dipendenza venga bloccata nel momento in cui viene aggiunta e non durante un audit.
4. Adempia agli obblighi. Generi i file di avvisi e fornisca il sorgente dove una licenza lo richiede.
5. Conservi i registri. Archivi l'inventario per ogni release, perché di solito la domanda riguarda una versione già distribuita.

Che cosa fanno gli strumenti per la conformità delle licenze

La conformità delle licenze è una parte standard della software composition analysis. Gli strumenti identificano i componenti, ne riportano le licenze e segnalano le violazioni della Sua policy. Si differenziano per profondità:

• Licenze dichiarate: la maggior parte degli strumenti legge ciò che ogni pacchetto dichiara nei propri metadati. È veloce e copre il caso più comune.
• Scansione approfondita delle licenze: FOSSA e Black Duck analizzano anche il testo delle licenze nel codice e aiutano con i report di attribuzione e la revisione legale. Veda CRACI vs FOSSA e CRACI vs Black Duck.
• Strumenti gratuiti: molti generatori di SBOM e scanner SCA riportano gratuitamente le licenze dichiarate. Veda i migliori strumenti SCA.

Dove si colloca CRACI

CRACI gestisce le licenze dichiarate nella build. Come Suo runner GitHub Actions, registra ogni pacchetto scaricato da un job, e ciascuno riporta la propria licenza dichiarata, così le licenze copyleft vengono individuate prima di finire nel prodotto. Le regole delle policy sulle licenze possono bloccare una build in base a una licenza, e gli export SBOM in CycloneDX e SPDX includono la licenza dichiarata di ogni componente. CRACI si basa su ciò che i pacchetti dichiarano, quindi se Le servono workflow di revisione legale o l'analisi del testo delle licenze, usi uno strumento specializzato accanto a CRACI.

Conformità delle licenze open source: domande frequenti

Che cos'è la conformità delle licenze open source?

Significa sapere quali licenze open source si applicano al software che usa e rispettarne le condizioni, come conservare gli avvisi o condividere il codice sorgente.

Che cos'è una licenza copyleft?

Una licenza che consente di usare e modificare il software a condizione che ciò che si distribuisce resti alle stesse condizioni. La GPL è l'esempio più noto.

Si può usare codice GPL in un software commerciale?

Sì, ma se distribuisce un software che lo include, può dover offrire il sorgente di quel software sotto la GPL. Conta il modo in cui il codice viene combinato, quindi per il Suo caso chieda una consulenza legale.

Il copyleft si applica al SaaS?

Le condizioni della GPL scattano in genere con la distribuzione, che il SaaS di solito evita. L'AGPL colma questa lacuna estendendo le condizioni agli utenti che interagiscono con il software tramite una rete.

Qual è la licenza open source più sicura per l'uso commerciale?

Le licenze permissive come MIT, BSD e Apache-2.0 sono quelle che chiedono meno. Deve comunque conservarne gli avvisi.

Come si controllano le licenze delle proprie dipendenze?

Generi una SBOM che includa le dipendenze transitive e le licenze dichiarate, oppure usi uno strumento SCA. Applichi la Sua policy in CI, così che le nuove violazioni facciano fallire la build.