La compatibilità tra le licenze e il re-licenziamento

di Richard Stallman

Qualora si vogliano combinare due programmi liberi in uno unico oppure inserire il codice di uno all'interno dell'altro, è necessario valutare se le licenze dei due programmi lo permettono.

Non vi è alcun problema ad unire programmi protetti dalla medesima licenza se la licenza è stata ben studiata e la maggior parte delle licenze libere lo è. (*)

Che fare allora quando le licenze differiscono tra loro? In generale, si definiscono compatibili due o più licenze quando permettono di unire il codice rilasciato sotto le varie licenze rimanendo al contempo conformi a tutte loro. Spesso ne risulta un programma con diverse parti protette da varie licenze compatibili—ma non è sempre così. Una tale capacità di combinazione delle licenze deriva infatti dalle caratteristiche delle licenze stesse e non dipende dall'ordine in cui vengono menzionate. La particolare combinazione di licenze determina inoltre qual è la licenza necessaria per il programma derivato.

Dividiamo le licenze in tre classi: deboli (dette anche “permissive” o “semplici”), intermedie e copyleft. Una licenza debole non limita in alcun modo l'inserimento del codice libero all'interno di un software proprietario, mentre una licenza copyleft proibisce questa operazione, permettendo l'uso del codice libero solo ai programmi provvisti della stessa licenza. Una licenza intermedia stabilisce alcune condizioni circa l'aggiunta di codice proprietario, ma non cerca di proibirla.

Generalmente le licenze permissive deboli (BSD modificata, X11, Expat, Apache, Python, ecc.) sono compatibili tra di loro. Ciò si deve al fatto che esse non prevedono alcun vincolo o limite al codice aggiunto al programma. Permettono addirittura di inserire l'intero programma (con o senza modifiche) all'interno di un software proprietario. Perciò queste licenze vengono definite “licenze permissive” dato che non sanno dire “no” quando un utente cerca di negare la libertà agli altri.

In una combinazione di programmi protetti da licenze deboli, ogni programma porta con sé la licenza della quale era originariamente dotato. Quando il codice viene amalgamato al punto da rendere indistinguibili le parti, allora il codice risultante dall'unione dovrebbe possedere tutte le licenze delle parti congiunte. Dal momento che, in questo caso, tutte le licenze sono di tipo debole, non si crea un problema effettivo, eccetto per la lunghezza della lista delle licenze.(**)

Per la stessa ragione, le licenze deboli sono solitamente compatibili con tutte le licenze copyleft. All'interno del programma combinato, infatti, le parti inserite con licenze deboli continuano ad essere protette dalle stesse licenze e il programma combinato risulta protetto dalla licenza copyleft. Una licenza debole, la Apache 2.0, contiene clausole sui brevetti che sono incompatibili con la GPL versione 2, ma, dal momento che ritengo buone tali clausole, ho fatto in modo che la GPL versione 3 fosse compatibile con esse.

Un'eccezione significativa è rappresentata dalla licenza BSD originale, a causa della sua “detestabile clausola pubblicitaria.”Tale clausola imponeva l'inserimento di una specifica nota in tutte le pubblicità di tutti i prodotti contenenti qualsiasi codice rilasciato sotto l'originale licenza BSD. Ciò era, ed è tuttora, incompatibile con tutte le vere licenze copyleft. Rappresentava inoltre una grossa scocciatura per tutte le distribuzioni, dal momento che i programmi si accumulavano con requisiti pubblicitari simili ma tuttavia differenti. Ad un certo punto, una distribuzione BSD richiedeva l'aggiunta di oltre una settantina di inserzioni.

Ho eliminato quasi per intero il problema convincendo il preside di facoltà, Hal Varian, a spingere la UC Berkeley a pubblicare la “licenza BSD modificata” (senza la clausola pubblicitaria) e a rilasciare nuovamente il codice della Distribuzione del Sistema Berkeley sotto questa licenza modificata. Oggigiorno la licenza BSD originale è (fortunatamente) raramente usata, ma è ancora necessario stare attenti a non parlare “della” licenza BSD.

Generalmente due diverse licenze copyleft sono inevitabilmente incompatibili a meno che non siano provviste di esplicita clausola di compatibilità. Ciò non è dovuto ad un errore nella stesura dei dettagli della licenza, ma deriva dall'idea stessa di copyleft. L'idea del copyleft è che “le versioni modificate ed estese debbano essere protette dalla stessa licenza.” Se la licenza A dice che i programmi estesi devono portare la licenza A, e la licenza B dice che i programmi devono portare la licenza B, tra loro vi è un inconciliabile disaccordo; la licenza del programma combinato dovrà per forza essere A e anche B. Questa è la ragione per cui la GPL versione 2 è incompatibile con la GPL versione 3; ciò era inevitabile. Allo stesso modo, le condizioni della CC-BY-SA 4.0 sarebbero intrinsecamente incompatibili con quelle della CC-BY-SA 3.0, e gli autori non avrebbero potuto evitarlo in alcun modo.

Ci sono due modi per evitare l'incompatibilità intrinseca nelle nuove versioni di licenze copyleft.

L'approccio usato dalla FSF consiste nel chiedere alle persone di rilasciare il programma sotto “licenza GNU GPL versione N o una qualunque versione successiva della stessa” Questo programma è compatibile con la versione N, e pure con la N+1 (dal momento che offre come opzione la versione N+1). Quando si combina del codice dotato di licenza “GPL 3 o successiva” con del codice accompagnato dalla licenza “GPL 2 o successiva”, la licenza del programma così combinato è la loro intersezione, ovvero la “GPL 3 o successiva”.

Noi speriamo di non dover mai scrivere una versione 4 della GNU GPL, ma niente è perfetto e non possiamo pretendere di aver anticipato tutti i problemi. Rilasciando il vostro codice sotto licenza GNU GPL 3 o successiva, permettete che quel codice venga aggiornato alla versione 4 della stessa, se mai un giorno ce ne sarà bisogno.

L'altro approccio consiste nel fare in modo che ogni versione della licenza permetta automaticamente l'aggiornamento alle versioni successive. Questo è esattamente ciò che fa la Creative Commons: ad esempio, la versione 4.0 della CC-BY-SA (la versione attuale) permette esplicitamente che ogni utente effettui l'aggiornamento alle versioni successive della CC-BY-SA, una volta che esse diventino disponibili. Anche la Mozilla Foundation utilizza questo approccio.

Soltanto le licenze GNU conferiscono agli autori la possibilità di autorizzare o meno l'aggiornamento alle future versioni delle licenze. Quando scrissi la prima versione della GNU GPL, nel 1989, considerai l'inserimento di un'opzione che permettesse automaticamente l'aggiornamento della licenza, così come avviene nelle licenze CC, ma pensai fosse più corretto affidare la scelta a ciascun autore. In tal modo l'autore può scegliere se rilasciare il programma sotto la licenza “GPL 1” oppure “GPL 1 o successiva.”

Mi è capitato, da allora, di mettere in discussione la saggezza di quella decisione. Programmi come Linux, che permettono una sola versione della GNU GPL e rifiutano l'aggiornamento della licenza, sono causa di effettiva incompatibilità.(***) Forse faremmo bene ad includere una clausola di aggiornamento nella versione 4 della GPL, se mai avremo bisogno della versione 4.

Alcune licenze copyleft permettono la combinazione del codice tra varie licenze copyleft con un'esplicita clausola di re-licenziamento che consente di proteggere il codice con una diversa licenza copyleft. Per esempio, la licenza CeCILL offre un esplicito permesso di re-licenziamento del codice alla versione 2 e successiva della GNU GPL. Se il programma P è dotato della licenza CeCILL e volete combinarlo con il programma Q dotato della licenza GPL versione 3 or successiva, la CeCILL dice che potete farlo rilasciando il codice combinato con la licenza GPL versione 3 o successiva.

L'esplicito permesso di re-licenziamento non equivale alla compatibilità (anche se questo può renderlo compatibile con altro codice) e non è simmetrico. Ad esempio, la CeCILL conferisce l'esplicito permesso di re-licenziare il codice sotto licenza GNU GPL, ma non è possibile fare il contrario poiché la GNU GPL non permette di re-licenziare sotto licenza CeCILL. Perciò, non potete combinare due programmi P e Q e distribuire la combinazione sotto licenza CeCILL; ciò violerebbe la GPL che protegge il programma Q. L'unica maniera legale di rilasciare un tale programma combinato è facendolo accompagnare dall'appropriata versione della GPL.

Similmente, la licenza CC-BY-SA 4.0 permette l'esplicito re-licenziamento delle versioni modificate sotto la GNU GPL versione 3, ma la GPL versione 3 non permette di re-licenziare sotto licenza CC-BY-SA. Questo problema non dovrebbe presentarsi per il software; la Creative Commons dice che le sue licenze non sono pensate per il codice e che la licenza da usare per il codice è la GNU GPL. Vi sono tuttavia altri tipi di lavori, come i progetti hardware o artistici per videogiochi, dove si potrebbe presentare l'occasione di unire del materiale rilasciato sotto licenza CC-BY-SA con materiale rilasciato sotto licenza GNU GPL. Questo si può ottenere attraverso l'esplicito permesso di re-licenziamento contenuto nella licenza CC-BY-SA.

Sfortunatamente, la licenza CC-BY-SA 4.0 non permette di re-licenziare verso versioni successive della GPL. Ciò che dovreste fare, quando re-licenziate alla GPL del materiale con originaria licenza CC-BY-SA 4.0, è di conferire a voi stessi la delega della versione della licenza per indicare se le versioni future della GPL sono adatte a tale materiale. Se un giorno vi sarà la versione 4 della GPL e Creative Commons deciderà di permettere il re-licenziamento dalla CC-BY-SA alla GPL versione 4, voi, in qualità di delegati, sarete in grado di autorizzare retroattivamente l'utilizzo di quel materiale sotto licenza GPL versione 4 (in alternativa, potete chiedere direttamente agli autori del materiale di concedervi il permesso necessario).

Le licenze GNU GPL e la GNU Affero GPL standard sono due diverse licenze copyleft, e perciò naturalmente incompatibili. Abbiamo però istituito una speciale compatibilità tra le due: è possibile includere un codice sorgente sotto licenza GNU GPL versione 3 con del codice protetto da GNU Affero GPL all'interno di uno stesso programma combinato. Ciò è stato possibile poiché entrambe le licenze garantiscono questa compatibilità in modo esplicito e, in tal caso, la GNU AGPL viene applicata al programma combinato. Tuttavia, non potete semplicemente re-licenziare del codice dalla GNU GPL (con o senza “o successiva”) alla GNU Affero GPL, o viceversa; nessuna delle due licenze lo permette. Notate inoltre che la GNU Affero GPL versione 3 non è una “versione successiva” della comune licenza GNU GPL versione 2 dal momento che la GNU Affero GPL e la GNU GPL fanno parte di due serie di licenze differenti.

La GNU Lesser General Public License (LGPL), versione 3, non è altro che la GNU General Public License versione 3 con l'aggiunta di alcuni permessi extra. La GPL versione 3 (sezione 7) afferma che è sempre possibile rimuovere i permessi aggiuntivi, vincolando così il codice alla ordinaria licenza GNU GPL versione 3. Se un programma permette l'utilizzo sotto licenza GNU LGPL versione 3 o successiva, potete rilasciarlo sotto la GPL versione 3 o successiva; per ciascuna futura versione della GPL versione N (N > 3), noi scriveremo una licenza LGPL versione N che sarà semplicemente la GPL versione N con l'aggiunta di alcuni permessi.

Lo stesso vale per la GNU Lesser GPL versione 2.1, la quale permette esplicitamente il re-licenziamento verso la licenza GNU GPL versione 2 o successiva.

Le licenze intermedie sono licenze dotate di importanti vincoli alla redistribuzione, ma non sono tuttavia copyleft. Alcuni esempi di questo tipo di licenze sono la Eclipse Public License e la Mozilla Public License. Le licenze intermedie tendono ad essere incompatibili con le licenze copyleft dal momento che le loro clausole non permettono che un programma combinato venga rilasciato sotto una licenza copyleft. La Mozilla Public License permette tuttavia il re-licenziamento verso la GNU GPL, ad eccezione del caso in cui il codice lo proibisca esplicitamente.

E per quanto riguarda la doppia licenza?(****) Tramite la doppia licenza si opera una separazione: per uno stesso programma è possibile scegliere tra due o più licenze diverse. Ad esempio, le versioni vecchie di Perl contenevano una doppia licenza: la Artistic License e la GNU General Public License. Ciò permetteva a ciascun utente di scegliere di utilizzare e ridistribuire Perl sotto una o l'altra licenza, oppure entrambe come avveniva per la versione originale Perl. Questa disgiunzione è compatibile con un gruppo di altre licenze se una qualunque delle opzioni di scelta è compatibile con il detto gruppo di licenze.

Quando scegliete una licenza per il vostro codice, vi preghiamo di scegliere la licenza GNU GPL versione 3 o successiva, oppure una licenza che sia compatibile con essa. In tal modo vi assicurate che il vostro codice sia combinabile con la maggior parte del corpus del software libero. Scegliere la GPL o la AGPL, versione 3 o successiva, porterà inoltre massimi benefici alla difesa della libertà di tutti gli utenti per tutte le versioni del vostro codice.

Note

* Il caso più eclatante di una licenza effettivamente utilizzata che si comporta in maniera irragionevole è la licenza di TeX: se due programmi seguono il modello della licenza di TeX, non esiste una maniera legale di distribuirne una versione combinata.

La licenza TeX autorizza la distribuzione di una versione modificata esclusivamente nella forma della versione originale con l'aggiunta di un file contenente le differenze. Se A e B vengono rilasciati separatamente in questa maniera, e quindi combinati, la distribuzione del programma derivante dalla combinazione di A, con l'aggiunta di una differenza, e B, viola la licenza di B. La distribuzione del programma combinato in qualità di B, con l'aggiunta della differenza, viola la licenza A. Distribuire il programma in qualunque altra maniera viola entrambe le licenze.

Che TeX sia stato rilasciato nel 1982 non è una coincidenza: la nostra comunità ha da allora imparato a scrivere licenze caratterizzate da un comportamento assai più ragionevole.

** Quando si distribuisce un programma sotto forma di codice sorgente, è di solito sufficiente lasciare le inserzioni di licenza così come si trovano; inserzioni aggiuntive sono tipicamente richieste soltanto nel caso di licenze deboli, quando si distribuiscono programmi binari sprovvisti del codice sorgente.

*** In aggiunta, la licenza GPL versione 2 permette tuttora di trasformare i programmi binari in software proprietario quando l'hardware rifiuta di funzionare se non con programmi binari speciali e ancora non permette la distribuzione di programmi binari attraverso il protocollo Bittorrent, che non esisteva quando venne pubblicata. Abbiamo corretto queste magagne, ed altre ancora, nella versione 3 della GPL, tuttavia non possiamo modificare la versione 2 della stessa.

**** Alcuni utilizzano in maniera inesplicabile il termine “duplice licenziamento” per fare riferimento alle vendita di eccezioni, ma ciò è un abuso del linguaggio. Vedasi Vendere eccezioni alla GNU GPL. Notate bene che se la licenza venduta come eccezione include un qualunque codice non presente nella comune versione libera, ciò non significa vendere eccezioni, piuttosto si tratta di software non libero.