Vai al contenuto principale

Idee sbagliate

Cosa danno per scontato i team rispetto a cosa richiedono le licenze

L'open source viene spesso trattato come un via libera al rilascio. In pratica, ogni libreria, font, SDK o script che includi è una licenza, con regole di avviso, attribuzione o copyleft che variano da componente a componente.

Le schede qui sotto affiancano le supposizioni più comuni a ciò che quelle licenze richiedono davvero, prima che un cliente, un revisore o un acquirente lo chieda.

Ultimo aggiornamento: 2 luglio 2026

Open source non significa nessun obbligo legale.

Significa che gli obblighi sono standardizzati, pubblici ed esigibili, spesso senza che nessuno del team li abbia letti.

  • Supposizione

    “È open source. Possiamo rilasciarlo.”

    Realtà

    Ogni componente arriva con delle condizioni. Le licenze permissive richiedono comunque avvisi di copyright e di licenza nelle distribuzioni. Le licenze copyleft possono richiedere offerte di codice sorgente, propagazione della licenza e analisi della distribuzione. Non una nota a piè di pagina su un wiki.

  • Supposizione

    “Siamo SaaS, quindi le licenze non si applicano.”

    Realtà

    Alcuni obblighi sono più leggeri per l'uso solo in rete; molti non lo sono. GPL, LGPL, l'attribuzione Apache negli installer, la ridistribuzione dei font e l'attribuzione degli asset contano comunque. E i clienti continuano a chiedere cosa rilasci e cosa includi.

  • Supposizione

    “Se è importante, se ne occuperà il legale.”

    Realtà

    Il legale non può mettere in pratica quello che l'ingegneria non ha mai inventariato. Gli elenchi dei pacchetti cambiano a ogni sprint; font, icone e SDK spesso non vi compaiono mai. Quando i legali vengono coinvolti, la release è già uscita.

  • Supposizione

    “Abbiamo un file LICENSE nel repository.”

    Realtà

    La licenza del tuo repository è la tua. Non quella delle tue dipendenze. Un unico file di attribuzione di tre anni fa non descrive quello che i clienti scaricano oggi.

  • Supposizione

    “npm update è solo una patch, la conformità resta la stessa.”

    Realtà

    Un aggiornamento di versione può cambiare la licenza effettiva, aggiungere copyleft o sostituire completamente gli obblighi. Gli aggiornamenti di routine sono uno dei modi più comuni in cui la conformità si rompe senza che nessuno se ne accorga.

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.