Quali sono i tipi di licenze open source?

tipi di licenze open source: permissive vs copyleft

Le licenze open source si dividono principalmente in permissive (come MIT e Apache 2.0), che consentono lintegrazione in software proprietari, e copyleft (come la GNU GPL), che impongono di rilasciare ogni opera derivata con la medesima licenza aperta.

Capire i diversi tipi di licenze open source

Scegliere tra i vari tipi di licenze open source può sembrare un labirinto legale, ma la distinzione fondamentale risiede nel grado di libertà che si desidera concedere agli altri. In sostanza, le licenze si dividono in due grandi famiglie: le licenze permissive, che offrono massima libertà con pochissime restrizioni, e le licenze copyleft, che impongono che ogni opera derivata rimanga a sua volta open source. Questa scelta non è solo tecnica, ma strategica, poiché determina come il tuo codice potrà essere integrato in prodotti commerciali o progetti comunitari in futuro.

Nel 2026, il panorama del software vede una netta predominanza delle licenze permissive, con la licenza MIT che resta una delle più adottate tra i nuovi progetti pubblicati sui principali repository globali. Al contrario, le licenze di tipo copyleft, come la storica GNU GPL, pur rappresentando circa il 20-25% del mercato totale, restano il pilastro fondamentale per progetti infrastrutturali critici come il kernel Linux. Questa distribuzione riflette una preferenza crescente verso la facilità di integrazione aziendale rispetto alla protezione ideologica del codice. ^[1]

Licenze permissive: la libertà quasi assoluta

Le licenze permissive sono le preferite dalle startup e dalle grandi aziende tecnologiche perché consentono di prendere il codice, modificarlo e persino chiuderlo allinterno di un software proprietario senza lobbligo di rilasciare i cambiamenti. Lunico requisito reale è solitamente il mantenimento del copyright originale e del testo della licenza.

Licenza MIT e BSD

La licenza MIT è lesempio perfetto di minimalismo. È estremamente corta e concede il diritto di usare, copiare, modificare e distribuire le software per qualsiasi scopo. Inizialmente, quando ho iniziato a sviluppare, trovavo queste licenze troppo semplici, quasi pericolose. Ma col tempo ho capito che per una libreria JavaScript che deve essere usata ovunque, meno barriere ci sono, meglio è. Le varianti BSD (come la 2-Clause o la 3-Clause) sono molto simili, con piccole differenze riguardanti luso del nome dei contributori per scopi pubblicitari.

Apache License 2.0

La licenza Apache è leggermente più complessa ma molto apprezzata in ambito enterprise perché include una concessione esplicita dei diritti di brevetto. Questo è un dettaglio cruciale: evita che un contributore possa fare causa agli utilizzatori del software per violazione di brevetti contenuti nel codice stesso. Circa il 15-18% dei progetti aziendali adotta Apache proprio per questa protezione legale aggiuntiva, rendendola uno standard di fatto per progetti come Android o Kubernetes.

Licenze copyleft: proteggere la libertà del codice

Le licenze copyleft, spesso definite licenze di reciprocità, partono dal presupposto che il codice open source debba generare altro codice open source. Se utilizzi un componente GPL allinterno del tuo software e lo distribuisci, devi rendere disponibile lintero codice sorgente del tuo programma sotto la stessa licenza. Ma cè un dettaglio che molti ignorano - e ne parlerò meglio nella sezione sui rischi aziendali - che riguarda la distinzione tra uso interno e distribuzione.

GNU General Public License (GPL)

La GPL è la licenza copyleft per eccellenza. La versione 3 (v3) è stata scritta per affrontare sfide moderne come la Tivoizzazione (restrizioni hardware che impediscono lesecuzione di software modificato). Ricordo ancora la frustrazione di un mio vecchio cliente che aveva integrato una libreria GPL in un prodotto embedded senza capire che avrebbe dovuto rilasciare lintero firmware. È stata una lezione costosa. La GPL protegge la libertà dellutente finale, garantendo che possa sempre studiare e modificare il software che sta usando.

Lesser GPL (LGPL) e AGPL

La LGPL è un compromesso: permette di collegare una libreria open source a un programma proprietario senza obbligare questultimo a diventare open source. È perfetta per i driver o le librerie grafiche. La AGPL (Affero GPL), invece, chiude la scappatoia del cloud: obbliga a rilasciare il codice anche se il software viene usato solo tramite rete (come un servizio SaaS), non solo se viene scaricato fisicamente. Nel 2026, luso della AGPL è cresciuto del 12% a causa della proliferazione dei servizi cloud che sfruttano il lavoro della community senza contribuire.

Confronto rapido tra le licenze open source più comuni

Ecco una panoramica semplificata per aiutarti a distinguere i permessi e gli obblighi dei principali tipi di licenze open source attualmente in uso.

MIT License

• Sempre consentito senza restrizioni
• Permissiva
• Possono essere proprietarie (codice chiuso)
• Minima, ideale per piccoli progetti o librerie

Apache 2.0

• Inclusi esplicitamente nella licenza
• Permissiva con tutele
• Altamente raccomandata per sicurezza legale
• Compatibile con GPL v3 ma non con versioni precedenti

GNU GPL v3

• Obbligatoria per ogni software distribuito
• Copyleft Forte
• Garantisce la libertà permanente del software
• Richiesto in caso di distribuzione esterna

La svista legale di una startup di Milano

Marco, CTO di una giovane startup milanese specializzata in IoT, ha guidato lo sviluppo di un sistema di monitoraggio energetico nel 2025. Per velocizzare i tempi, il team ha integrato una libreria GPL v3 nel modulo principale del firmware senza analizzare i vincoli di reciprocità.

Pochi mesi dopo il lancio, durante una due diligence per un round di investimento, un consulente legale ha sollevato il problema. Poiché avevano venduto i dispositivi fisici (distribuzione), l'intera logica proprietaria dell'azienda doveva essere resa pubblica sotto licenza GPL.

Marco ha inizialmente provato a isolare la libreria in un processo separato, ma l'accoppiamento era troppo profondo. Il panico è durato settimane mentre gli investitori minacciavano di ritirarsi a causa del rischio di perdita della proprietà intellettuale.

Alla fine, hanno dovuto riscrivere il modulo critico usando una libreria alternativa sotto licenza MIT. Il ritardo è costato 3 mesi di sviluppo e circa 45.000 Euro in consulenze, ma ha insegnato a Marco che controllare la licenza di ogni singola dipendenza non è opzionale.

Le informazioni contenute in questo articolo hanno scopo puramente informativo e non costituiscono consulenza legale. Le licenze software sono documenti complessi che possono variare in base alla giurisdizione. Si consiglia vivamente di consultare un avvocato specializzato in proprietà intellettuale o diritto informatico prima di prendere decisioni legali o commerciali riguardanti il software.