Il software libero si definisce per i permessi che concede sul codice sorgente, non per il prezzo. La Free Software Foundation li elenca come quattro libertà, numerate da 0 a 3: eseguire il programma per qualunque scopo, studiarne il funzionamento e adattarlo, ridistribuirne copie, distribuire versioni modificate. Perché le ultime tre siano davvero esercitabili serve una condizione: l’accesso al codice sorgente. Tutto il resto — le licenze, i modelli di sviluppo, le dispute sui nomi — discende da una domanda sola: come rendere queste libertà non revocabili.

Il problema che il copyleft risolve

Una licenza permissiva, come quella dei sistemi BSD, concede le quattro libertà a chi riceve il codice ma non impone niente a chi lo ridistribuisce. Chi prende un sorgente BSD può modificarlo, compilarlo e distribuire solo il binario, sotto una licenza proprietaria. Il destinatario finale riceve un programma utile e nessuna delle quattro libertà. Le libertà ci sono al primo passaggio e si perdono al secondo.

La GNU General Public License interviene esattamente qui. La versione 2, pubblicata nel giugno 1991, mette una condizione sulla ridistribuzione: chi distribuisce un’opera derivata da codice coperto dalla GPL deve renderla disponibile sotto la stessa licenza, e deve fornire o rendere disponibile il sorgente corrispondente. È il meccanismo che Richard Stallman ha chiamato copyleft, gioco di parole su copyright. L’autore non rinuncia al proprio copyright: lo usa per imporre che le libertà concesse si propaghino a ogni redistributore successivo.

Così le quattro libertà diventano ereditarie. Un programma GPL può attraversare un numero qualsiasi di modifiche e ridistribuzioni, e a ogni passaggio il destinatario riceve gli stessi permessi del primo. La licenza permissiva garantisce le libertà come stato iniziale; la GPL le garantisce come invariante lungo tutta la catena di distribuzione.

Cosa vuol dire “opera derivata”

Il punto delicato della GPL è la definizione di opera derivata, perché è lì che si decide fin dove arriva l’obbligo di copyleft. La GPL versione 2 lega quell’obbligo alla nozione di opera derivata del diritto d’autore, non a un criterio tecnico esplicito. Resta quindi una zona grigia molto concreta: un programma proprietario che si collega (link) a una libreria GPL, per la FSF, ne diventa opera derivata, e la libreria diventa inutilizzabile da software non libero.

Per le librerie di sistema l’effetto era indesiderabile. Una libreria C di base rilasciata sotto GPL piena avrebbe imposto la GPL a qualunque programma compilato per quel sistema. Per questo nel 1991, insieme alla GPL versione 2, la FSF pubblica la GNU Library General Public License versione 2, una licenza dal copyleft più debole: il codice della libreria resta libero e ogni sua modifica resta sotto la stessa licenza, ma un programma che si limita a collegarsi alla libreria può avere qualunque licenza, anche proprietaria. La distinzione tra GPL e LGPL è una scelta di confine: dove far passare la linea oltre la quale il copyleft non si propaga.

Due nomi per la stessa cosa, due ragioni diverse

Dal 1998 lo stesso software viene chiamato in due modi, free software e open source, e la differenza non è tecnica ma di motivazione dichiarata. La Open Source Initiative, fondata nel febbraio 1998 da Eric Raymond e Bruce Perens, ha adottato la Open Source Definition, ricavata dalle Debian Free Software Guidelines scritte da Perens. I dieci criteri della Open Source Definition e le quattro libertà della FSF classificano quasi lo stesso insieme di licenze: GPL, LGPL, BSD e MIT soddisfano entrambi gli elenchi.

La scelta di open source fu deliberata, e argomentata su basi pragmatiche: in inglese l’aggettivo free oscilla tra “libero” e “gratuito”, e la OSI giudicava il discorso sulle libertà poco spendibile davanti alle aziende. Conviene tenere separati due piani, la classificazione e l’argomentazione. Sulla classificazione le due definizioni quasi coincidono. Sull’argomentazione divergono: la FSF motiva il software libero come questione di permessi dovuti all’utente, la OSI come metodo di sviluppo più efficace.

L’argomento della OSI sul metodo è formulato con precisione nel saggio di Eric Raymond The Cathedral and the Bazaar, presentato al Linux Kongress nel maggio 1997 e ripubblicato in volume nel 1999. La tesi centrale — “dato un numero sufficiente di occhi, tutti i bug vengono a galla” — fa della disponibilità del sorgente la variabile che accelera la scoperta dei difetti. È un’affermazione sul processo di sviluppo, indipendente dalla questione delle libertà, e spiega perché molti progetti adottano licenze libere per ragioni che con il copyleft non c’entrano nulla.

Cosa controllare prima di adottare una licenza

Leggendo una licenza, la distinzione che conta davvero è una: cosa succede quando ridistribuisci. Tre cose concrete da verificare. Primo, se la licenza obbliga a rendere disponibile il sorgente delle modifiche — è la differenza tra copyleft e permissiva. Secondo, se l’obbligo riguarda il solo file modificato, l’intero programma, o anche il software che si limita a collegarsi — è la differenza tra GPL e LGPL. Terzo, se la licenza è compatibile con le altre già presenti nel progetto, perché mettere insieme codice con obblighi diversi può dare un risultato che non si può distribuire.

Queste tre domande vengono prima di qualunque discorso su comunità, modello di sviluppo o terminologia. Decidono cosa è lecito fare con il codice una volta integrato, ed è l’unica parte della scelta che non si può rimandare.

Immagine di copertina: Richard Stallman, fondatore del progetto GNU, durante un intervento a Wikimania 2005 — foto di Fafnir~commonswiki, pubblico dominio — https://commons.wikimedia.org/wiki/File:Wikimania2005_Richard_Stallman_2005-08-07.JPG