Quando si parla di software libero, la prima grande divisione tra le licenze non riguarda il prezzo né la qualità del codice, ma una domanda precisa: chi riceve il software, e poi lo modifica e lo ridistribuisce, deve concedere agli altri le stesse libertà che ha ricevuto? Le licenze che rispondono «no, non è obbligatorio» si chiamano permissive; quelle che rispondono «sì» si chiamano copyleft. Capire questa differenza evita la maggior parte degli errori che vedo nei progetti, sia in chi scrive codice sia in chi lo integra in un prodotto.
Cosa hanno in comune
Entrambe le famiglie sono licenze open source a tutti gli effetti. Tutte permettono di:
- usare il programma per qualsiasi scopo, anche commerciale;
- studiarne il codice sorgente;
- modificarlo;
- ridistribuirlo, nella versione originale o modificata.
La differenza emerge solo nel momento della distribuzione: finché si usa il software internamente, senza consegnarlo a terzi, le due famiglie si comportano in modo molto simile (con l'eccezione dell'AGPL, che estende gli obblighi all'uso in rete).
Le licenze permissive
Le licenze permissive chiedono poco: in genere conservare l'avviso di copyright e il testo della licenza, e accettare l'esclusione di garanzia. Le più diffuse sono:
| Licenza | Obblighi principali | Nota distintiva |
|---|---|---|
| MIT | mantenere copyright e testo della licenza | brevissima, molto popolare |
| BSD 2-Clause | come la MIT | formulazione diversa, stessa sostanza |
| BSD 3-Clause | come la 2-Clause | vieta di usare il nome degli autori per promuovere derivati |
| Apache 2.0 | copyright, licenza, file NOTICE, indicare le modifiche | concessione esplicita di brevetti |
Con una licenza permissiva un'azienda può prendere una libreria, modificarla e incorporarla in un prodotto proprietario chiuso, senza pubblicare le proprie modifiche. Molti autori lo considerano un vantaggio: la libreria si diffonde di più e diventa uno standard di fatto.
Un esempio concreto
Una software house sviluppa un'app per la gestione di magazzino e include una libreria di parsing CSV con licenza MIT. Può vendere l'app senza rilasciare il proprio codice. Deve però includere, ad esempio in una schermata «Informazioni» o in un file allegato, l'avviso di copyright e il testo della licenza MIT della libreria. Dimenticare questo passaggio è la violazione più frequente, ed è anche la più facile da evitare.
Le licenze copyleft
Il copyleft usa il diritto d'autore per garantire che il software resti libero anche nelle versioni derivate. Chi distribuisce un'opera derivata deve farlo con la stessa licenza e mettere a disposizione il codice sorgente corrispondente.
Esistono gradi diversi di copyleft:
- Copyleft forte (GPL): l'obbligo si estende all'intero programma derivato, comprese le parti che vi sono combinate in modo stretto.
- Copyleft debole (LGPL, MPL): l'obbligo riguarda la libreria o i singoli file con licenza copyleft, non necessariamente il programma che li usa.
- Copyleft di rete (AGPL): l'obbligo scatta anche quando il software modificato viene offerto agli utenti attraverso una rete, senza distribuirlo.
Lo stesso esempio, con la GPL
Se la libreria CSV fosse sotto GPL e venisse incorporata nell'app di magazzino distribuita ai clienti, l'intera app diventerebbe un'opera derivata soggetta alla GPL. La software house dovrebbe fornire ai clienti il codice sorgente completo e permettere loro di modificarlo e ridistribuirlo. Non è un divieto di vendere: la GPL consente di far pagare il software. Ma il modello di business basato sulla segretezza del codice non è più praticabile.
Perché scegliere l'una o l'altra
Le motivazioni sono più filosofiche e strategiche che tecniche.
A favore del permissivo:
- massima adozione, anche da parte di aziende che non vogliono obblighi;
- semplicità di conformità;
- adatto a standard, librerie di base, esempi e piccoli strumenti.
A favore del copyleft:
- garantisce che i miglioramenti tornino alla comunità quando il software viene distribuito;
- impedisce che un concorrente chiuda il progetto in un prodotto proprietario;
- protegge gli utenti finali, che ricevono sempre il codice sorgente.
Un criterio pratico che uso spesso: se il valore del progetto sta nella sua diffusione come mattone per altri, una licenza permissiva funziona bene. Se il valore sta nel prodotto finito e si teme che qualcuno ne faccia una versione chiusa, il copyleft è più coerente.
Errori comuni da evitare
- Pensare che «open source» significhi «senza regole». Anche la MIT ha obblighi, per quanto minimi.
- Confondere uso e distribuzione. Molti obblighi della GPL scattano solo distribuendo; usare internamente un programma GPL non obbliga a pubblicare nulla.
- Mescolare codice senza verificare la compatibilità. Codice MIT può confluire in un progetto GPL, ma il contrario non è possibile mantenendo la licenza MIT sull'insieme.
- Copiare frammenti da progetti senza guardare la licenza. Anche poche righe possono essere protette.
- Credere che il codice senza licenza sia libero. In assenza di licenza valgono le regole ordinarie del diritto d'autore: nessuno può legittimamente riutilizzarlo.
Come verificare in pratica
Per ogni dipendenza di un progetto conviene annotare nome, versione, licenza e obblighi richiesti. Gli strumenti di analisi delle dipendenze aiutano, ma il controllo finale va fatto leggendo il file di licenza del progetto, perché i metadati dei gestori di pacchetti a volte sono incompleti o errati.
In sintesi
- Permissive e copyleft sono entrambe licenze open source: la differenza riguarda gli obblighi quando si distribuiscono versioni derivate.
- Le permissive (MIT, BSD, Apache) chiedono soprattutto di conservare copyright e testo della licenza.
- Le copyleft (GPL, LGPL, MPL, AGPL) richiedono di mantenere la stessa licenza e fornire il sorgente, con ampiezza variabile.
- La scelta dipende dalla strategia: diffusione massima oppure garanzia che le derivate restino libere.
- Il codice senza licenza non è libero: senza un permesso esplicito non si può riutilizzare.
