Il 29 giugno 2007 la Free Software Foundation ha pubblicato la GNU General Public License versione 3, prima revisione della licenza più diffusa nel software libero da quando era uscita la versione 2 nel 1991. A quattro mesi di distanza, quell’evento sposta il problema pratico di chi sviluppa o adotta software libero: non più “è libero o no”, ma “questo codice libero si combina con quell’altro codice libero”.

Contesto

In Italia l’autunno 2007 vede parecchie iniziative sul tema. Il 27 ottobre c’è il Linux Day, coordinato dalla Italian Linux Society e organizzato sul territorio dai LUG in oltre cento città, con l’ingresso libero come requisito esplicito della manifestazione. Nelle stesse settimane la Regione Toscana ospita, dentro il Festival della Creatività alla Fortezza da Basso di Firenze, due giornate dedicate ai saperi liberi sotto il marchio QuiFree.

L’espressione “saperi liberi” allarga il discorso oltre il software: dati pubblici, materiale didattico, formati documentali. Ma il nucleo tecnico resta il software, e lì il quadro normativo si è appena mosso in modo sostanziale.

Il problema delle licenze

La Open Source Definition, mantenuta dalla Open Source Initiative, è ferma alla versione 1.9 dal 22 marzo 2007. Fissa dieci criteri che una licenza deve rispettare per dirsi open source: ridistribuzione libera, codice sorgente disponibile, opere derivate ammesse, nessuna discriminazione verso persone o campi d’uso, e così via. È un esame d’ammissione, non una garanzia di interoperabilità.

Il punto è che la OSI ha approvato decine di licenze conformi alla Definizione, e queste licenze non sono compatibili tra loro. Codice rilasciato sotto una licenza con clausola di copyleft non si può combinare e ridistribuire sotto una licenza incompatibile, anche quando entrambe rispettano gli stessi dieci criteri. La conformità alla Definizione dice che una licenza è libera; non dice che due licenze libere possano stare insieme nello stesso eseguibile.

La OSI ha riconosciuto il fenomeno aprendo un lavoro sulla proliferazione delle licenze, con la proposta di raggrupparle in categorie e di scoraggiare la creazione di nuove licenze ridondanti. Il problema è strutturale: ogni organizzazione che pubblica una propria licenza, anche conforme, aggiunge un nodo a un grafo di compatibilità sempre più difficile da percorrere.

Cosa introduce la GPLv3

La GPLv3, scritta da Richard Stallman con la consulenza legale di Eben Moglen e Richard Fontana del Software Freedom Law Center, dopo diciotto mesi di consultazione pubblica e quattro bozze, interviene su tre fronti che la versione 2 non copriva.

Primo, i brevetti: chi distribuisce software sotto GPLv3 concede una licenza esplicita sui brevetti che possiede e che il software mette in pratica, e la licenza neutralizza accordi del tipo Microsoft-Novell del novembre 2006, dove un distributore otteneva una copertura brevettuale selettiva per i propri clienti.

Secondo, la cosiddetta tivoizzazione: dispositivi che eseguono software GPL ma si rifiutano di avviare versioni modificate dall’utente, bloccati da una firma hardware. Per i prodotti destinati al consumatore, la GPLv3 impone di consegnare le informazioni di installazione necessarie a far girare il codice modificato.

Terzo, la compatibilità: la GPLv3 è scritta per accogliere codice rilasciato sotto alcune licenze prima incompatibili, e così allarga l’insieme delle combinazioni lecite.

Il punto critico

Lo scoglio pratico è che GPLv2 e GPLv3 non sono compatibili tra loro nel caso generale. Un progetto rilasciato come “GPLv2 only” non può incorporare codice “GPLv3 only”, e viceversa. La clausola “or later” — la formula GPLv2 or any later version presente in molti progetti storici — consente la migrazione, ma chi ha scelto di proposito la sola versione 2, come il kernel Linux, resta su un binario separato.

Dal 29 giugno 2007 in avanti, quindi, la base di software libero esistente si divide in tre insiemi: codice che può migrare a GPLv3, codice vincolato alla sola GPLv2, e codice sotto altre licenze copyleft o permissive. Chi assembla un sistema — una distribuzione, un prodotto embedded, un servizio — deve verificare che gli insiemi che mette insieme siano compatibili, e questo controllo non si automatizza leggendo soltanto l’etichetta “open source”.

Implicazioni per chi adotta

Per un’impresa o un ente che valuta il software libero, la conseguenza operativa è che sapere se un componente è libero non basta a chiudere la domanda. Le verifiche concrete sono altre: sotto quale licenza esatta sta il componente; se porta la clausola “or later”; se è collegato in modo statico o dinamico ad altri componenti di licenza diversa; se la ridistribuzione prevista — vendere un dispositivo, offrire un servizio in rete — fa scattare obblighi specifici.

Una distribuzione matura rende praticabile questa verifica. Ubuntu 7.10, uscita il 18 ottobre 2007, divide i pacchetti in componenti per stato di licenza e supporto (main, universe, multiverse, restricted): a livello di repository dice ciò che la sola etichetta “open source” tace. Parte del valore di una distribuzione, letta così, sta anche nel lavoro di curatela legale che porta con sé.

Limiti

Tutto questo riguarda il software. I “saperi liberi” comprendono materiali per cui le licenze software non vanno bene: per testi, immagini e dati ci sono famiglie di licenze diverse — Creative Commons, GNU Free Documentation License — con clausole proprie di attribuzione, condivisione allo stesso modo e uso commerciale, e con problemi di compatibilità reciproca simili a quelli del software, ma non sovrapponibili. Trattare un dataset o una dispensa con gli stessi criteri di una libreria C è un errore.

Resta poi una distinzione che il dibattito divulgativo tende a confondere: “libero” nel senso della FSF e “open source” nel senso della OSI selezionano insiemi di licenze quasi coincidenti ma non identici, e partono da motivazioni diverse. Per le decisioni tecniche conta l’insieme effettivo delle licenze ammesse, non l’etichetta con cui lo si chiama.

Il programma fiorentino dà spazio all’installazione di Ubuntu, al riuso dei vecchi PC e alla certificazione: pratica, non principio. È il livello giusto per misurare se i saperi liberi siano davvero adottabili da chi non scrive codice, o se restino una faccenda per addetti ai lavori. Su quel banco di prova, alla Fortezza da Basso, c’è anche noze, presente a QuiFree.it durante il Festival della Creatività: il resoconto è nell’insight pubblicato da noze https://www.noze.it/insights/quifree-festival-creativita/.

Immagine di copertina: Richard Stallman ritratto a una conferenza nel 2007, con barba e capelli lunghi, mentre guarda di lato — foto di Boro, CC BY-SA 3.0 — https://commons.wikimedia.org/wiki/File:Richard_stallman_portrait.png