Introduzione Un esperimento globale per l'affermazione della libertà

Transcript

1 Copyright per l'edizione italiana 2003 StampaAlternativa/Nuovi Equilibri per accordi con la Free Software Foundation. Si consente la copia letterale e la distribuzione di uno o di tutti gli articoli di questo libro, nella loro integrità, a condizione che su ogni copia sia mantenuta la citazione del copyright e questa nota. 1

2 Introduzione Un esperimento globale per l'affermazione della libertà Offrire al mondo programmi informatici che possano essere liberamente usati e copiati, modificati e distribuiti, gratis o a pagamento. Questa la scommessa lanciata nell'ormai lontano 1984 da Richard Matthew Stallman. Qualcosa (apparentemente) impossibile perfino a concepirsi, in un epoca in cui informatica era (ed è) sinonimo di monopoli, produzioni industriali, megacoporation. Un approccio tanto semplice quanto rivoluzionario, il concetto stesso di software libero, che ci riporta finalmente con i piedi per terra. E la cui pratica quotidiana è ispirata ad un principio anch'esso basilare ma troppo spesso dimenticato: la libera condivisione del sapere, qui e ora, la necessità di (ri)prendere in mano la libertà individuale di creare, copiare, modificare e distribuire qualsiasi prodotto dell'ingegno umano. Ponendo così le condizioni per un ribaltamento totale proprio di quell'apparato pantagruelico che ha piegato l'attuale ambito informatico alla merce' di un pugno di colossi, inarrivabili e monopolistici. Nella rapida trasformazione degli equilibri in gioco nell'odierna rivoluzione tecnologica e industriale, il software libero va dunque scardinando certezze antiche aprendo al contempo le porte a scenari del tutto nuovi e inimmaginabili. Senza affatto escluderne i riflessi nel mondo della piccola e grande imprenditoria e a livello commerciale: basti ricordare l'ampio utilizzo del sistema operativo GNU/Linux (spesso indicato, in maniera imprecisa, solo come 'Linux') sia su macchine high-end come pure su quelle più economiche e dispositivi portatili vari, mentre il 70 per cento dei server web su internet girano su Apache, programma di software libero. Considerando insomma la centralità assunta dal software in quanto comparto industriale strategico all'interno di una poliedrica età dell'informazione, c'è da scommettere che la rivoluzione innescata da Richard Stallman continuerà a produrre un'onda assai lunga negli anni e nei decenni di là da venire. Predisposto all'isolamento sociale ed emotivo, fin da ragazzo Stallman dimostra un'acuta intelligenza unita ad una sviscerata attrazione per le discipline scientifiche. Laureatosi in fisica ad Harvard nel 1974, alla carriera di accademico frustrato preferisce l'ambiente creativo degli hacker che danno vita al laboratorio di intelligenza artificiale presso il prestigioso MIT (Massachusetts Institute of Technology) di Boston. Si tuffa così nella cultura hacker di quegli anni, imparando i linguaggi di programmazione e lo sviluppo dei sistemi operativi. E' qui che, poco più che ventenne, scrive il primo text editor estendibile, Emacs. Ma soprattutto abbraccia lo stile di vita anti-burocratico, creativo e insofferente di ogni autorità costituita, tipico della prima generazione di computer hacker al MIT. Nei primi anni '60 si deve a costoro, ad esempio, la nascita di Spacewar, il primo video game interattivo, che includeva tutte le caratteristiche dell'hacking tradizionale: divertente e casuale, perfetto per la distrazione serale di decine di hacker, dava però concretezza alle capacità di innovazione nell'ambito della programmazione. Ovviamente, era del tutto libero (e gratuito), di modo che il relativo codice venne ampiamente condiviso con altri programmatori. Pur se non sempre queste posizioni di apertura e condivisione erano parimenti apprezzate da hacker e ricercatori "ufficiali", nella rapida evoluzione del settore informatico i due tipi di programmatori finirono per impostare un rapporto basato sulla collaborazione, una sorta di una relazione simbiotica. La generazione successiva, cui apparteneva Richard Stallman, aspirava a calcare le orme di quei primi hacker, particolarmente a livello etico. Onde potersi definire tale, all'hacker era richiesto qualcosa in più che scrivere programmi interessanti; doveva far parte dell'omonima cultura e onorarne le tradizioni in maniera analoga alle corporazioni medievali, pur se con una struttura sociale non così rigida. Scenario che prese corpo in istituzioni accademiche d'avanguardia, quali MIT, Stanford e Carnegie Mellon, emanando al contempo quelle norme non ancora scritte che governavano i comportamenti dell'hacker -- l'etica hacker. Proprio per garantire massima consistenza e aderenza a tale etica, dopo non poche vicissitudini, all'inizio del 1984 Stallman lascia il MIT per dedicarsi anima e corpo al lancio del progetto GNU e della successiva Free Software Foundation. Come scrive Sam Williams nella biografia 'ufficiosa' di Stallman (Codice Libero, Apogeo, 2003), il "passaggio di Richard Matthew Stallman da accademico frustrato a leader politico nel corso degli ultimi vent'anni, testimonia della sua natura testarda e della volontà prodigiosa, di una visione ben articolata sui valori di quel movimento per il software libero che ha aiutato a costruire." A ciò va aggiunta l'alta qualità dei programmi da lui realizzati man mano, "programmi che ne hanno cementato la reputazione come sviluppatore leggendario." Un attivismo spietato, il suo, sempre al servizio della libertà di programmazione, di parola, di pensiero. Non certo casualmente alla domanda se, di fronte alla quasi-egemonia del software proprietario, oggi il movimento del software libero rischi di perdere la capacità di stare al passo con i più recenti sviluppi tecnologici, Stallman non ha dubbi: "Credo che la libertà sia più importante del puro avanzamento tecnico. Sceglierei sempre un programma libero meno aggiornato piuttosto che uno non-libero più recente, perché non voglio rinunciare alla libertà personale. La mia regola è, se non posso condividerlo, allora non lo uso." Questo in estrema sintesi il percorso seguito finora dall'ideatore del movimento del software libero, rimandando ulteriori approfondimenti alle risorse segnalate in appendice. Ma per quanti hanno scarsa familiarità con simili dinamiche e con lo 2

3 Stallman-pensiero, oppure per chi vuole esplorare tematiche più ampie, questa collezione di saggi è certamente l'ideale. Primo, perché copre vent'anni di interventi pubblici da parte di colui che viene (giustamente) considerato il "profeta" del software libero. Secondo, perché nella raccolta vengono sottolineati gli aspetti sociali dell'attività di programmazione, chiarendo come tale attività possa creare davvero comunità e giustizia. Terzo, perché nel panorama dell'informazione odierna spesso fin troppo rapida e generica, ancor più in ambito informatico, è vitale tenersi correttamente aggiornati su faccende calde, tipo le crescenti potenzialità del copyleft (noto anche come "permesso d'autore") oppure i pericoli dei brevetti sul software. La raccolta riporta inoltre una serie di documenti storici cruciali: il "Manifesto GNU" datato 1984 (leggermente rivisto per l'occasione), la definizione di software libero, la spiegazione del motivo per cui sia meglio usare la definizione 'software libero' anziché 'open source'. Il tutto mirando ad un pubblico il più vasto possibile: "non occorre avere un background in computer science per comprendere la filosofia e le idee qui esposte," come recita infatti la nota introduttiva del libro originale -- Free Software, Free Society: Selected Essays of Richard M. Stallman. L'edizione italiana di quest'ultima è stata scomposta in due distinti volumi: quello che avete per le mani, dove sono raccolte le prime due sezioni della versione inglese, verrà seguito a breve da un secondo con i testi rimanenti. Tra questi, vanno fin d'ora segnalate le trascrizioni di alcuni importanti interventi dal vivo di Stallman (quali "Copyright e globalizzazione nell'epoca delle reti informatiche" e "Software libero: libertà e cooperazione"), oltre al testo integrale delle varie licenze GNU, a partire dalla più affermata, la GPL, General Public License. Si è optato per due volumi italiani onde rendere più agile e godibile l'intera opera originale, considerando lo spessore e la complessità spesso presenti nei vari saggi. Presi nella loro interezza, questi forniranno al lettore un quadro ampio e articolato su questioni pressanti, non soltanto per l'odierno ambito informatico. Proprio perché Stallman non si risparmia affatto, gettando luce sul passato e soprattutto sul futuro di tematiche al crocevia tra etica e legge, business e software, libertà individuale e società trasparente. Senza infine dimenticare come a complemento del tutto sia già attivo un'apposita area sul sito web di Stampa Alternativa ( dove circolano interventi vari in tema di software libero e dove troverà spazio l'intera versione italiana del libro. Oltre naturalmente alle relative modifiche, ovvero le segnalazioni di lettori e utenti riguardo errori, contributi, aggiornamenti e quant'altro possibile. Il materiale qui raccolto sarà ulteriormente disponibile sul sito dell'associazione Software Libero, il quale ospita il gruppo dei traduttori italiani dei testi del progetto GNU ( che ha validamente contributo alla stesura di questo lavoro. Un lavoro, va detto nel caso qualcuno avesse ancora dei dubbi, portato avanti interamente via internet tra i vari soggetti coinvolti, dalla fase di progettazione a quella di consegna dei materiali definitivi, e ricorrendo al software non proprietario per quanto possibile. Un progetto in evoluzione continua, quindi, in sintonia con le pratica di massima apertura e condivisione su cui vive e prospera il movimento del software libero a livello globale -- espressione concreta di un'esperimento teso all'affermazione della libertà di tutti e di ciascuno. Bernardo Parrella berny@cybermesa.com marzo La copia letterale e la distribuzione di questo testo nella sua integrità sono permesse con qualsiasi mezzo, a condizione che sia mantenuta questa nota

4 PARTE PRIMA: Il progetto GNU e il software libero Il progetto GNU (The GNU Project: Il progetto GNU: La prima comunità di condivisione del software Quando cominciai a lavorare nel laboratorio di Intelligenza Artificiale del MIT [Massachusetts Institute of Technology] nel 1971, entrai a far parte di una comunità in cui ci si scambiavano i programmi, che esisteva già da molti anni. La condivisione del software non si limitava alla nostra comunità; è un cosa vecchia quanto i computer, proprio come condividere le ricette è antico come l'arte culinaria. Ma noi lo facevamo più di quasi chiunque altro. Il laboratorio di Intelligenza Artificiale usava un sistema operativo a partizione di tempo (timesharing) chiamato ITS (Incompatible Timesharing System) che il gruppo di hacker del laboratorio aveva progettato e scritto in linguaggio assembler per il Digital PDP-10, uno dei grossi elaboratori di quel periodo. Come membro di questa comunità, hacker di sistema nel gruppo laboratorio, il mio compito era quello di migliorare il sistema. Non chiamavamo il nostro software "software libero", poiché questa espressione ancora non esisteva, ma proprio di questo si trattava. Ogni volta che persone di altre università o aziende volevano convertire il nostro programma per adattarlo al proprio sistema ed utilizzarlo, gliene davamo volentieri il permesso. Se si notava qualcuno usare un programma sconosciuto ed interessante, gli si poteva sempre chiedere di vederne il codice sorgente, in modo da poterlo leggere, modificare, o cannibalizzarne alcune parti per creare un nuovo programma. L'uso del termine "hacker" per indicare qualcuno che "infrange i sistemi di sicurezza" è una confusione creata dai mezzi di informazione. Noi hacker ci rifiutiamo di riconoscere questo significato, e continuiamo ad utilizzare il termine nel senso di "uno che ama programmare, e a cui piace essere bravo a farlo". [1] La comunità si dissolve La situazione cambiò drasticamente all'inizio degli anni '80, con la dissoluzione della comunità hacker del laboratorio d'intelligenza Artificiale seguita dalla decisione della Digital di cessare la produzione del computer PDP-10. Nel 1981 la Symbolics, nata da una costola del laboratorio stesso, gli aveva sottratto quasi tutti gli hacker e l'esiguo gruppo rimasto fu incapace di sostenersi (il libro "Hackers" di Steve Levy narra questi eventi, oltre a fornire una fedele ricostruzione della comunità ai suoi albori). Quando nel 1982 il laboratorio di Intelligenza Artificiale acquistò un nuovo PDP-10, i sistemisti decisero di utilizzare il sistema timesharing non libero della Digital piuttosto che ITS. Poco tempo dopo la Digital decise di cessare la produzione della serie PDP-10. La sua architettura, elegante e potente negli anni '60, non poteva essere estesa in modo naturale ai maggiori spazi di intervento che andavano materializzandosi negli anni '80. Questo stava a significare che quasi tutti i programmi che formavano ITS divennero obsoleti. Ciò rappresentò l'ultimo chiodo conficcato nella bara di ITS; 15 anni di lavoro andati in fumo. I moderni elaboratori di quell'epoca, come il VAX o il 68020, avevano il proprio sistema operativo, ma nessuno di questi era libero: si doveva firmare un accordo di non-diffusione persino per ottenerne una copia eseguibile. Questo significava che il primo passo per usare un computer era promettere di negare aiuto al proprio vicino. Una comunità cooperante era vietata. La regola creata dai proprietari di software proprietario era: «se condividi il software col tuo vicino sei un pirata. Se vuoi modifiche, pregaci di farle». L'idea che la concezione sociale di software proprietario -- cioè il sistema che impone che il software non possa essere condiviso o modificato -- sia antisociale, contraria all'etica, semplicemente sbagliata, può apparire sorprendente a qualche lettore. Ma che altro possiamo dire di un sistema che si basa sul dividere utenti e lasciarli senza aiuto? Quei lettori che trovano sorprendente l'idea possono aver data per scontata la concezione sociale di software proprietario, o averla giudicata utilizzando lo stesso metro suggerito dal mercato del software proprietario. I produttori di software hanno lavorato a lungo e attivamente per diffondere la convinzione che c'è un solo modo di vedere la cosa. Quando i produttori di software parlano di "difendere" i propri "diritti" o di "fermare la pirateria", quello che dicono è in realtà 4

5 secondario. Il vero messaggio in quelle affermazioni sta nelle assunzioni inespresse, che essi danno per scontate; vogliono che siano accettate acriticamente. Esaminiamole, dunque. Un primo assunto è che le aziende produttrici di software abbiano il diritto naturale indiscutibile di proprietà sul software, e di conseguenza, abbiano controllo su tutti i suoi utenti. Se questo fosse un diritto naturale, non potremmo sollevare obiezioni, indipendentemente dal danno che possa recare ad altri. È interessante notare che, negli Stati Uniti, sia la costituzione che la giurisprudenza rifiutano questa posizione: il diritto d'autore non è un diritto naturale, ma un monopolio imposto dal governo che limita il diritto naturale degli utenti ad effettuare delle copie. Un'altra assunzione inespressa è che la sola cosa importante del software sia il lavoro che consente di fare -- vale a dire che noi utenti non dobbiamo preoccuparci del tipo di società in cui ci è permesso vivere. Un terzo assunto è che non avremmo software utilizzabile (o meglio, che non potremmo mai avere un programma per fare questo o quell'altro particolare lavoro) se non riconoscessimo ai produttori il controllo sugli utenti di quel programmi. Quest'assunzione avrebbe potuto sembrare plausibile, prima che il movimento del software libero dimostrasse che possiamo scrivere quantità di programmi utili senza bisogno di metterci dei catenacci. Se rifiutiamo di accettare queste assunzioni, giudicando queste questioni con comuni criteri di moralità e di buon senso dopo aver messo al primo posto gli interessi degli utenti, tenendo conto che gli utenti vengono prima di tutto, arriviamo a conclusioni del tutto differenti. Chi usa un calcolatore dovrebbe essere libero di modificare i programmi per adattarli alle proprie necessità, ed essere libero di condividere il software, poiché aiutare gli altri è alla base della società. Una difficile scelta morale Una volta che il mio gruppo si fu sciolto, continuare come prima fu impossibile. Mi trovai di fronte ad una difficile scelta morale. La scelta facile sarebbe stata quella di unirsi al mondo del software proprietario, firmando accordi di non diffusione e promettendo di non aiutare i miei compagni hacker. Con ogni probabilità avrei anche sviluppato software che sarebbe stato distribuito secondo accordi di non-diffusione, contribuendo così alla pressione su altri perché a loro volta tradissero i propri compagni. In questo modo avrei potuto guadagnare, e forse mi sarei divertito a programmare. Ma sapevo che al termine della mia carriera mi sarei voltato a guardare indietro, avrei visto anni spesi a costruire muri per dividere le persone, e avrei compreso di aver contribuito a rendere il mondo peggiore. Avevo già sperimentato cosa significasse un accordo di non diffusione per chi lo firmava, quando qualcuno rifiutò a me e al laboratorio d'intelligenza Artificiale del MIT il codice sorgente del programma di controllo della nostra stampante. (L'assenza di alcune funzionalità nel programma rendeva oltremodo frustrante l'uso della stampante). Per cui non mi potevo dire che gli accordi di non-diffusione fossero innocenti. Ero molto arrabbiato quando quella persone si rifiutò di condividere il programma con noi; non potevo far finta di niente e fare lo stesso con tutti gli altri. Un'altra possibile scelta, semplice ma spiacevole, sarebbe stata quella di abbandonare l'informatica. In tal modo le mie capacità non sarebbero state mal utilizzate, tuttavia sarebbero state sprecate. Non sarei mai stato colpevole di dividere o imporre restrizioni agli utenti di calcolatori, ma queste cose sarebbero comunque successe. Allora cercai un modo in cui un programmatore potesse fare qualcosa di buono. Mi chiesi dunque: c'erano un programma o dei programmi che io potessi scrivere, per rendere nuovamente possibile l'esistenza di una comunità? La risposta era semplice: innanzitutto serviva un sistema operativo. Questo è difatti il software fondamentale per iniziare ad usare un computer. Con un sistema operativo si possono fare molte cose; senza, non è proprio possibile far funzionare il computer. Con un sistema operativo libero, avremmo potuto avere nuovamente una comunità in cui hacker possono cooperare, e invitare chiunque ad unirsi al gruppo. E chiunque sarebbe stato in grado di usare un calcolatore, senza dover cospirare fin dall'inizio per sottrarre qualcosa ai propri amici. Essendo un programmatore di sistemi, possedevo le competenze adeguate per questo lavoro. Così, anche se non davo il successo per scontato, mi resi conto di essere la persona giusta per farlo. Scelsi di rendere il sistema compatibile con Unix, in modo che fosse portabile, e che gli utenti Unix potessero passare facilmente ad esso. Il nome GNU fu scelto secondo una tradizione hacker, come acronimo ricorsivo che significa "GNU's Not Unix" [GNU non è Unix]. Un sistema operativo non si limita solo al suo nucleo, che è proprio il minimo per eseguire altri programmi. Negli anni '70, qualsiasi sistema operativo degno di questo nome includeva interpreti di comandi, assemblatori, compilatori, interpreti di 5

6 linguaggi, debugger, editor di testo, programmi per la posta e molto altro. ITS li aveva, Multics li aveva, VMS li aveva e Unix li aveva. Anche il sistema operativo GNU li avrebbe avuti. Tempo dopo venni a conoscenza di questa massima, attribuita al sapiente ebraico Hillel: Se non sono per me stesso, chi sarà per me? E se sono solo per me stesso, che cosa sono? E se non ora, quando? La decisione di iniziare il progetto GNU si basò su uno spirito simile. Essendo ateo, non seguo alcuna guida religiosa, ma a volte mi trovo ad ammirare qualcosa che qualcuno di loro ha detto. "Free" come libero Il termine "free software" [il termine 'free' in inglese significa sia gratuito che libero] a volte è mal interpretato: non ha niente a che vedere col prezzo del software; si tratta di libertà. Ecco, dunque, la definizione di software libero: un programma è software libero per un dato utente se: * l'utente ha la libertà di eseguire il programma per qualsiasi scopo; * l'utente ha la libertà di modificare il programma secondo i propri bisogni (perché questa libertà abbia qualche effetto in pratica, è necessario avere accesso al codice sorgente del programma, poiché apportare modifiche ad un programma senza disporre del codice sorgente è estremamente difficile); * l'utente ha la libertà di distribuire copie del programma, gratuitamente o dietro compenso; * l'utente ha la libertà di distribuire versioni modificate del programma, così che la comunità possa fruire dei miglioramenti apportati. Poiché "free" si riferisce alla libertà e non al prezzo, vendere copie di un programma non contraddice il concetto di software libero. In effetti, la libertà di vendere copie di programmi è essenziale: raccolte di software libero vendute su CD-ROM sono importanti per la comunità, e la loro vendita è un modo di raccogliere fondi importante per lo sviluppo del software libero. Di conseguenza, un programma che non può essere liberamente incluso in tali raccolte non è software libero. A causa dell'ambiguità del termine "free", si è cercata a lungo un'alternativa, ma nessuno ne ha trovata una valida. La lingua inglese ha, più termini e sfumature di ogni altra, ma non ha una parola semplice e non ambigua che significhi libero; "unfettered" è la parola più vicina come significato [unfettered è una parola di tono aulico o arcaico che significa libero da ceppi, vincoli o inibizioni]. Alternative come "liberated", "freedom" e "open" hanno altri significati o non sono adatte per altri motivi [rispettivamente, liberato, libertà, aperto]. Software GNU e il sistema GNU Sviluppare un intero sistema è un progetto considerevole. Per raggiungere l'obiettivo decisi di adattare e usare parti di software libero tutte le volte che fosse possibile. Per esempio, decisi fin dall'inizio di usare TeX come il principale programma di formattazione di testo; qualche anno più tardi, decisi di usare l'x Window System piuttosto che scrivere un altro sistema a finestre per GNU. A causa di questa decisione, il sistema GNU e la raccolta di tutto il software GNU non sono la stessa cosa. Il sistema GNU comprende programmi che non sono GNU, sviluppati da altre persone o gruppi di progetto per i propri scopi, ma che possiamo usare in quanto software libero. L'inizio del progetto Nel gennaio 1984 lasciai il mio posto al MIT e cominciai a scrivere software GNU. Dovetti lasciare il MIT, per evitare che potesse interferire con la distribuzione di GNU come software libero. Se fossi rimasto, il MIT avrebbe potuto rivendicare la proprietà del lavoro, ed avrebbe potuto imporre i propri termini di distribuzione, o anche farne un pacchetto proprietario. Non avevo alcuna intenzione di fare tanto lavoro solo per vederlo reso inutilizzabile per il suo scopo originario: creare una nuova comunità di condivisione di software. Ad ogni buon conto, il professor Winston -- allora responsabile del laboratorio d'intelligenza Artificiale del MIT -- mi propose gentilmente di continuare ad utilizzare le attrezzature del laboratorio stesso. I primi passi Poco dopo aver iniziato il progetto GNU, venni a sapere del Free University Compiler Kit, noto anche come VUCK (la 6

7 parola olandese che sta per "free" inizia con la V, "vrij"). Era un compilatore progettato per trattare più linguaggi, fra cui C e Pascal, e per generare codice binario per diverse architetture. Scrissi al suo autore chiedendo se GNU avesse potuto usarlo. Rispose in modo canzonatorio, dicendo che l'università era sì libera, ma non il compilatore. Decisi allora che il mio primo programma per il progetto GNU sarebbe stato un compilatore multilinguaggio e multipiattaforma. Sperando di evitare di dover scrivere da me l'intero compilatore, ottenni il codice sorgente del Pastel, un compilatore multipiattaforma sviluppato ai Laboratori Lawrence Livermore. Il linguaggio supportato da Pastel, in cui il Pastel stesso era scritto, era una versione estesa del Pascal, pensata come linguaggio di programmazione di sistemi. Io vi aggiunsi un frontend per il C, e cominciai il porting per il processore Motorola 68000, ma fui costretto a rinunciare quando scoprii che il compilatore richiedeva diversi megabyte di memoria sullo stack, mentre il sistema Unix disponibile per il processore ne permetteva solo 64K. Mi resi conto allora che il compilatore Pastel interpretava tutto il file di ingresso creandone un albero sintattico, convertiva questo in una catena di "istruzioni", e quindi generava l'intero file di uscita senza mai liberare memoria. A questo punto, conclusi che avrei dovuto scrivere un nuovo compilatore da zero. Quel nuovo compilatore è ora noto come Gcc; non utilizza niente del compilatore Pastel, ma riuscii ad adattare e riutilizzare il frontend per il C che avevo scritto. Questo però avvenne qualche anno dopo; prima, lavorai su GNU Emacs. GNU Emacs Cominciai a lavorare su GNU Emacs nel settembre 1984, e all'inizio del 1985 cominciava ad essere utilizzabile. Così potei iniziare ad usare sistemi Unix per scrivere; fino ad allora, avevo scritto sempre su altri tipi di macchine, non avendo nessun interesse ad imparare vi né ed. A questo punto alcuni cominciarono a voler usare GNU Emacs, il che pose il problema di come distribuirlo. Naturalmente lo misi sul server ftp anonimo del computer che usavo al MIT (questo computer, prep.ai.mit.edu, divenne così il sito ftp primario di distribuzione di GNU; quando alcuni anni dopo andò fuori servizio, trasferimmo il nome sul nostro nuovo ftp server). Ma allora molte delle persone interessate non erano su Internet e non potevano ottenere una copia via ftp, così mi si pose il problema di cosa dir loro. Avrei potuto dire: «trova un amico che è in rete disposto a farti una copia». Oppure avrei potuto fare quel che feci con l'originario Emacs su PDP-10, e cioè dir loro: «spediscimi una busta affrancata ed un nastro, ed io te lo rispedisco con sopra Emacs». Ma ero senza lavoro, e cercavo un modo di far soldi con il software libero. E così feci sapere che avrei spedito un nastro a chi lo voleva per 150 dollari. In questo modo, creai un'impresa di distribuzione di software libero, che anticipava le compagnie che oggi distribuiscono interi sistemi GNU basati su Linux. Un programma è libero per tutti? Se un programma è software libero quando esce dalle mani del suo autore, non significa necessariamente che sarà software libero per chiunque ne abbia una copia. Per esempio, il software di pubblico dominio (software senza copyright) è software libero, ma chiunque può farne una versione modificata proprietaria. Analogamente, molti programmi liberi sono protetti da diritto d'autore, ma vengono distribuiti con semplici licenze permissive che permettono di farne versioni modificate proprietarie. L'esempio emblematico della questione è l'x Window System. Sviluppato al MIT, e pubblicato come software libero con una licenza permissiva, fu rapidamente adottato da diverse società informatiche. Queste aggiunsero X ai loro sistemi Unix proprietari, solo in forma binaria, e coperto dello stesso accordo di non diffusione. Queste copie di X non erano software più libero di quanto lo fosse Unix. Gli autori dell'x Window System non ritenevano che questo fosse un problema, anzi se lo aspettavano ed era loro intenzione che accadesse. Il loro scopo non era la libertà, ma semplicemente il "successo", definito come "avere tanti utenti". Non erano interessati che questi utenti fossero liberi, ma solo che fossero numerosi. Questo sfociò in una situazione paradossale, in cui due modi diversi di misurare la quantità di libertà risultavano in risposte diverse alla domanda «questo programma è libero»? Giudicando sulla base della libertà offerta dai termini distributivi usati dal MIT, si sarebbe dovuto dire che X era software libero. Ma misurando la libertà dell'utente medio di X, si sarebbe dovuto dire che X era software proprietario. La maggior parte degli utenti di X usavano le versioni proprietarie fornite con i sistemi Unix, non la versione libera. 7

8 Il permesso d'autore (copyleft) e la GNU GPL Lo scopo di GNU consisteva nell'offrire libertà agli utenti, non solo nell'ottenere ampia diffusione. Avevamo quindi bisogno di termini di distribuzione che evitassero che il software GNU fosse trasformato in software proprietario. Il metodo che usammo si chiama copyleft. Il permesso d'autore (copyleft) usa le leggi sul diritto d'autore (copyright), ma le capovolge per ottenere lo scopo opposto: invece che un metodo per privatizzare il software, diventa infatti un mezzo per mantenerlo libero. Il succo dell'idea di permesso d'autore consiste nel dare a chiunque il permesso di eseguire il programma, copiare il programma, modificare il programma, e distribuirne versioni modificate, ma senza dare il permesso di aggiungere restrizioni. In tal modo, le libertà essenziali che definiscono il "free software" (software libero) sono garantite a chiunque ne abbia una copia, e diventano diritti inalienabili. Perché un permesso d'autore sia efficace, anche le versioni modificate devono essere libere. Ciò assicura che ogni lavoro basato sul nostro sia reso disponibile per la nostra comunità, se pubblicato. Quando dei programmatori professionisti lavorano su software GNU come volontari, è il permesso d'autore che impedisce ai loro datori di lavoro di dire: «non puoi distribuire quei cambiamenti, perché abbiamo intenzione di usarli per creare la nostra versione proprietaria del programma». La clausola che i cambiamenti debbano essere liberi è essenziale se vogliamo garantire libertà a tutti gli utenti del programma. Le aziende che privatizzarono l'x Window System di solito avevano apportato qualche modifica per portare il programma sui loro sistemi e sulle loro macchine. Si trattava di modifiche piccole rispetto alla mole di X, ma non banali. Se apportare modifiche fosse una scusa per negare libertà agli utenti, sarebbe facile per chiunque approfittare di questa scusa. Una problematica correlata è quella della combinazione di un programma libero con codice non libero. Una tale combinazione sarebbe inevitabilmente non libera; ogni libertà che manchi dalla parte non libera mancherebbe anche dall'intero programma. Permettere tali combinazioni aprirebbe non uno spiraglio, ma un buco grosso come una casa. Quindi un requisito essenziale per il permesso d'autore è tappare il buco: tutto ciò che venga aggiunto o combinato con un programma protetto da permesso d'autore dev'essere tale che il programma risultante sia anch'esso libero e protetto da permesso d'autore. La specifica implementazione di permesso d'autore che utilizziamo per la maggior parte del software GNU è la GNU General Public License (licenza pubblica generica GNU), abbreviata in GNU GPL. Abbiamo altri tipi di permesso d'autore che sono utilizzati in circostanze specifiche. I manuali GNU sono anch'essi protetti da permesso d'autore, ma ne usano una versione molto più semplice, perché per i manuali non è necessaria la complessità della GPL. Nel 1984 o 1985, Don Hopkins, persona molto creativa, mi mandò una lettera. Sulla busta aveva scritto diverse frasi argute, fra cui questa: "Permesso d'autore--tutti i diritti rovesciati". Utilizzai l'espressione "permesso d'autore" [copyleft] per battezzare il concetto di distribuzione che allora andavo elaborando. La Free Software Foundation Man mano che l'interesse per Emacs aumentava, altre persone parteciparono al progetto GNU, e decidemmo che era di nuovo ora di cercare finanziamenti. Così nel 1985 fondammo la Free Software Foundation (FSF), una organizzazione senza fini di lucro per lo sviluppo di software libero. La FSF fra l'altro si prese carico della distribuzione dei nastri di Emacs; più tardi estese l'attività aggiungendo sul nastro altro software libero (sia GNU che non GNU) e vendendo manuali liberi. La FSF accetta donazioni, ma gran parte delle sue entrate è sempre stata costituita dalle vendite: copie di software libero e servizi correlati. Oggi vende CD-ROM di codice sorgente, CD-ROM di programmi compilati, manuali stampati professionalmente (tutti con libertà di ridistribuzione e modifica), e distribuzioni Deluxe (nelle quali compiliamo l'intera scelta di software per una piattaforma a richiesta). I dipendenti della Free Software Foundation hanno scritto e curato la manutenzione di diversi pacchetti GNU. Fra questi spiccano la libreria C e la shell. La libreria C di GNU è utilizzata da ogni programma che gira su sistemi GNU/Linux per comunicare con Linux. È stata sviluppata da un membro della squadra della Free Software Foundation, Roland McGrath. La shell usata sulla maggior parte dei sistemi GNU/Linux è Bash, la Bourne Again Shell, che è stata sviluppata da Brian Fox, dipendente della FSF. Finanziammo lo sviluppo di questi programmi perché il progetto GNU non riguardava solo strumenti di lavoro o un 8

9 ambiente di sviluppo: il nostro obiettivo era un sistema operativo completo, e questi programmi erano necessari per raggiungere quell'obiettivo. ["Bourne Again Shell" è un gioco di parole sul nome "Bourne Shell", che era la normale shell di Unix; "Bourne again" richiama l'espressione cristiana "born again", "rinato" (in Cristo)]. Il supporto per il software libero La filosofia del software libero rigetta una diffusa pratica commerciale in particolare, ma non è contro il commercio. Quando un'impresa rispetta la libertà dell'utente, c'è da augurarle ogni successo. La vendita di copie di Emacs esemplifica un modo di condurre affari col software libero. Quando la FSF prese in carico quest'attività, dovetti trovare un'altra fonte di sostentamento. La trovai nella vendita di servizi relativi al software libero che avevo sviluppato, come insegnare argomenti quali programmazione di Emacs e personalizzazione di GCC, oppure sviluppare software, soprattutto adattamento di GCC a nuove architetture. Oggi tutte queste attività collegate al software libero sono esercitate da svariate aziende. Alcune distribuiscono raccolte di software libero su CD-ROM, altre offrono consulenza a diversi livelli, dall'aiutare gli utenti in difficoltà, alla correzione di errori, all'aggiunta di funzionalità non banali. Si cominciano anche a vedere aziende di software che si fondano sul lancio di nuovi programmi liberi. Attenzione, però -- diverse aziende che si fregiano del marchio "open source" (software aperto) in realtà fondano le loro attività su software non libero che funziona insieme con software libero. Queste non sono aziende di software libero, sono aziende di software proprietario i cui prodotti attirano gli utenti lontano dalla libertà. Loro li chiamano "a valore aggiunto", il che riflette i valori che a loro farebbe comodo che adottassimo: la convenienza prima della libertà. Se noi riteniamo che la libertà abbia più valore, li dovremmo chiamare prodotti "a libertà sottratta". Obiettivi tecnici L'obiettivo principale di GNU era essere software libero. Anche se GNU non avesse avuto alcun vantaggio tecnico su Unix, avrebbe avuto sia un vantaggio sociale, permettendo agli utenti di cooperare, sia un vantaggio etico, rispettando la loro libertà. Tuttavia risultò naturale applicare al lavoro le regole classiche di buona programmazione; per esempio, allocare le strutture dati dinamicamente per evitare limitazioni arbitrarie sulla dimensione dei dati, o gestire tutti i possibili codici a 8 bit in tutti i casi ragionevoli. Inoltre, al contrario di Unix che era pensato per piccole dimensioni di memoria, decidemmo di non supportare le macchine a 16 bit (era chiaro che le macchine a 32 bit sarebbero state la norma quando il sistema GNU sarebbe stato completo), e di non preoccuparci di ridurre l'occupazione di memoria a meno che eccedesse il megabyte. In programmi per i quali non era essenziale la gestione di file molto grandi, spingemmo i programmatori a leggere in memoria l'intero file di ingresso per poi analizzare il file senza doversi preoccupare delle operazioni di I/O. Queste decisioni fecero sì che molti programmi GNU superassero i loro equivalenti Unix sia in affidabilità che in velocità di esecuzione. Donazioni di computer Man mano che la reputazione del progetto GNU andava crescendo, alcune persone iniziarono a donare macchine su cui girava Unix. Queste macchine erano molto utili, perché il modo più semplice di sviluppare componenti per GNU era di farlo su di un sistema Unix così da sostituire pezzo per pezzo i componenti di quel sistema. Ma queste macchine sollevavano anche una questione etica: se fosse giusto per noi anche solo possedere una copia di Unix. Unix era (ed è) software proprietario, e la filosofia del progetto GNU diceva che non avremmo dovuto usare software proprietario. Ma, applicando lo stesso ragionamento per cui la violenza è ammessa per autodifesa, conclusi che fosse legittimo usare un pacchetto proprietario, se ciò fosse stato importante nel crearne un sostituto libero che permettesse ad altri di smettere di usare quello proprietario. Tuttavia, benché fosse un male giustificabile, era pur sempre un male. Oggi non abbiamo più alcuna copia di Unix, perché le abbiamo sostituite con sistemi operativi liberi. Quando non fu possibile sostituire il sistema operativo di una macchina con uno libero, sostituimmo la macchina. 9

10 L'elenco dei compiti GNU Mentre il progetto GNU avanzava, ed un numero sempre maggiore di componenti di sistema venivano trovati o sviluppati, diventò utile stilare un elenco delle parti ancora mancanti. Usammo questo elenco per ingaggiare programmatori che scrivessero tali parti, e l'elenco prese il nome di elenco dei compiti GNU. In aggiunta ai componenti Unix mancanti inserimmo nell'elenco svariati progetti utili di programmazione o di documentazione che a nostro parere non dovrebbero mancare in un sistema operativo veramente completo. Oggi non compare quasi nessun componente Unix nell'elenco dei compiti GNU; tutti questi lavori, a parte qualcuno non essenziale, sono già stati svolti. D'altro canto l'elenco è pieno di quei progetti che qualcuno chiamerebbe "applicazioni": ogni programma che interessi ad una fetta non trascurabile di utenti sarebbe un'utile aggiunta ad un sistema operativo. L'elenco comprende anche dei giochi, e così è stato fin dall'inizio: Unix comprendeva dei giochi, perciò era naturale che così fosse anche per GNU. Ma poiché non c'erano esigenze di compatibilità per i giochi, non ci attenemmo alla scelta di giochi presenti in Unix, preferendo piuttosto fornire un elenco di diversi tipi di giochi potenzialmente graditi agli utenti. La licenza GNU per le librerie La libreria C del sistema GNU utilizza un tipo speciale di permesso d'autore, la "Licenza Pubblica GNU per le Librerie", che permette l'uso della libreria da parte di software proprietario. Perché quest'eccezione? Non si tratta di questioni di principio: non c'è nessun principio che dica che i prodotti software proprietari abbiano il diritto di includere il nostro codice (perché contribuire ad un progetto fondato sul rifiuto di condividere con noi?). L'uso della licenza LGPL per la libreria C, o per qualsiasi altra libreria, è una questione di strategia. La libreria C svolge una funzione generica: ogni sistema operativo proprietario ed ogni compilatore includono una libreria C. Di conseguenza, rendere disponibile la nostra libreria C solo per i programmi liberi non avrebbe dato nessun vantaggio a tali programmi liberi, avrebbe solo disincentivato l'uso della nostra libreria. C'è un'eccezione a questa situazione: sul sistema GNU (termine che include GNU/Linux) l'unica libreria C disponibile è quella GNU. Quindi i termini di distribuzione della nostra libreria C determinano se sia possibile o meno compilare un programma proprietario per il sistema GNU. Non ci sono ragioni etiche per permettere l'uso di applicazioni proprietarie sul sistema GNU, ma strategicamente sembra che impedirne l'uso servirebbe più a scoraggiare l'uso del sistema GNU che non a incoraggiare lo sviluppo di applicazioni libere. Ecco perché l'uso della licenza LGPL è una buona scelta strategica per la libreria C, mentre per le altre librerie la strategia va valutata caso per caso. Quando una libreria svolge una funzione particolare che può aiutare a scrivere certi tipi di programmi, distribuirla secondo la GPL, quindi limitandone l'uso ai soli programmi liberi, è un modo per aiutare gli altri autori di software libero, dando loro un vantaggio nei confronti del software proprietario. Prendiamo come esempio GNU Readline [2], una libreria scritta per fornire a Bash la modificabilità della linea di comando: Readline è distribuita secondo la normale licenza GPL, non la LGPL. Ciò probabilmente riduce l'uso di Readline, ma questo non rappresenta una perdita per noi; d'altra parte almeno una applicazione utile è stata resa software libero proprio al fine di usare Readline, e questo è un guadagno tangibile per la comunità. Chi sviluppa software proprietario ha vantaggi economici, gli autori di programmi liberi hanno bisogno di avvantaggiarsi a vicenda. Spero che un giorno possiamo avere una grande raccolta di librerie coperte dalla licenza GPL senza che esista una raccolta equivalente per chi scrive software proprietario. Tale libreria fornirebbe utili moduli da usare come i mattoni per costruire nuovi programmi liberi, e costituendo un sostanziale vantaggio per la scrittura di ulteriori programmi liberi. [Nel 1999 la FSF ha cambiato nome alla licenza LGPL che ora si chiama "Lesser GPL", GPL attenuata, per non suggerire che si tratti della forma di licenza preferenziale per le librerie.] Togliersi il prurito? Eric Raymond afferma che «ogni buon programma nasce dall'iniziativa di un programmatore che si vuole togliere un suo personale prurito». É probabile che talvolta succeda così, ma molte parti essenziali del software GNU sono state sviluppate al fine di completare un sistema operativo libero. Derivano quindi da una idea e da un progetto, non da una necessità contingente. Per esempio, abbiamo sviluppato la libreria C di GNU perché un sistema di tipo Unix ha bisogno di una libreria C, la Bourne-Again Shell (bash) perché un sistema di tipo Unix ha bisogno di una shell, e GNU tar perché un sistema di tipo Unix 10

11 ha bisogno un programma tar. Lo stesso vale per i miei programmi: il compilatore GNU, GNU Emacs, GDB, GNU Make. Alcuni programmi GNU sono stati sviluppati per fronteggiare specifiche minacce alla nostra libertà: ecco perché abbiamo sviluppato gzip come sostituto per il programma Compress, che la comunità aveva perduto a causa dei brevetti sull'algoritmo LZW [3]. Abbiamo trovato persone che sviluppassero LessTif, e più recentemente abbiamo dato vita ai progetti GNOME e Harmony per affrontare i problemi causati da alcune librerie proprietarie (come descritto più avanti). Stiamo sviluppando la GNU Privacy Guard per sostituire i diffusi programmi di crittografia non liberi, perché gli utenti non siano costretti a scegliere tra riservatezza e libertà. Naturalmente, i redattori di questi programmi sono coinvolti nel loro lavoro, e varie persone vi hanno aggiunto diverse funzionalità secondo le loro personali necessità ed i loro interessi. Tuttavia non è questa la ragione dell'esistenza di tali programmi. Sviluppi inattesi All'inizio del progetto GNU pensavo che avremmo sviluppato l'intero sistema GNU e poi lo avremmo reso disponibile tutto insieme, ma le cose non andarono così. Poiché i componenti del sistema GNU sono stati implementati su un sistema Unix, ognuno di essi poteva girare su sistemi Unix molto prima che esistesse un sistema GNU completo. Alcuni di questi programmi divennero diffusi e gli utenti iniziarono ad estenderli e a renderli utilizzabili su nuovi sistemi: sulle varie versioni di Unix, incompatibili tra loro, e talvolta anche su altri sistemi. Questo processo rese tali programmi molto più potenti e attirò finanziamenti e collaboratori al progetto GNU; tuttavia probabilmente ritardò di alcuni anni la realizzazione di un sistema minimo funzionante, perché il tempo degli autori GNU veniva impiegato a curare la compatibilità di questi programmi con altri sistemi e ad aggiungere nuove funzionalità ai componenti esistenti, piuttosto che a proseguire nella scrittura di nuovi componenti. GNU Hurd Nel 1990 il sistema GNU era quasi completo, l'unica parte significativa ancora mancante era il kernel. Avevamo deciso di implementare il nostro kernel come un gruppo di processi server che girassero sul sistema Mach. Mach è un micro-kernel sviluppato alla Carnegie Mellon University e successivamente all'università dello Utah; GNU Hurd è un gruppo di server (o "herd of gnus": mandria di gnu) che gira su Mach svolgendo le funzioni del kernel Unix. L'inizio dello sviluppo fu ritardato nell'attesa che Mach fosse reso disponibile come software libero, come era stato promesso. Una ragione di questa scelta progettuale fu di evitare quella che sembrava la parte più complessa del lavoro: effettuare il debugging del kernel senza un debugger a livello sorgente. Questo lavoro era già stato fatto, appunto in Mach, e avevamo previsto di effettuare il debugging dei server Hurd come programmi utente, con GDB. Ma questa fase si rivelò molto lunga, ed il debugging dei server multi-thread che si scambiano messaggi si è rivelato estremamente complesso. Per rendere Hurd robusto furono così necessari molti anni. Alix Originariamente il kernel GNU non avrebbe dovuto chiamarsi Hurd; il suo nome originale era Alix -- come la donna di cui ero innamorato in quel periodo. Alix, che era amministratrice di sistemi Unix, aveva sottolineato come il suo nome corrispondesse ad un comune schema usato per battezzare le versioni del sistema Unix: scherzosamente diceva ai suoi amici: «qualcuno dovrebbe chiamare un kernel come me». Io non dissi nulla ma decisi di farle una sorpresa scrivendo un kernel chiamato Alix. Le cose non andarono così. Michael Bushnell (ora Thomas), principale autore del kernel, preferì il nome Hurd, e chiamò Alix una parte del kernel, quella che serviva a intercettare le chiamate di sistema e a gestirle inviando messaggi ai server che compongono HURD. Infine io e Alix ci lasciammo e lei cambiò nome; contemporaneamente la struttura di Hurd veniva cambiata in modo che la libreria C mandasse messaggi direttamente ai server, e così il componente Alix scomparve dal progetto. Prima che questo accadesse, però, un amico di Alix si accorse della presenza del suo nome nel codice sorgente di Hurd e glielo disse. Così il nome raggiunse il suo scopo. 11

12 Linux e GNU/Linux GNU Hurd non è pronto per un uso non sperimentale, ma per fortuna è disponibile un altro kernel: nel 1991 Linus Torvalds sviluppò un Kernel compatibile con Unix e lo chiamò Linux. Attorno al 1992, la combinazione di Linux con il sistema GNU ancora incompleto produsse un sistema operativo libero completo (naturalmente combinarli fu un notevole lavoro di per sé). È grazie a Linux che oggi possiamo utilizzare una versione del sistema GNU. Chiamiamo GNU/Linux questa versione del sistema, per indicare la sua composizione come una combinazione del sistema GNU col kernel Linux. Le sfide che ci aspettano Abbiamo dimostrato la nostra capacità di sviluppare un'ampia gamma di software libero, ma questo non significa che siamo invincibili e inarrestabili. Diverse sfide rendono incerto il futuro del software libero, e affrontarle richiederà perseveranza e sforzi costanti, talvolta per anni. Sarà necessaria quella determinazione che le persone sanno dimostrare quando danno valore alla propria libertà e non permettono a nessuno di sottrargliela. Le quattro sezioni seguenti parlano di queste sfide. Hardware segreto Sempre più spesso, i costruttori di hardware tendono a mantenere segrete le specifiche delle loro apparecchiature; questo rende difficile la scrittura di driver liberi che permettano a Linux e XFree86 [4] di supportare nuove periferiche. Anche se oggi abbiamo sistemi completamente liberi, potremmo non averli domani se non saremo in grado di supportare i calcolatori di domani. Esistono due modi per affrontare il problema. Un programmatore può ricostruire le specifiche dell'hardware usando tecniche di reverse engineering. Oppure si può scegliere hardware supportato dai programmi liberi: man mano che il nostro numero aumenta, la segretezza delle specifiche diventerà una pratica controproducente. Il reverse engineering è difficile: avremo programmatori sufficientemente determinati da dedicarvisi? Sì, se avremo costruito una forte consapevolezza che avere programmi liberi sia una questione di principio e che i driver non liberi non sono accettabili. E succederà che molti di noi accettino di spendere un po' di più o perdere un po' più di tempo per poter usare driver liberi? Si`, se il desiderio di libertà e la determinazione ad ottenerla saranno diffusi. Librerie non libere Una libreria non libera che giri su sistemi operativi liberi funziona come una trappola per i creatori di programmi liberi. Le funzionalità attraenti della libreria fungono da esca; chi usa la libreria cade nella trappola, perché il programma che crea è inutile come parte di un sistema operativo libero (a rigore, il programma potrebbe esservi incluso, ma non funzionerebbe, visto che manca la libreria). Peggio ancora, se un programma che usa la libreria proprietaria diventa diffuso, può attirare altri ignari programmatori nella trappola. Il problema si concretizzò per la prima volta con la libreria Motif [5], negli anni '80. Sebbene non ci fossero ancora sistemi operativi liberi, i problemi che Motif avrebbe causato loro erano già chiari. Il progetto GNU reagì in due modi: interessandosi presso diversi progetti di software libero perché supportassero gli strumenti grafici X liberi in aggiunta a Motif, e cercando qualcuno che scrivesse un sostituto libero di Motif. Il lavoro richiese molti anni: solo nel 1997 LessTif, sviluppato dagli "Hungry Programmers", divenne abbastanza potente da supportare la maggior parte delle applicazioni Motif. Tra il 1996 e il 1998 un'altra libreria non libera di strumenti grafici, chiamata Qt, veniva usata in una significativa raccolta di software libero: l'ambiente grafico KDE. I sistemi liberi GNU/Linux non potevano usare KDE, perché non potevamo usare la libreria; tuttavia, alcuni distributori commerciali di sistemi GNU/Linux, non scrupolosi nell'attenersi solo ai programmi liberi, aggiunsero KDE ai lori sistemi, ottenendo così sistemi che offrivano più funzionalità, ma meno libertà. Il gruppo che sviluppava KDE incoraggiava esplicitamente altri programmatori ad usare Qt, e milioni di nuovi "utenti Linux" non sospettavano minimamente che questo potesse costituire un problema. La situazione si faceva pericolosa. La comunità del software libero affrontò il problema in due modi: GNOME e Harmony. GNOME (GNU Network Object Model Environment, modello di ambiente per oggetti di rete) è il progetto GNU per l'ambiente grafico (desktop). Intrapreso nel 1997 da Miguel de Icaza e sviluppato con il supporto di Red Hat Software, GNOME si ripromise di fornire funzionalità grafiche simili a quelle di KDE, ma usando esclusivamente software libero. 12

13 GNOME offre anche dei vantaggi tecnici, come il supporto per svariati linguaggi di programmazione, non solo il C++. Ma il suo scopo principale era la libertà: non richiedere l'uso di alcun programma che non fosse libero. Harmony è una libreria compatibile con Qt, progettata per rendere possibile l'uso del software KDE senza dover usare Qt. Nel novembre 1998 gli autori di Qt annunciarono un cambiamento di licenza che, una volta operativo, avrebbe reso Qt software libero. Non c'è modo di esserne certi, ma credo che questo fu in parte dovuto alla decisa risposta della comunità al problema posto da Qt quando non era libero (la nuova licenza è scomoda ed iniqua, per cui rimane comunque preferibile evitare l'uso di Qt) [6]. Come risponderemo alla prossima allettante libreria non libera? Riuscirà la comunità in toto a comprendere l'importanza di evitare la trappola? Oppure molti di noi preferiranno la convenienza alla libertà, creando così ancora un grave problema? Il nostro futuro dipende dalla nostra filosofia. Brevetti sul software Il maggior pericolo a cui ci troviamo di fronte è quello dei brevetti sul software, che possono rendere inaccessibili al software libero algoritmi e funzionalità per un tempo che può estendersi fino a vent'anni. I brevetti sugli algoritmi di compressione LZW furono depositati nel 1983, e ancor oggi non possiamo distribuire programmi liberi che producano immagini GIF compresse. Nel 1998 un programma libero per produrre audio compresso MP3 venne ritirato sotto minaccia di una causa per violazione di brevetto. Ci sono modi per affrontare la questione brevetti: possiamo cercare prove che un brevetto non sia valido oppure possiamo cercare modi alternativi per completare ugualmente il lavoro. Ognuna di queste tecniche, però, funziona solo in certe circostanze; quando entrambe falliscono, un brevetto può obbligare tutto il software libero a rinunciare a qualche funzionalità che gli utenti desiderano. Cosa dobbiamo fare quando ciò accade? Chi fra noi apprezza il software libero per il valore della libertà rimarrà comunque dalla parte dei programmi liberi; saremo in grado di svolgere il nostro lavoro senza le funzionalità coperte da brevetto. Ma coloro che apprezzano il software libero perché si aspettano che sia tecnicamente superiore probabilmente grideranno al fallimento quando un brevetto ne impedisce lo sviluppo. Perciò, nonostante sia utile parlare dell'efficacia pratica del modello di sviluppo "a cattedrale" [7], e dell'affidabilità e della potenza di un dato programma libero, non ci dobbiamo fermare qui; dobbiamo parlare di libertà e di principi. Documentazione libera La più grande carenza nei nostri sistemi operativi liberi non è nel software, quanto nella carenza di buoni manuali liberi da includere nei nostri sistemi. La documentazione è una parte essenziale di qualunque pacchetto software; quando un importante pacchetto software libero non viene accompagnato da un buon manuale libero si tratta di una grossa lacuna. E di queste lacune attualmente ne abbiamo molte. La documentazione libera, come il software libero, è una questione di libertà, non di prezzo. Il criterio per definire libero un manuale è fondamentalmente lo stesso che per definire libero un programma: si tratta di offrire certe libertà a tutti gli utenti. Deve essere permessa la redistribuzione (compresa la vendita commerciale), sia in formato elettronico che cartaceo, in modo che il manuale possa accompagnare ogni copia del programma. Autorizzare la modifica è anch'esso un aspetto cruciale; in generale, non credo sia essenziale permettere alle persone di modificare articoli e libri di qualsiasi tipo. Per esempio, non credo che voi o io dobbiamo sentirci in dovere di autorizzare la modifica di articoli come questo, articoli che descrivono le nostre azioni e il nostro punto di vista. Ma c'è una ragione particolare per cui la libertà di modifica è cruciale per la documentazione dei programmi liberi. Quando qualcuno esercita il proprio diritto di modificare il programma, aumentandone o alterandone le funzionalità, se è coscienzioso modificherà anche il manuale, in modo da poter fornire una documentazione utile e accurata insieme al programma modificato. Un manuale che non permetta ai programmatori di essere coscienziosi e completare il loro lavoro non soddisfa i bisogni della nostra comunità. Alcuni limiti sulla modificabilità non pongono alcun problema; per esempio, le richieste di conservare la nota di copyright dell'autore originale, i termini di distribuzione e la lista degli autori vanno bene. Non ci sono problemi nemmeno nel richiedere che le versioni modificate dichiarino esplicitamente di essere tali, così pure che intere sezioni non possano essere rimosse o modificate, finché queste sezioni vertono su questioni non tecniche. Restrizioni di questo tipo non creano 13

14 problemi perché non impediscono al programmatore coscienzioso di adattare il manuale perché rispecchi il programma modificato. In altre parole, non impediscono alla comunità del software libero di beneficiare appieno dal manuale. D'altro canto, deve essere possibile modificare tutto il contenuto tecnico del manuale e poter distribuire il risultato in tutti i formati usuali, attraverso tutti i normali canali di distribuzione; diversamente, le restrizioni creerebbero un ostacolo per la comunità, il manuale non sarebbe libero e avremmo bisogno di un altro manuale. Gli sviluppatori di software libero avranno la consapevolezza e la determinazione necessarie a produrre un'intera gamma di manuali liberi? Ancora una volta, il nostro futuro dipende dalla nostra filosofia. Dobbiamo parlare di libertà Stime recenti valutano in dieci milioni il numero di utenti di sistemi GNU/Linux quali Debian GNU/Linux e Red Hat Linux. Il software libero ha creato tali vantaggi pratici che gli utenti stanno approdando ad esso per pure ragioni pratiche. Gli effetti positivi di questa situazione sono evidenti: maggior interesse a sviluppare software libero, più clienti per le imprese di software libero e una migliore capacità di incoraggiare le aziende a sviluppare software commerciale libero invece che prodotti software proprietari. L'interesse per il software, però, sta crescendo più in fretta della coscienza della filosofia su cui è basato, e questa disparità causa problemi. La nostra capacità di fronteggiare le sfide e le minacce descritte in precedenza dipende dalla determinazione nell'essere impegnati per la libertà. Per essere sicuri che la nostra comunità abbia tale determinazione, dobbiamo diffondere l'idea presso i nuovi utenti man mano che entrano a far parte della comunità. Ma in questo stiamo fallendo: gli sforzi per attrarre nuovi utenti nella comunità sono di gran lunga maggiori degli sforzi per l'educazione civica della comunità stessa. Dobbiamo fare entrambe le cose, e dobbiamo mantenere un equilibrio fra i due impegni. "Open Source" Parlare di libertà ai nuovi utenti è diventato più difficile dal 1998, quando una parte della comunità decise di smettere di usare il termine "free software" e usare al suo posto "open source". Alcune delle persone che suggerirono questo termine intendevano evitare che si confondesse "free" con "gratis", un valido obiettivo. D'altra parte, altre persone intendevano mettere da parte lo spirito del principio che aveva dato la spinta al movimento del software libero e al progetto GNU, puntando invece ad attrarre i dirigenti e gli utenti commerciali, molti dei quali afferiscono ad una ideologia che pone il profitto al di sopra della libertà, della comunità, dei principi. Perciò la retorica di "open source" si focalizza sulla possibilità di creare software di buona qualità e potente ma evita deliberatamente le idee di libertà, comunità, principio. Le riviste che si chiamano "Linux..." sono un chiaro esempio di ciò: sono piene di pubblicità di software proprietario che gira sotto GNU/Linux; quando ci sarà il prossimo Motif o Qt, queste riviste avvertiranno i programmatori di starne lontano o accetteranno la sua pubblicità? L'appoggio delle aziende può contribuire alla comunità in molti modi; a parità di tutto il resto è una cosa utile. Ma ottenere questo appoggio parlando ancor meno di libertà e principi può essere disastroso; rende ancora peggiore lo sbilanciamento descritto tra diffusione ed educazione civica. "Software libero" (free software) e "sorgente aperto" (open source) descrivono più o meno la stessa categoria di software, ma dicono cose differenti sul software e sui valori. Il progetto GNU continua ad usare il termine "software libero" per esprimere l'idea che la libertà sia importante, non solo la tecnologia. Provaci! La filosofia di Yoda ("Non esiste provare") suona bene, ma per me non funziona. Ho fatto la maggior parte del mio lavoro angustiato dal timore di non essere in grado di svolgere il mio compito e nel dubbio, se fossi riuscito, che non fosse sufficiente per raggiungere l'obiettivo. Ma ci ho provato in ogni caso perché nessuno tranne me si poneva tra il nemico e la mia città. Sorprendendo me stesso, qualche volta sono riuscito. A volte ho fallito, alcune delle mie città sono cadute; poi ho trovato un'altra città minacciata e mi sono preparato ad un'altra battaglia. Con l'andar del tempo ho imparato a cercare le possibili minacce e a mettermi tra loro e la mia città, facendo appello ad altri hacker perché venissero e si unissero a me. 14

15 Oggigiorno spesso non sono da solo. È un sollievo ed una gioia quando vedo un reggimento di hacker che scavano trincee per difendere il confine e quando mi rendo conto che questa città può sopravvivere; per ora. Ma i pericoli diventano più grandi ogni anno, ed ora Microsoft ha esplicitamente preso di mira la nostra comunità. Non possiamo dare per scontato il futuro della libertà; non diamolo per scontato! Se volete mantenere la vostra libertà dovete essere pronti a difenderla Note: [1] È difficile dare una definizione semplice di qualcosa talmente variegato come l'hacking, ma credo che la maggior parte degli "hacks" abbiano in comune la giocosità, la bravura e l'esplorazione. Perciò hacking vuol dire esplorare i limiti di quel che è possibile fare, in uno spirito di scaltra giocosità. Quelle attività che evidenziano queste caratteristiche conquistano il valore di hacking. Si può aiutare a correggere le interpretazioni poco corrette ponendo la semplice distinzione tra intrusioni nei sistemi di sicurezza e hacking -- usando il termine "cracking" per tali intrusioni. Coloro che si dedicano a quest'attività vengono definiti "cracker". Alcuni di loro potrebbero anche essere degli hacker, come altri potrebbero giocare a scacchi o a golf ; ma la maggior parte non lo sono. -- "On Hacking," RMS, 2002 [2] La libreria GNU Readline fornisce una serie di funzioni utilizzabili da applicazioni che consentono all'utente la modifica della linee di comando man mano che queste vengono composte. [3] L'algoritmo Lempel-Ziv-Welch è usato per la compressione dei dati. [4] XFree86 è un programma che fornisce un ambiente desktop che interfaccia con le periferiche dell'hardware, quali mouse e tastiera; gira su molte piattaforme diverse. [5] Motif è un interfaccia grafico e manager di finestre che gira su X Windows. [6] Nel settembre 2000 Qt venne ri-ridistribuito sotto la GNU GPL, il che ha sostanzialmente risolto questo problema. [7] Probabilmente intendevo scrivere "del modello a bazaar", poichè era questa l'alternativa nuova e inizialmente controversa La versione originale inglese di questo saggio è apparsa nel libro Open Sources: Voices from the Open Source Revolution (O'Reilly, 1999); in italiano in Open Sources: Voci dalla rivoluzione open source (Apogeo, 1999). Questa versione fa parte del libro Free Software, Free Society: The Selected Essays of Richard M. Stallman, GNU Press, La copia letterale e la distribuzione di questo testo nella sua integrità sono permesse con qualsiasi mezzo, a condizione che sia mantenuta questa nota. Il manifesto GNU Il manifesto GNU venne scritto all'inizio del progetto GNU, per stimolare la partecipazione e il sostegno. Nei primi anni è stato aggiornato in maniera ridotta per documentarne gli sviluppi, ma oggi sembra meglio lasciarlo inalterato per come lo ha visto la maggior parte della gente. Da allora, ci siamo accorti di alcuni equivoci comuni che l'uso di una diversa terminologia potrebbe aiutare ad evitare. Nel corso degli anni sono state aggiunte delle note a chiarimento di tali equivoci. Cos'è GNU? Gnu non è Unix! GNU, che sta per "Gnu's Not Unix" (Gnu Non è Unix), è il nome del sistema software completo e Unix-compatibile che sto scrivendo per distribuirlo liberamente a chiunque lo possa utilizzare. [1] Molti altri volontari mi stanno aiutando. Abbiamo gran necessità di contributi in tempo, denaro, programmi e macchine. 15

16 Fino ad ora abbiamo un editor Emacs fornito di Lisp per espanderne i comandi, un debugger simbolico, un generatore di parser compatibile con yacc, un linker e circa 35 utility. È quasi pronta una shell (interprete di comandi). Un nuovo compilatore C portabile e ottimizzante ha compilato se stesso e potrebbe essere pubblicato quest'anno. Esiste un inizio di kernel, ma mancano molte delle caratteristiche necessarie per emulare Unix. Una volta terminati il kernel e il compilatore sarà possibile distribuire un sistema GNU utilizzabile per lo sviluppo di programmi. Useremo TeX come formattatore di testi, ma lavoriamo anche su un nroff. Useremo inoltre il sistema a finestre portabile libero X. Dopo di che aggiungeremo un Common Lisp portabile, il gioco Empire, un foglio elettronico e centinaia di altre cose, oltre alla documentazione in linea. Speriamo di fornire, col tempo, tutte le cose utili che normalmente si trovano in un sistema Unix, ed anche di più. GNU sarà in grado di far girare programmi Unix, ma non sarà identico a Unix. Apporteremo tutti i miglioramenti che sarà ragionevole fare basandoci sull'esperienza maturata con altri sistemi operativi. In particolare abbiamo in programma nomi più lunghi per i file, numeri di versione per i file, un filesystem a prova di crash, forse completamento automatico dei nomi dei file, supporto indipendente dal terminale per la visualizzazione e forse col tempo un sistema a finestre basato sul Lisp, attraverso il quale più programmi Lisp e normali programmi Unix siano in grado di condividere lo schermo. Sia C che Lisp saranno linguaggi per la programmazione di sistema. Per le comunicazioni vedremo di supportare UUCP, Chaosnet del MIT ed i protocolli di Internet. GNU è inizialmente orientato alle macchine della classe 68000/16000 con memoria virtuale, perché sono quelle su cui è più facile farlo girare. Lasceremo agli interessati il lavoro necessario a farlo girare su macchine più piccole. Vi preghiamo, per evitare confusioni, di pronunciare la 'G' nella parola 'GNU' quando indica il nome di questo progetto [questa avvertenza serve a chiarire che in inglese "GNU" va pronunciato con la g dura, gh-nu, piuttosto che come "new", niu; identica la pronuncia italiana]. Perché devo scrivere GNU Credo che il punto fondamentale sia che, se a me piace un programma, io debba condividerlo con altre persone a cui piace. I venditori di software usano il criterio "divide et impera" con gli utenti, facendo sì che non condividano il software con altri. Io mi rifiuto di spezzare così la solidarietà con gli altri utenti. La mia coscienza non mi consente di firmare un accordo per non rivelare informazioni o per una licenza d'uso del software. Ho lavorato per anni presso il laboratorio di intelligenza artificiale per resistere a queste tendenze e ad altri atteggiamenti sgradevoli, ma col tempo queste sono andate troppo oltre: non potevo rimanere in una istituzione dove ciò viene fatto a mio nome contro la mia volontà.per poter continuare ad usare i computer senza disonore, ho deciso di raccogliere un corpus di software libero in modo da andare avanti senza l'uso di alcun software che non sia libero. Mi sono dimesso dal laboratorio di Intelligenza Artificiale per togliere al MIT ogni scusa legale che mi impedisca di distribuire GNU. Perché GNU sarà compatibile con Unix Unix non è il mio sistema ideale, ma non è poi così male. Le caratteristiche essenziali di Unix paiono essere buone e penso di poter colmare le lacune di Unix senza rovinarne le caratteristiche. E adottare un sistema compatibile con Unix può risultare pratico anche per molti altri. Come sarà reso disponibile GNU GNU non è di pubblico dominio. A tutti sarà permesso di modificare e ridistribuire GNU, ma a nessun distributore sarà concesso di porre restrizioni sulla sua ridistribuzione. Questo vuol dire che non saranno permesse modifiche proprietarie. Voglio essere sicuro che tutte le versioni di GNU rimangano libere. Perché molti altri programmatori desiderano essere d'aiuto Ho trovato molti altri programmatori molto interessati a GNU che vogliono dare una mano. Molti programmatori sono scontenti della commercializzazione del software di sistema. Li può aiutare a far soldi, ma li costringe in generale a sentirsi in conflitto con gli altri programmatori, invece che solidali. L'atto di amicizia fondamentale tra programmatori è condividere programmi; le politiche di commercializzazione attualmente in uso essenzialmente proibiscono ai programmatori di trattare gli altri come amici. Gli acquirenti del software devono decidere tra l'amicizia e l'obbedienza alle leggi. Naturalmente molti decidono che l'amicizia è più importante. Ma quelli che credono nella legge non 16

17 si sentono a proprio agio con queste scelte. Diventano cinici e pensano che programmare sia solo un modo per fare soldi. Lavorando e utilizzando GNU invece che programmi proprietari, possiamo comportarci amichevolmente con tutti e insieme rispettare la legge. Inoltre GNU è un esempio che ispira gli altri e una bandiera che li chiama a raccolta perché si uniscano a noi nel condividere il software. Questo ci può dare una sensazione di armonia che sarebbe irraggiungibile se usassimo software che non sia libero. Per circa la metà dei programmatori che conosco è una soddisfazione importante, che il denaro non può sostituire. Come si può contribuire Chiedo ai produttori di computer donazioni in denaro e macchine, ed ai privati donazioni in programmi e lavoro. Donare delle macchine può far sì che su di esse giri ben presto GNU. Le macchine devono essere sistemi completi e pronti all'uso approvati per l'utilizzo in aree residenziali e non devono richiedere raffreddamento o alimentazione di tipo sofisticato. Ho conosciuto moltissimi programmatori desiderosi di contribuire a GNU a metà tempo. Per la gran parte dei progetti, un lavoro a metà tempo distribuito risulterebbe troppo difficile da coordinare, perché le varie parti scritte indipendentemente non funzionerebbero insieme. Ma per scrivere un sostituto di Unix questo problema non si pone, perché un sistema Unix completo contiene centinaia di programmi di servizio, ognuno con la propria documentazione separata, e con gran parte delle specifiche di interfaccia date dalla compatibilità con Unix. Se ogni partecipante scrive un solo programma da usare al posto di una utility di Unix, il quale funzioni correttamente al posto dell'originale su un sistema Unix, allora questi programmi funzioneranno bene una volta messi assieme. Anche considerando qualche imprevisto dovuto a Murphy [2], assemblare tali componenti è un lavoro fattibile. Il kernel invece richiederà una più stretta cooperazione, e verrà sviluppato da un gruppo piccolo e affiatato. Donazioni in denaro possono mettermi in grado di assumere alcune persone a tempo pieno o a metà tempo. Lo stipendio non sarà alto rispetto agli standard dei programmatori, ma io cerco persone per le quali lo spirito della comunità GNU sia importante quanto il denaro. Io lo vedo come un modo di permettere a degli appassionati di dedicare tutte le loro energie al lavoro su GNU senza essere costretti a guadagnarsi da vivere in un altro modo. Perché tutti gli utenti dei computer ne trarranno beneficio Una volta scritto GNU, ognuno potrà avere liberamente del buon software di sistema, così come può avere l'aria. [3] Questo significa molto di più che far risparmiare a ciascuno il costo di una licenza Unix: vuol dire evitare l'inutile spreco di ripetere ogni volta lo sforzo della programmazione di sistema. Queste energie possono essere invece impiegate ad avanzare lo stato dell'arte. I sorgenti completi del sistema saranno a disposizione di tutti. Di conseguenza, un utente che abbia necessità di apportare dei cambiamenti al sistema sarà sempre in grado di farlo da solo o di commissionare i cambiamenti ad un programmatore o ad un'impresa. Gli utenti non saranno più in balia di un solo programmatore o di una impresa che, avendo la proprietà esclusiva dei sorgenti, sia la sola a poter fare le modifiche. Le scuole avranno la possibilità di fornire un ambiente molto più educativo, incoraggiando gli studenti a studiare e migliorare il software di sistema. I laboratori di informatica di Harvard avevano una politica per cui nessun programma poteva essere installato nel sistema senza che i sorgenti fossero pubblicamente consultabili, e la praticarono rifiutandosi effettivamente di installare alcuni programmi. Questo comportamento mi è stato di grande ispirazione. Infine, scompariranno le necessità burocratiche di tener conto di chi sia il proprietario del software di sistema e di chi abbia il diritto di farci cosa. Ogni sistema per imporre tariffe d'uso di un programma, comprese le licenze d'uso per le copie, è sempre estremamente costoso in termini sociali a causa del complesso meccanismo necessario per decidere quanto (cioè per quali programmi) ognuno debba pagare, e solo uno stato di polizia può costringere tutti all'obbedienza. Immaginate una stazione spaziale dove l'aria deve essere prodotta artificialmente ad un costo elevato: far pagare ogni litro d'aria consumato può essere giusto, ma indossare la maschera col contatore tutto il giorno e tutta la notte è intollerabile, anche se tutti possono permettersi di pagare la bolletta. E le videocamere poste in ogni dove per controllare che nessuno si tolga mai la maschera sono offensive. Meglio finanziare l'impianto di ossigenazione con una tassa pro capite e buttar via le maschere. Copiare un programma in tutto o in parte è tanto naturale per un programmatore quanto respirare ed è altrettanto produttivo. Dovrebbe essere altrettanto libero. 17

18 Alcune obiezioni facilmente confutabili agli obiettivi GNU: - "La gente non lo userà se è gratuito, perché non potrà avere l'assistenza". - "Un programma deve essere a pagamento, per poter fornire supporto adeguato". Se la gente preferisse pagare per GNU più l'assistenza piuttosto che avere GNU gratis senza assistenza, allora un'impresa che fornisse assistenza a chi si è procurato GNU gratis potrebbe operare con profitto. Si deve distinguere tra il supporto sotto forma di lavoro di programmazione e la semplice gestione. Il primo non è ottenibile da un venditore di software. Se il problema non è sentito da un numero sufficiente di clienti allora il venditore dirà al cliente di arrangiarsi. Per chi deve poter contare su questo tipo di supporto l'unica soluzione è di disporre dei sorgenti e degli strumenti necessari, in modo da poter commissionare il lavoro a chi sia disposto a farlo, invece che rimanere in balia di qualcuno. Con Unix il prezzo dei sorgenti rende ciò improponibile per la maggior parte delle imprese. Con GNU questo sarà invece facile. Si darà sempre il caso che non siano disponibili persone competenti, ma questo non potrà essere imputato al sistema di distribuzione. GNU non elimina tutti i problemi del mondo, solo alcuni. Allo stesso tempo, gli utenti che non sanno nulla di computer hanno bisogno di manutenzione, cioè di cose che potrebbero fare facilmente da soli ma che non sono in grado di fare. Servizi di questo genere potrebbero essere forniti da aziende che vendono solo gestione e manutenzione. Se è vero che gli utenti sono disposti a pagare per un prodotto con servizio, allora saranno anche disposti a pagare per il servizio avendo avuto il prodotto gratuitamente. Le aziende di servizi si faranno concorrenza sul prezzo e sulla qualità; gli utenti d'altra parte non saranno legati a nessuna di esse in particolare. Nel frattempo, coloro che non avranno bisogno del servizio saranno sempre in grado di usare il programma senza pagare il servizio. - "Non si può raggiungere molta gente senza pubblicità, e per finanziarla si deve far pagare il programma". - "È inutile reclamizzare un programma gratuito". Ci sono molte forme di pubblicità gratuita o a basso costo che possono essere usate per informare un gran numero di utenti di computer riguardo a cose come GNU. Ma può essere vero che la pubblicità può raggiungere molti più utenti di microcomputer. Se fosse veramente così, una ditta che reclamizzasse il servizio di copia e spedizione per posta di GNU a pagamento dovrebbe aver abbastanza successo commerciale da rientrare dai costi della pubblicità e da guadagnarci. In questo modo, pagano la pubblicità solo gli utenti che ne beneficiano. D'altro canto, se molta gente ottiene GNU da amici e queste aziende non hanno successo, vorrà dire che la pubblicità non era necessaria per diffondere GNU. Perché tutti questi difensori del libero mercato non vogliono lasciare che sia il libero mercato a decidere? [4] "La mia azienda ha bisogno di un sistema operativo proprietario per essere più avanti della concorrenza". Con GNU, i sistemi operativi non rientreranno più fra gli elementi di concorrenza. La vostra azienda non potrà essere concorrenziale in quest'area, ma egualmente non potranno esserlo i concorrenti. Vi farete concorrenza in altre aree, mentre in questa godrete di mutui benefici. Se vendete sistemi operativi non apprezzerete GNU, ma è un problema vostro. Se avete un'attività di altro tipo, GNU vi può evitare di essere spinti nel costoso campo della vendita di sistemi operativi. Mi piacerebbe che lo sviluppo di GNU fosse sostenuto da donazioni da parte di numerosi produttori ed utenti, riducendo così la spesa per tutti. [5] - "Ma i programmatori non meritano una ricompensa per la loro creatività?" Se qualcosa merita una ricompensa questo è il contribuire al bene sociale. La creatività può essere un contributo al bene sociale, ma solo nella misura in cui la società è libera di usarne i risultati. Se i programmatori meritano una ricompensa per la creazione di programmi innovativi, allora con la stessa logica meritano una punizione se pongono restrizioni all'uso di questi programmi. - "Un programmatore non dovrebbe poter chiedere una ricompensa per la sua creatività?" Non c'è niente di male nel chiedere di esser pagati per il proprio lavoro, o mirare ad incrementare le proprie entrate, fintanto che non si utilizzino metodi che siano distruttivi. Ma i metodi comuni nel campo del software, al giorno d'oggi, sono distruttivi. Spremere denaro dagli utenti di un programma imponendo restrizioni sull'uso è distruttivo perché riduce i modi in cui il programma può essere usato. Questo diminuisce la quantità di ricchezza che l'umanità ricava dal programma. Quando c'è una scelta deliberata di porre restrizioni, le conseguenze dannose sono distruzione deliberata. 18

19 La ragione per cui un buon cittadino non usa questi metodi distruttivi per diventare più ricco è che, se lo facessero tutti, diventeremmo tutti più poveri a causa delle distruzioni reciproche. Questa è etica kantiana, la Regola Aurea: poiché non mi piacciono le conseguenze che risulterebbero se tutti impedissero l'accesso alle informazioni, devo considerare sbagliato che uno lo faccia. In particolare, il desiderio di una ricompensa per la propria creatività non giustifica il privare il mondo nel suo insieme di tutta o parte di questa creatività. - "Ma i programmatori non moriranno di fame?" Potrei rispondere che nessuno è obbligato a fare il programmatore. La maggior parte di noi non è in grado di andare per strada a fare il mimo, ma ciò non vuol dire che siamo condannati a passare la vita per strada a fare i mimi, e morire di fame. Facciamo un altro lavoro. Ma è la risposta sbagliata, perché accetta l'assunzione implicita di chi pone la domanda, e cioè che senza proprietà del software non è possibile pagare ai programmatori il becco di un quattrino. Un'assunzione del tipo tutto o niente. La vera ragione per cui i programmatori non moriranno di fame è che sarà per loro egualmente possibile essere pagati per programmare, solo non pagati così tanto come ora. Porre restrizioni sulle copie non è l'unico modello di affari nel campo del software. È il modello più comune perché è il più redditizio. Se fosse vietato, o rifiutato dagli utenti, l'industria del software si sposterebbe su altri modelli organizzativi, adottandone altri ora meno comuni. Ci sono sempre numerosi modi per organizzare un qualunque tipo di affari. Probabilmente programmare nel nuovo modello organizzativo non sarà più così redditizio come lo è ora. Ma questo non è un argomento contro il cambiamento. Che gli addetti alle vendite ricevano i salari che ora ricevono non è considerata un'ingiustizia. Se i programmatori avessero gli stessi stipendi (in pratica guadagnerebbero molto di più), non sarebbe nemmeno quella un'ingiustizia. - "Ma le persone non hanno diritto di controllare come la loro creatività viene usata?" Il "controllo sull'uso delle proprie idee" in realtà costituisce un controllo sulle vite degli altri; e di solito viene usato per rendere più difficili le loro vite. Le persone che hanno studiato con cura i vari aspetti del diritto alla proprietà intellettuale (come gli avvocati) dicono che non c'è alcun diritto intrinseco alla proprietà intellettuale. I tipi dei supposti diritti alla proprietà intellettuale riconosciuti dal governo furono creati da specifici atti legislativi per scopi specifici. Per esempio la legislazione sui brevetti fu introdotta per incoraggiare gli inventori a rivelare i dettagli delle loro invenzioni. Lo scopo era avvantaggiare la società più che avvantaggiare gli inventori. A quel tempo la validità di 17 anni per un brevetto era breve se confrontata con la velocità di avanzamento dello stato dell'arte. Poiché i brevetti riguardano solo i produttori, per i quali il costo e lo sforzo degli accordi di licenza sono piccoli in confronto all'organizzazione della produzione, spesso i brevetti non costituiscono un gran danno. E non ostacolano la gran parte degli individui che usano prodotti coperti da brevetto. L'idea del copyright non esisteva in tempi antichi, quando gli autori copiavano estesamente altri autori in opere non narrative. Questa pratica era utile, ed è il solo modo attraverso cui almeno parte del lavoro di alcuni autori è sopravvissuto. La legislazione sul copyright fu creata espressamente per incoraggiare l'originalità. Nel campo per cui fu inventata, cioè i libri, che potevano essere copiati a basso costo solo con apparecchiature tipografiche, non fece molto danno e non pose ostacoli alla maggior parte dei lettori. Tutti i diritti di proprietà intellettuale sono solo licenze concesse dalla società perché si riteneva, correttamente o meno, che concederle avrebbe giovato alla società nel suo complesso. Ma data una situazione particolare dobbiamo chiederci: facciamo realmente bene a concedere queste licenze? Che atti permettiamo di compiere con esse? Il caso dei programmi ai giorni nostri differisce enormemente da quello dei libri un secolo fa. Il fatto che la via più facile per passare una copia di un programma sia da persona a persona, che il programma abbia un codice sorgente ed un codice oggetto che sono cose distinte, ed infine il fatto che un programma venga usato più che letto e gustato, combinandosi creano una situazione in cui qualcuno che impone un copyright minaccia la società nel suo insieme, sia materialmente che spiritualmente, una situazione in cui quel qualcuno non dovrebbe farlo, che la legge lo permetta o no. - "La competizione fa sì che le cose siano fatte meglio." Il paradigma della competizione è la gara: premiando il vincitore incoraggia ognuno a correre più veloce. Quando veramente il capitalismo funziona in questo modo, fa un buon lavoro; ma chi lo difende ha torto nell'asserire che agisce sempre così. Se i corridori dimenticano il motivo per cui è offerto il premio e si concentrano solo sul vincere non curandosi 19

20 di come, possono trovare altre strategie, come ad esempio attaccare gli altri concorrenti. Se i corridori si azzuffano, arrivano tutti in ritardo al traguardo. Il software proprietario e segreto è l'equivalente morale dei corridori che si azzuffano. Triste a dirsi, l'unico arbitro che abbiamo pare non muovere alcuna obiezione alle zuffe, al più le regolamenta ("ogni dieci metri puoi tirare un pugno"). Dovrebbe invece dividerli e penalizzarli anche se solo provassero a combattere. - "Ma senza un incentivo economico non smetterebbero tutti di programmare?" In realtà molta gente programmerebbe senza alcun incentivo economico. Programmare ha un fascino irresistibile per alcune persone, solitamente per quelli che ci riescono meglio. Non mancano certo i musicisti professionisti che insistono pur non avendo speranza di guadagnarsi da vivere suonando. Ma in realtà questa domanda, benché posta spesso, non è appropriata. La paga per i programmatori non sparirà, semplicemente diminuirà. Quindi la domanda corretta è: "qualcuno si metterà mai a programmare per un minore incentivo economico?" La mia esperienza dice che sì, ci si metterà. Per più di dieci anni molti tra i migliori programmatori del mondo hanno lavorato nel laboratorio di Intelligenza Artificiale per molti meno soldi di quanti ne avrebbero potuti ricevere in ogni altro posto. Hanno avuto soddisfazioni non economiche di moltissimi tipi, ad esempio fama e riconoscenza. E la creatività è anche divertente, un premio di per sé. Poi molti se ne sono andati quando hanno avuto la possibilità di fare lo stesso interessante lavoro per un mucchio di soldi. Ciò che i fatti mostrano è che la gente programma per altre ragioni che non siano il denaro; ma se viene data la possibilità di fare la stessa cosa per un mucchio di soldi, allora cominceranno ad aspettarseli e a richiederli. Le organizzazioni che pagano poco sono svantaggiate in confronto a quelle che pagano molto, ma non sarebbero necessariamente in questa posizione se quelle che pagano molto fossero bandite. - "Abbiamo un disperato bisogno dei programmatori. Se ci chiedono di smettere di aiutare i nostri vicini dobbiamo obbedire." Non si è mai così disperati da dover obbedire a questo genere di pretese. Ricorda: milioni in difesa, ma non un centesimo in tributi [è una famosa frase di George Washington]. - "I programmatori devono guadagnarsi da vivere in qualche modo." A breve termine è vero. Ma ci sono un'infinità di modi in cui i programmatori possono guadagnarsi da vivere senza vendere i diritti d'uso dei programmi. Questo metodo è comune ai giorni nostri perché porta la maggior quantità di denaro a programmatori e aziende, non perché sia l'unica strada per guadagnarsi da vivere. È facile trovarne altre, nel caso lo si voglia. Ecco una serie di esempi. - Un produttore che immette sul mercato un nuovo computer pagherà per il porting dei sistemi operativi sul nuovo hardware. - I servizi a pagamento di insegnamento, gestione e manutenzione possono impiegare dei programmatori. - Persone con idee nuove possono distribuire i programmi come gratuitamente chiedendo donazioni agli utenti soddisfatti, o vendendo servizi di gestione. Ho incontrato persone che già lavorano con successo in questo modo. - Utenti con necessità simili possono formare gruppi e pagare. Un gruppo potrebbe stipulare un contratto con un'impresa di programmazione per scrivere i programmi che i membri del gruppo vorrebbero usare. Tutti i tipi di sviluppo possono essere finanziati da una Tassa per il Software: - Supponiamo che chiunque compri un computer debba pagare un x per cento del costo del computer come tassa per il software. Il governo girerebbe questi fondi ad un'agenzia come la NSF [più o meno l'equivalente del nostro CNR] per impiegarli nello sviluppo del software. - Ma se è lo stesso acquirente a fare una donazione per lo sviluppo del software, potrebbe ottenere un credito nei confronti di queste tasse. Potrebbe fare una donazione ad un progetto di sua scelta -- tipicamente scelto perché spera di usarne i risultati quando questo verrà completato. Potrebbe ottenere un credito per ogni donazione fatta, fino al valore totale della tassa che dovrebbe pagare. - Il gettito complessivo di questa tassa potrebbe essere deciso dal voto di chi la paga, pesato secondo l'ammontare pagato. 20