Vai al contenuto principale

Risorse

La guida in linguaggio semplice alla conformità delle licenze di terze parti

Cosa richiedono davvero le licenze open source, come le regole si manifestano nei prodotti reali e come produrre un registro difendibile. Scritto per chi deve rispondere alla due diligence sotto scadenza, non per avvocati.

Inizia da qui

“Open source” non è un permesso di rilascio. È un contratto.

Ogni libreria, font, icona e SDK che includi arriva con delle condizioni: avviso, attribuzione, talvolta copyleft. Sono standardizzate, pubbliche ed esigibili, spesso senza che nessuno del team le abbia lette. Ecco le tre supposizioni che costano di più ai team.

“È open source, possiamo rilasciarlo.”

Le licenze permissive richiedono comunque avvisi di copyright e di licenza nelle distribuzioni. Il copyleft può richiedere offerte di codice sorgente. Mai una nota a piè di pagina su un wiki.

“Siamo SaaS, le licenze non si applicano.”

Alcuni obblighi sono più leggeri per l'uso solo in rete; molti non lo sono. Font, installer e asset inclusi comportano comunque obblighi, e gli acquirenti continuano a chiedere.

“npm update è solo una patch.”

Un aggiornamento di versione può cambiare la licenza effettiva o aggiungere copyleft. Gli aggiornamenti di routine sono il modo più comune in cui la conformità si rompe senza essere notata.

Stai studiando perché qualcuno ti ha chiesto una prova?

Salta la corsa contro il tempo. Importa il tuo inventario e scopri a che punto sei, gratis, in pochi minuti.

Cookie su sourcetrust.dev

Utilizziamo cookie essenziali per la sicurezza (ad esempio per prevenire abusi nella scansione del sito e nel modulo di richiesta della demo). Con il tuo consenso, utilizziamo anche analitiche e diagnostica opzionali (Google Tag Manager su questo sito e l'SDK browser di Sentry nell'applicazione SourceTrust quando configurato). Consulta la nostra cookie policy.