2.1 Il Software libero

Il concetto di ‘software libero’ (SL) è legato, come dice la parola stessa, all'ideale di libertà e si richiama al principio dello scambio senza restrizioni di idee e di informazioni che è alla base anche della libertà di pensiero e di espressione. Al pari delle idee, infatti, il software ha una natura immateriale, può essere facilmente riprodotto e trasmesso ad altri e, in modo analogo a quanto avviene per le idee, la libera diffusione rappresenta un presupposto per la sua evoluzione, crescita e continuo miglioramento.

In questo sono evidenti le somiglianze con quanto accade nel mondo della ricerca scientifica, dove la diffusione pubblica dei risultati (pur con il riconoscimento della paternità dell'opera), la libertà di ricerca, la peer review e la cooperazione internazionale rivestono un ruolo fondamentale. Ciò è dovuto al fatto che prima dell'avvento delpersonal computer negli anni '80, quando i costi proibitivi dei calcolatori li rendevano una prerogativa delle università e dei centri di ricerca più avanzati, spesso le figure del ricercatore e dello sviluppatore venivano a coincidere e perciò il modello di sviluppo e distribuzione più naturale per il software era proprio quello stesso della ricerca nel mondo accademico.

Per chiarire il concetto di SL, tuttavia sono necessarie alcune precisazioni introduttive sulla natura del software. Nella sezione successiva si tenterà di offrire una sintesi molto generale su che cosa sia il software e sul modo in cui viene prodotto, per chiarire concetti chiave quali ‘codice sorgente’ o ‘compilazione’ che verranno ripresi nelle definizioni successive.

2.1.1 Che cos'è il software?

Nei moderni sistemi di elaborazione la programmazione, cioè la specifica delle sequenze di operazioni che la macchina deve eseguire, non avviene in maniera ‘cablata’ (in hardware) ma attraverso una serie di istruzioni rappresentate alla stregua di dati su cui operano, quindi in formato binario, che risiedono fisicamente nella stessa sede di questi ultimi (cioè la memoria principale): questo principio fondamentale è alla base del concetto di software.

I programmi, in quest'ottica, possono essere immaginati come sequenze di istruzioni corrispondenti alle operazioni elementari di elaborazione, trasferimento dati da/verso la memoria e controllo che corrispondono alle funzionalità del processore (CPU). Ogni famiglia di processori risponde a una serie di specifiche architetturali (il repertorio di operazioni della o delle unità aritmetico-logiche; l'organizzazione, la dimensione e il numero di registri; il formato e il ciclo di esecuzione delle istruzioni; i metodi di indirizzamento utilizzati; ecc…) ed è dotata pertanto del proprio specifico linguaggio macchina (instruction set) che rispecchia queste caratteristiche di progettazione.

Semplificando, un programma in linguaggio macchina corrisponde a una serie di 0 e di 1, raggruppabili nelle varie istruzioni, che vengono recuperate dalla memoria maniera più o meno sequenziale, decodificate in base al loro codice operativo ed eseguite sui dati (immediatamente contenuti nell'istruzione o letti a loro volta dalla memoria dopo averne calcolato l'indirizzo).

Dal momento che la programmazione in linguaggio macchina, e cioè a basso livello, è estremamente scomoda per l'uomo anche adottando rappresentazioni alternative a quella binaria (es. esadecimale), un primo livello di astrazione è rappresentato dall'introduzione del linguaggio assembly, in cui ai codici operativi delle istruzioni sono associate etichette mnemoniche (es. ADD, LOAD) e gli indirizzi di memoria possono essere rappresentati in forma simbolica, mediante degli identificatori. Per poter essere eseguito il codice deve essere prima convertito in linguaggio macchina da un apposito programma (assembler), introducendo una prima idea di compilazione.

Il vantaggio, e al contempo lo svantaggio di questo secondo approccio è lo stretto legame con l'architettura sottostante: un programma assembly, se realizzato correttamente, offre vantaggi prestazionali e pieno controllo sull'hardware, ma è fortemente dipendente dal tipo di processore su cui viene eseguito e il suo port su un'architettura diversa ne richiederebbe quasi certamente la riscrittura.

Per questo motivo, così come per rendere più facile l'individuazione di certi errori (ad es. controllo rispetto ai tipi) sono stati introdotti linguaggi ad alto livello, in cui le specifiche del processore diventano trasparenti al programmatore, senza più necessità di gestire direttamente memoria e registri o adottare operatori diversi a seconda del dato manipolato (anche quando questo produce risultati potenzialmente diversi, es. divisione euclidea sugli interi versus divisione sui reali). I linguaggi ad alto livello richiedono, a maggior ragione, di essere convertiti in linguaggio macchina per poter essere eseguiti, con una procedura complessa e articolata che prende il nome di compilazione.

I vantaggi principali di questo approccio rispetto all'assembly si hanno in termini di concisione e più facile comprensibilità, ma anche di indipendenza dall'architettura sottostante: è sufficiente utilizzare opzioni di compilazione differenti per ciascuna architettura a partire dal medesimo codice sorgente. Il risultato è, però, che il software viene ad essere composto da due parti separate: il codice sorgente e il codice eseguibile. Il codice sorgente è il risultato dell'attività del programmatore e consiste in una serie di istruzioni, redatte utilizzando le regole sintattiche di un determinato linguaggio di programmazione, contenute in uno o più file. I sorgenti hanno pertanto la caratteristica fondamentale di essere intellegibili (cioè comprensibili all'uomo) ma non sono adatti all'esecuzione da parte della macchina.

Perché il programma possa essere eseguito dall'elaboratore è necessario che il codice sorgente venga compilato,7 ma il codice oggetto, contenuto nei file eseguibili detti anche binari, è adatto all'esecuzione ma non è intellegibile, il che significa che risulta incomprensibile all'umano. Per il funzionamento del programma è sufficiente disporre soltanto dei file eseguibili ed è per questo motivo che nell'immaginario comune il software è associato tipicamente al solo eseguibile.

Il processo di compilazione è inoltre univoco e irreversibile: non è possibile apportare modifiche al programma se non si dispone del codice sorgente e la decompilazione (cioè l'operazione di ricostruire il codice sorgente a partire dall'eseguibile) e, più in generale, il reverse engineering (cioè lo studio del codice eseguibile volto a scoprirne il funzionamento) sono attività molto complesse, estremamente poco pratiche e, in molti casi, illegali [Giacomini, 2010].

2.1.2 La definizione di Software Libero

La prima definizione ‘formale’ di SL si deve a R. M. Stallman e risale all'inizio degli anni '80. Secondo tale formulazione, può essere definito ‘libero’ il software per cui sono validi i quattro principi enunciati nella tabella tab:liberta che prendono il nome di libertà fondamentali [GNU Project, 2010b].

Vale la pena di notare come tale definizione ponga in modo drastico l'enfasi sulla libertà degli utenti: l'aggettivo ‘free’ utilizzato in inglese non intende essere in alcun modo un riferimento al prezzo (nel senso di ‘gratuito’) quanto piuttosto esprimere l'idea di libertà. In base a quanto enunciato sopra, il programma deve poter essere eseguito da chiunque (persona od organizzazione) su qualsiasi sistema e per qualsiasi scopo senza imposizioni o restrizioni da parte dello sviluppatore (libertà 0, altrimenti detta ‘libertà fondamentale’).

Perché il software possa essere definito ‘libero’ deve essere garantita anche la possibilità di redistribuirne copie in qualsiasi forma, anche commerciale, senza alcuna limitazione se non quella di rispettare l'altrui libertà (libertà 2). Ma la più importante condizione necessaria perché sia possibile parlare di SL è avere accesso al codice sorgente del programma, in modo da rendere possibile a chiunque di studiarne il funzionamento e di modificarlo per adattarlo alle proprie necessità (libertà 1) o per apportarvi dei miglioramenti (libertà 3): da qui il celebre motto «If it's not source, it's not software!».

Va ricordato, però, che la disponibilità del codice sorgente del programma non è condizione sufficiente perché il software possa essere classificato come ‘libero’. Esistono infatti dei casi in cui pur essendo distribuito tanto in formato eseguibile quanto in formato sorgente, il suo utilizzo è ristretto a determinati ambiti: ad esempio non può essere impiegato per trarne profitto o può essere utilizzato solo su determinati sistemi operativi. Tali limitazioni, che è possibile imporre tramite licenze o contratti con l'utente, rappresentano una violazione della libertà fondamentale e non sono, quindi, compatibili con la definizione di SL.

2.1.3 Il progetto GNU e la Free Software Foundation

Quando Stallman cominciò a lavorare presso il MIT nel 1971, lo sviluppo e la distribuzione del software seguivano di fatto le regole del SL, anche se tale definizione non esisteva ancora, perché nessuno sentiva l'esigenza di dare un nome a tale modello essendo quella l'unica possibilità avvertita come naturale e non esistendo ancora alcuna alternativa [Stallman, 1998]. La situazione cambiò radicalmente negli anni '80, con la diffusione del software proprietario e fu allora che per Stallman e per chi come lui era contrario a tale modello si rese necessario dare una forma ‘teorica’ all'idea di SL.

Nel 1983 Stallman fondò inoltre il progetto GNU.8 Lo scopo di tale progetto era quello di creare un insieme di software compatibile con Unix, sistema operativo allora largamente diffuso ma proprietario, con l'intento ultimo di arrivare a costituire un sistema Unix-like pienamente utilizzabile ma disponibile in forma libera. In sostanza, il progetto GNU si proponeva di tradurre nella realtà concretagli ideali alla base del SL. Lo sviluppo vero e proprio del sistema GNU ebbe inizio nel 1984, e l'anno successivo venne costituita la Free Software Foundation (FSF) allo scopo di dare supporto legale e ideologico al progetto GNU.

Nel sistema GNU vennero inclusi alcuni componenti di terze parti considerati liberi, come il motore di tipocomposizione TeX (sviluppato da Donald Knuth) e il gestore grafico X Window System (sviluppato da Bob Scheifler all'interno del MIT), tuttavia era necessario riscrivere tutti gli strumenti principali per poter avere un sistema ‘completo’. Nacquero così la libreria standard del C (glibc), il compilatore gcc e gli altri strumenti della cosiddetta ‘GNU toolchain’, la shell testuale bash (Bourne Again Shell), l'editor di testo GNU Emacs, nonché un set di utilità di base (note come ‘GNU coreutils’) a immagine e somiglianza di quelle presenti in un sistema Unix standard.

Nel 1990 il lavoro poteva dirsi ultimato, con un'unica eccezione: al nuovo sistema mancava un kernel, cioè il componente fondamentale di ogni sistema operativo responsabile di amministrare le risorse di sistema a livello hardware (CPU, dispositivi di memorizzazione e altre periferiche) rendendole disponibili alle varie applicazioni o processi.

Lo sviluppo di HURD, il software destinato a sostituire il kernel Unix nel sistema GNU,9 procedeva infatti a rilento a causa di una serie di difficoltà tecniche che ponevano problemi di stabilità e usabilità. Questa lacuna poté essere colmata nel 1991, quando il finlandese Linus Torvalds, allora studente, creò un kernel funzionante e lo rilasciò l'anno successivo sotto una licenza libera.10 L'integrazione degli strumenti GNU, disponibili come software libero già da diversi anni con il kernel Linux nei primi anni '90 permise di ottenere finalmente un sistema completo.

I sistemi GNU ancora oggi più diffusi si basano sull'integrazione fra il software sviluppato inizialmente dal progetto e il kernel Linux e assumono pertanto la denominazione GNU/Linux.11

Il plurale, nella frase precedente, non è dovuto al caso: si preferisce parlare di sistemi GNU/Linux perché, pur restando il kernel Linux e gli strumenti GNU l'elemento comune, essi vengono in genere distribuiti agli utenti finali accompagnati da software (utilità che facilitano l'installazione, interfacce grafiche predefinite, strumenti di configurazione e amministrazione di sistema) leggermente diversi fra loro. Tali divergenze danno origine a quelle che prendono il nome di ‘distribuzioni Linux’ o, più correttamente, distribuzioni GNU/Linux (cfr. sez. 3.1).

Va infatti sottolineata l'importanza di entrambe le componenti: in prima approssimazione un kernel senza applicazioni da eseguire non permetterebbe all'utente di svolgere alcuna operazione ma d'altra parte una serie di applicazioni senza un kernel non potrebbe essere eseguita sulla macchina.

Come si vedrà più avanti, infine, il progetto GNU va ricordato almeno per un'altra ragione: la licenza messa a punto nel 1989 da parte di Richard Stallman e Eben Moglen con la quale vennero rilasciati i vari componenti del sistema GNU. Tale licenza prese il nome di GNU General Public License (GNU GPL) e costituisce uno dei più importanti pilastri della libertà del software. Prima di passare alla questione delle licenze, però, è necessaria un'ulteriore precisazione di natura terminologica, per chiarire meglio a che cosa si fa riferimento con l'espressione ‘software libero’.

2.1.4 Software libero e software open source

La possibilità di avere accesso al codice sorgente evidenziata fra i requisiti necessari affinché sia garantita la libertà del software è anche quanto viene messo in risalto da un'altra espressione spesso associata a questo genere di programmi: open source. In realtà, tale denominazione implica molto più della semplice disponibilità dei sorgenti ma, tuttavia, non è immediatamente sovrapponibile a quanto si è detto finora a proposito di SL.

Le origini dell'open source risalgono a quando nel 1998 Bruce Perens, Eric Raymond e altre personalità allora attive nel mondo del SL diedero vita all'Open Source Initiative (OSI). L'obiettivo di una simile iniziativa era lanciare una campagna di promozione che puntasse sui vantaggi pratici derivanti dall'adozione del software libero piuttosto che di software proprietario evitando di proposito qualsiasi riferimento ideologico o ‘politico’ ai principi di libertà, potenzialmente compromettenti, al fine di attrarre l'interesse di investitori in ambito aziendale.

Il documento che chiarisce il concetto di open source è la Open Source Definition articolata in dieci punti e redatta da Bruce Perens sulla base delle Linee Guida Debian per il Software Libero (DFSG), facenti parte del Contratto Sociale Debian approvato nel 1997.12

Anche in questo caso, la disponibilità del codice sorgente messa in evidenza dall'espressione ‘open source’ non è in realtà che uno solo dei requisiti perché sia possibile applicare tale etichetta. Affinché un programma possa essere considerato conforme alla definizione, è necessario che venga rispettata una serie di condizioni. Per citarne solo alcune, il software deve inoltre essere utilizzabile senza discriminazione nei confronti di persone o gruppi di persone né limitatamente a determinati campi di impiego, deve esserne consentita la libera distribuzione, il codice sorgente deve essere distribuito o, in alternativa, deve essere indicato il modo per ottenerlo e devono essere permesse le modifiche nonché la creazione di lavori derivati.13

Sebbene in questo emergano delle somiglianze con la definizione di SL, vanno evidenziate delle differenze altrettanto importanti. Nella definizione di open source non compaiono riferimenti di natura etica o di principio: si tratta di una posizione deliberatamente neutrale verso le potenziali implicazioni politiche o ideologiche del SL, al punto che nell'espressione ‘open source’ non compare alcun riferimento all'idea di libertà.

Secondo la OSI, il modello di sviluppo open source è preferibile rispetto al software proprietario perché quest'ultimo è in grado di assicurare vantaggi come l'indipendenza dai fornitori, la flessibilità e la facilità di adattamento, nonché la conformità agli standard.

Uno dei maggiori punti di forza dell'open source è costituito, inoltre, dalla sicurezza e dall'affidabilità, dal momento che l'accesso al codice sorgente permette a chiunque lo desideri di studiarne il funzionamento e correggere eventuali bug, principio che corrisponde alla cosiddetta ‘legge di Linus’: «given enough eyes all bugs are shallow»14 [Raymond, 1997, s.p.]. È evidente che ciò sarebbe impossibile laddove il codice sorgente fosse mantenuto ‘segreto’ come avviene nel caso del software proprietario.

Riassumendo, i sostenitori dell'open source, con un approccio più pragmatico, puntano alla qualità come fine ultimo ritenendo la libertà come un mezzo, mentre gli attivisti del SL considerano la libertà come fine ultimo da perseguire a ogni costo vedendo la qualità solo come una ricaduta (per quanto auspicabile) ma senza mai sacrificare per questo la propria libertà. I due movimenti differiscono quindi per le priorità e per l'atteggiamento adottato nei confronti del software proprietario (inefficiente per i primi, ‘immorale’ per i secondi), tuttavia si tratta di differenze di natura più teorica che pratica.

L'una e l'altra visione portano nella maggioranza dei casi al medesimo comportamento, ad esempio, contribuire allo sviluppo dello stesso software [Stallman, 2007]. Nella quasi totalità dei casi, inoltre, le licenze approvate dalla FSF sono le stesse approvate anche dalla OSI. Per questo motivo non è infrequente imbattersi nell'acronimo inglese F/OSS(Free and Open Source Software) o anche FLOSS (Free/Libre/Open Source Software)15 nei casi in cui si voglia evitare di prendere posizione fra i due movimenti.

Con tutta la consapevolezza del peso che ha la scelta di un termine piuttosto che un altro, maturata attraverso i miei studi di traduzione, in questo lavoro ho scelto di adottare sempre (ove possibile) l'espressione ‘software libero’ con tutte le implicazioni del caso.