Ogni volta che mi trovo a creare un progetto pubblico su Github, cercando sempre di fornire una descrizione quanto più completa e professionale possibile del mio codice, mi trovo di fronte alla scelta di una licenza da piazzare lì, in bella vista, prima di ignorarla per sempre. Data la mia poca esperienza in materia e il mio generale disinteresse per le questioni legali, soprattutto quando legate a qualcosa che, dal mio punto di vista, dovrebbe essere prima di tutto un modo per condividere ciò che si ritiene possa essere un modo per migliorare, magari in modo impercettibile, la propria esperienza e quella di altri, mi sono sempre affidato a quelle più popolari, senza mai approfondire troppo la questione. Di conseguenza, la maggior parte dei miei progetti su Github sono sotto licenza MIT. Tuttavia, trovandomi ad avere a che fare sempre più spesso con software proprietario, dove l’ottenimento di una licenza è un processo estremamente lungo, farraginoso, noioso e costoso, e trovandomi anche a dover rendere pubblico del codice che dipende da librerie con licenze più restrittive, ho deciso di approfondire un po’ la questione, per capire meglio come funziona questo male necessario.
La fonti principali di questo post, indicate per chi voglia approfondire, sono il sito Choose a License e l’articolo You Clicked “Add a License” on GitHub…But Do You Know What You Picked?.
A cosa serve una licenza software?
In soldoni, una licenza software è un documento legale che stabilisce, nero su bianco, i termini di utilizzo di un software. Diventa ancora più importante quando il codice sorgente è pubblico, perché la licenza chiarisce anche
- Cosa è permesso fare con il codice,
- Cosa non è permesso fare con il codice.
- Eventuali limitazioni o condizioni da rispettare quando si utilizza, modifica o distribuisce il software.
Le licenze più popolari
La maggior parte dei progetti open‑source su Github utilizza una di queste licenze, con minime variazioni.
Nessuna licenza = nessun permesso
Si guarda ma non si tocca.
Se un progetto su Github non ha una licenza, significa che, legalmente, nessuno ha il permesso di utilizzare, modificare o distribuire quel codice. In pratica, è come se il codice fosse “tutto riservato”, e chiunque voglia usarlo, modificarlo o condividerlo dovrebbe prima ottenere un permesso esplicito dall’autore, il che potrebbe scoraggiante chi ha intenzione di contribuire o utilizzare quel codice, ovviamente ammesso che sia al corrente delle regole del gioco.
MIT License
Puoi fare quello che vuoi a tuo rischio e pericolo, basta che mi citi.
Con la licenza MIT, chiunque può utilizzare, modificare e distribuire il codice, anche per scopi commerciali, a patto di includere una copia della licenza e di attribuire l’autore originale. È una delle licenze più permissive e popolari, ideale per progetti che vogliono massimizzare la diffusione e l’adozione del proprio codice.
Indicata per
- Progetti personali
- Progetti accademici
- Librerie completamente open‑source
Apache License 2.0
Puoi fare quello che vuoi, ma se usi il mio codice, devi darmi credito e sono protetto da eventuali cause legali legate a brevetti.
Molto simile alla MIT, ma con alcune clausole aggiuntive che proteggono l’autore da eventuali cause legate ai brevetti. È una buona scelta per progetti che vogliono offrire una licenza permissiva ma con una maggiore protezione legale, soprattutto in ambito aziendale.
Indicata per
- Progetti commerciali
- Frameworks
- Progetti open-source a lungo termine
Usata da
- Android
- Kubernetes
- Progetti Apache
GPL (GNU General Public License)
Puoi usare il mio codice, ma se lo modifichi o lo distribuisci, devi rilasciare il tuo codice sotto la stessa licenza.
Si tratta di una licenza copyleft, che richiede che qualsiasi software derivato dal codice originale sia rilasciato sotto la stessa licenza GPL. Si comporta quindi un po’ come un “virus” che si propaga in qualsiasi progetto che utilizzi codice protetto da questa licenza. È una scelta popolare per progetti che vogliono garantire che il loro codice rimanga sempre open‑source, ma può essere limitante per chi vuole utilizzare il codice in progetti proprietari o con licenze più permissive, impedendo di fatto l’inclusione del codice GPL in progetti che non vogliono rilasciare il proprio codice sotto GPL.
Indicata per
- Progetti educativi
- Software guidato dalla comunità
- Progetti che si vogliono sempre mantenere open‑source
LGPL (Lesser GPL)
Puoi usare la mia libreria, ma se modifichi la libreria stessa, devi rilasciare le modifiche sotto la stessa licenza.
La LGPL è una versione più permissiva della GPL, che consente di utilizzare la libreria in progetti proprietari, a patto che eventuali modifiche alla libreria stessa siano rilasciate sotto la stessa licenza.
Indicata per
- Librerie
- SDKs
BSD License
Simile alla MIT, ma più formale.
La BSD è una licenza permissiva che consente l’uso, la modifica e la distribuzione del codice, con alcune restrizioni minori rispetto alla MIT. È stata una delle prime licenze open‑source e, sebbene sia meno comune oggi, è ancora rispettata e utilizzata in alcuni progetti accademici e di ricerca.
Indicata per
- Progetti accademici
- Software di ricerca
Schema riassuntivo
| Licenza | Uso commerciale? | Attribuzione? | Copyleft? | Indicata per |
|---|---|---|---|---|
| MIT | ✓ | ✓ | X | Progetti personali, accademici, librerie open‑source |
| Apache 2.0 | ✓ | ✓ | X | Progetti commerciali, frameworks, |
| GPL | ✓ | ✓ | ✓ | Progetti che si vogliono mantenere open‑source |
| LGPL | ✓ | ✓ | ⚠ (per la libreria) | Librerie, SDKs |
| BSD | ✓ | ✓ | X | Progetti accademici, software di ricerca |
Alcuni progetti famosi
- Apache richiede Apache License 2.0
- Cloud Native Computing Foundation richiede Apache License 2.0
- GNU raccomanda GNU GPLv3
- npm packages spesso usano MIT o ISC, che è molto simile
- OpenBSD tende a preferire la ISC
- Rust crates sono spesso sotto MIT o Apache License 2.0
- WordPress plugin e temi devono essere rilasciati sotto GNU GPLv2 o superiore.
- Joomla extensions e templates devono essere rilasciati sotto GNU GPLv2 per il codice PHP.