Due licenze open sono compatibili se un’opera derivata può rispettare tutte le clausole di entrambe nello stesso momento; la qualità tecnica del codice non c’entra. Quando questa possibilità non esiste, il codice resta inutilizzabile in combinazione anche se compila, gira e fa esattamente ciò che serve.

Contesto

Una licenza open è uno strumento per gestire i diritti d’autore. Al posto della regola predefinita dell’ordinamento — tutti i diritti riservati all’autore — mette una concessione esplicita a terzi di alcune facoltà: accesso al codice sorgente, studio, copia, modifica, ridistribuzione. La Open Source Definition elenca i criteri che una licenza deve soddisfare per dirsi tale. La sua Annotated Version ricorda che una licenza non vive isolata dal diritto applicabile: leggerla senza tener conto delle norme imperative dello Stato in cui opera è come leggere un testo ignorando il vocabolario della sua lingua.

Il software open raramente parte da zero. Il valore sta nel riuso: si mettono insieme moduli di provenienza diversa, ciascuno governato dalla propria licenza. Qui la pratica si scontra con l’intuizione comune dello sviluppatore, per cui col codice “si fa tutto”. In astratto è vero. Nel momento in cui distribuisco un’opera derivata, quel “tutto” si riduce alle operazioni che la licenza concede, e l’insieme può essere vuoto.

Il problema

Mettere insieme due programmi sotto licenze diverse produce un’opera derivata che deve soddisfare entrambe le licenze d’origine nello stesso momento. Se le due impongono obblighi che non possono coesistere, l’opera derivata non si può distribuire in modo lecito: o si rinuncia alla combinazione, o la si distribuisce comunque e si commette una violazione del diritto d’autore.

L’incompatibilità più frequente nasce tra due licenze copyleft forti. Il copyleft impone che ogni opera derivata venga ridistribuita sotto la stessa licenza. Se la licenza A vuole che il derivato esca sotto A, e la licenza B vuole che esca sotto B, il derivato dovrebbe essere A e B nello stesso momento — condizioni che si escludono a vicenda. Nessun derivato le soddisfa entrambe, quindi nessun derivato è lecito.

L’altra sorgente di incompatibilità, meno evidente, sono le clausole sui brevetti. Su queste si gioca buona parte delle frizioni recenti, e meritano una sezione a sé.

L’architettura delle clausole

Conviene leggere le licenze non come blocchi monolitici, ma come insiemi di clausole i cui effetti si combinano oppure no. Ricorrono tre famiglie.

Le licenze permissive in stile BSD impongono pochi obblighi: tenere l’avviso di copyright, riprodurre il testo della licenza, in qualche variante non usare il nome dell’autore per promuovere derivati senza permesso. Sulla licenza dell’opera derivata non dicono nulla. Per questo si combinano con quasi tutto, codice proprietario compreso: un modulo BSD si lega a un programma chiuso senza problemi di compatibilità, purché si dia conto della paternità.

Le licenze copyleft per file o per modulo, come la Mozilla Public License 1.1, applicano la reciprocità al singolo file modificato, non all’intero aggregato. Con loro si costruisce un’opera in cui un modulo MPL e un modulo proprietario restano distinti e licenziati a parte, a patto che le modifiche ai file MPL restino sotto MPL. È un copyleft a grana fine, pensato proprio per convivere con codice chiuso.

Le licenze copyleft forti, come la GNU GPL, estendono l’obbligo all’intera opera derivata. Chi mette insieme codice GPL e altro codice in un’unica opera deve rilasciare il tutto sotto GPL. Questo rende la GPL strutturalmente incompatibile con le licenze proprietarie quando si creano opere derivate combinate, e incompatibile con qualunque altra licenza imponga condizioni che la GPL non ammette. La GNU LGPL allenta il vincolo per consentire il linking da programmi sotto altre licenze, ma tiene copyleft la libreria stessa.

Il punto critico: i brevetti e le versioni della GPL

Il caso che mostra quanto la compatibilità sia fragile è quello tra Apache License 2.0 e GPL.

La Apache License 2.0 contiene una concessione esplicita di brevetto da parte dei contributori e una clausola di terminazione: chi avvia un’azione brevettuale sul software perde i diritti concessi. La Free Software Foundation legge queste clausole — terminazione brevettuale e indennizzo — come restrizioni aggiuntive che la GPLv2 non prevede e non ammette. Per questo Apache 2.0 e GPLv2 sono incompatibili: il codice Apache 2.0 non si può incorporare in un’opera GPLv2 (Apache Software Foundation, GPL compatibility).

La GPLv3, pubblicata dalla FSF il 29 giugno 2007 insieme alla LGPLv3, è stata scritta tenendo conto proprio di queste clausole. Ha un proprio meccanismo di concessione e ritorsione brevettuale e dichiara esplicitamente compatibili alcune restrizioni aggiuntive, tra cui quelle della Apache 2.0. Così la FSF considera Apache 2.0 compatibile con la GPLv3: il codice Apache 2.0 si può includere in un progetto GPLv3, mentre il contrario non vale, perché la GPLv3 impone condizioni che la Apache 2.0 non riproduce.

Apache 2.0 e GPL restano le stesse; cambia la versione della controparte, e il verdetto di compatibilità si ribalta. La compatibilità non è un attributo della singola licenza, ma una relazione tra coppie di clausole, sensibile alle revisioni.

Implicazioni per il diritto italiano

La conclusione tecnica — un derivato è lecito solo se rispetta tutte le clausole d’origine — coincide con quanto prevede la legge italiana sul diritto d’autore. L’art. 4 della legge 633/1941 protegge le elaborazioni di carattere creativo dell’opera “senza pregiudizio dei diritti esistenti sull’opera originaria”. Nel caso del software open, i diritti esistenti sull’opera originaria sono quelli che la sua licenza definisce. Un’opera derivata che violi le clausole della licenza d’origine arreca pregiudizio a quei diritti, e l’autorizzazione dell’autore viene meno: torna in vigore la riserva predefinita, tutti i diritti riservati. Il software che si voleva distribuire diventa una violazione.

Tornano così a coincidere due piani che lo sviluppatore tende a tenere separati. La verifica di compatibilità non è un adempimento formale da fare dopo aver scritto il codice. È un vincolo di progetto al pari delle dipendenze tecniche, da sciogliere mentre si disegna l’architettura, quando ancora si sceglie quale libreria adottare e sotto quale licenza rilasciare.

Limiti

Quanto sopra fissa il criterio generale ma non sostituisce l’analisi del caso concreto. Il confine tra “opera derivata” e “mera aggregazione” non è netto e dipende dal modo in cui si combina — linking statico, linking dinamico, comunicazione tra processi separati — su cui le stesse comunità non concordano del tutto. Sulla compatibilità tra Apache 2.0 e GPLv3 ci sono state letture discordanti, prima che le posizioni FSF si assestassero. E ogni clausola va letta nell’ordinamento dove sarà applicata: una licenza scritta su modello statunitense interagisce con la 633/1941 in modi che l’autore originale non sempre ha previsto. Per una decisione di rilascio o di commercializzazione resta necessario lo studio puntuale delle licenze in gioco e delle loro interazioni.

https://opensource.org/docs/osd https://www.gnu.org/licenses/license-list.html http://www.apache.org/licenses/GPL-compatibility.html https://www.gnu.org/licenses/gpl-3.0.html https://www.gnu.org/licenses/quick-guide-gplv3.html https://www.mozilla.org/MPL/1.1/ https://www.noze.it/insights/compatibilita-licenze-open-proprietarie/

Immagine di copertina: Diagramma a frecce che mostra la compatibilità tra le principali licenze software open source — da quelle permissive in stile BSD,… — diagramma di David A. Wheeler, CC BY-SA 3.0 — https://commons.wikimedia.org/wiki/File:Floss-license-slide-image.svg