«Open source» non è un’etichetta che si appiccica a piacere: è la conformità verificabile a un documento, la Open Source Definition (OSD), che mantiene la Open Source Initiative (OSI). Una licenza è open source se e solo se rispetta i dieci criteri della OSD, e l’OSI ne tiene l’elenco certificato. Per chi distribuisce codice conta una cosa sola: i termini che scegli vincolano per sempre chiunque riceva il software, e da una licenza approvata all’altra gli obblighi giuridici si rovesciano.

La OSD e il ruolo dell’OSI

L’OSI nasce nel febbraio 1998 da Eric Raymond e Bruce Perens. La OSD non è stata scritta da zero: deriva dalle Debian Free Software Guidelines (DFSG), che Perens aveva redatto nel 1997 per Debian, ripulite dei riferimenti specifici a Debian. È un documento di criteri, non una licenza: dice cosa una licenza deve concedere, non come scriverla.

I dieci criteri impongono, tra le altre cose, la libera redistribuzione senza royalty, la disponibilità del codice sorgente, il permesso di creare opere derivate e di redistribuirle sotto la stessa licenza, nessuna discriminazione verso persone o gruppi, nessuna restrizione sul campo di applicazione — il criterio 6: il software non può vietare l’uso, per dire, in ambito commerciale o nella ricerca genetica. Il decimo criterio, aggiunto nel 2002, chiede che la licenza sia neutrale rispetto alla tecnologia: non può dare per scontata una precisa modalità di distribuzione, per esempio pretendere un click-through.

Quel che la OSD non garantisce pesa quanto il resto. Non obbliga il codice derivato a restare aperto. Una licenza che lascia prendere il sorgente, modificarlo e ridistribuirlo come prodotto chiuso è perfettamente conforme alla OSD. La OSD fissa un minimo di libertà concesse a chi riceve il software; quanto imporre oltre quel minimo lo decide l’autore.

Le tre famiglie

Le licenze certificate OSI si dispongono lungo un asse che nasce da una domanda: cosa succede al sorgente di un’opera derivata distribuita a terzi? Le risposte si raggruppano in tre famiglie.

Copyleft forte. Il caso di riferimento è la GNU General Public License (GPL), scritta da Richard Stallman, nella versione 2 del giugno 1991. La clausola operativa (sezione 2b) impone che ogni opera «basata sul Programma» distribuita a terzi esca, nel suo insieme, sotto GPL. Il meccanismo è ricorsivo: la libertà si propaga lungo ogni anello della catena di derivazione. La conseguenza pratica più discussa riguarda il linking: collegare codice proprietario a una libreria GPL produce, secondo la Free Software Foundation, un’opera derivata, quindi vincolata alla GPL. Per questa lettura le aziende che vogliono mantenere chiuso il proprio codice evitano di linkare librerie GPL.

Copyleft debole. La GNU Lesser General Public License (LGPL), versione 2.1 del febbraio 1999, nasce esattamente per quel problema. Tiene il copyleft sul codice della libreria — chi la modifica deve rilasciare le modifiche sotto LGPL — ma concede in modo esplicito che un programma proprietario possa linkare la libreria senza diventare a sua volta LGPL. L’obbligo si ferma al confine della libreria. La Mozilla Public License (MPL) 1.1, del 1999, applica lo stesso principio a livello di singolo file: i file nati MPL restano MPL anche combinati con codice proprietario, ma il combinato nel suo insieme non è vincolato.

Permissive. Le licenze BSD e MIT chiedono il minimo che la OSD ammette: conservare la nota di copyright e il testo della licenza. Nessun obbligo sul codice derivato, che può essere chiuso. La vecchia BSD «a quattro clausole» portava con sé una clausola pubblicitaria, cioè l’obbligo di citare l’autore in ogni materiale promozionale; Berkeley l’ha ritirata nel 1999 su richiesta della Free Software Foundation, e ne è uscita la BSD «a tre clausole» oggi raccomandata. La licenza Apache corrente, la Apache License 1.1 (2000), è una BSD a tre clausole con i nomi cambiati più una clausola sull’uso del marchio «Apache».

La compatibilità

La conseguenza meno intuitiva è che due licenze entrambe certificate OSI possono essere incompatibili tra loro: il codice sotto l’una non si può combinare e distribuire sotto l’altra. La GPL è il caso più rigido. La sua sezione 6 vieta di aggiungere restrizioni oltre quelle della GPL stessa, perciò il codice sotto una licenza che impone un obbligo in più — anche minimo — non si può fondere con codice GPL in un’unica opera distribuita.

La clausola pubblicitaria della vecchia BSD a quattro clausole è il caso da manuale: imponendo la citazione nei materiali promozionali aggiungeva una restrizione che la GPL non ammette, e rendeva i due corpi di codice incompatibili. È una delle ragioni tecniche per cui Berkeley l’ha tolta. La Apache License 1.1, pur avendo eliminato quella clausola pubblicitaria che era già nella Apache 1.0, resta per la Free Software Foundation incompatibile con la GPLv2: aggiunge termini su attribuzione e uso del nome che la GPL non ammette.

La compatibilità è quindi una proprietà di coppia, non di singola licenza, e si valuta solo quando si combina codice di provenienza diversa in un’unica opera distribuita. Per un programma a licenza unica il problema non esiste; salta fuori appena si linkano librerie di terzi.

Cosa cambia per chi distribuisce codice

Scegliere la licenza è una decisione tecnica con effetti irreversibili sul codice già pubblicato: le versioni future si possono ri-licenziare, ma ogni copia già distribuita resta sotto i termini con cui è uscita. Tre conseguenze operative:

  • Una libreria pensata per essere adottata anche da software proprietario non può stare sotto GPL; restano LGPL, MPL o una permissiva.
  • Per combinare codice di terzi si verifica la compatibilità a coppie, non che ogni singola licenza sia «open source». Due licenze approvate non bastano a garantire un risultato distribuibile.
  • Una permissiva massimizza l’adozione, ma non garantisce che i derivati restino aperti; un copyleft garantisce l’apertura dei derivati, ma restringe chi può integrare il codice.

Limiti

La OSD certifica le licenze, non decide i casi limite. La questione del linking dinamico contro la GPL, a oggi, non ha una sentenza che la chiuda: la lettura della Free Software Foundation è autorevole, ma non è giurisprudenza consolidata. Allo stesso modo, la qualifica «open source» riguarda i termini della licenza, non la disponibilità reale di un repository, di una comunità o di processi di contribuzione: un progetto può avere licenza OSI e codice che nessuno mantiene. La OSD risponde a una domanda sola — quali libertà concede la licenza — e va letta sapendo che è quella.

https://opensource.org/docs/definition.php https://www.gnu.org/licenses/gpl.html https://www.gnu.org/licenses/lgpl.html https://www.gnu.org/licenses/license-list.html https://www.apache.org/licenses/LICENSE-1.1 https://www.mozilla.org/MPL/MPL-1.1.html https://www.debian.org/social_contract#guidelines https://www.noze.it/insights/licenze-oss-osi/

Immagine di copertina: Logo della Open Source Initiative: un buco della serratura stilizzato verde con bordo verde scuro, che fonde la lettera O con la… — logo di Colin Viebrock, CC BY 2.5 — https://commons.wikimedia.org/wiki/File:Open_Source_Initiative_keyhole.svg