“Lo scopo di GNU consisteva nell’offrire libertà agli utenti, non solo nell’ottenere ampia diffusio-
ne. Avevamo quindi bisogno di termini di distribuzione che evitassero che il software GNU fosse
trasformato in software proprietario. Il metodo che usammo si chiama “permesso d’autore”.
Il permesso d’autore (copyleft)5. 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.
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.”
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 (Fondazione per il software libero), 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 Shell67 , che è stata sviluppata da
Brian Fox, dipendente della FSF.
Finanziammo lo sviluppo di questi programmi perché il progetto GNU non riguardava so-
lo strumenti di lavoro o un ambiente di sviluppo: il nostro obiettivo era un sistema operativo
completo, e questi programmi erano necessari per raggiungere quell’obiettivo.”
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 ri ette 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 al-
cun 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.”
“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ù sempli-
ce 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.”
L’elenco dei compiti GNU
“Mentre il progetto GNU avanzava, e un numero sempre maggiore di componenti di sistema ve-
nivano 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 a una fetta non
trascurabile di utenti sarebbe un’utile aggiunta a 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”8, 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 a 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 e ogni com-
pilatore 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’u-
nica 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.
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, 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 han-
no 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 soft-
ware 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.”
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.
Ad 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 ha bisogno di un programma tar 9. 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. 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à e 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 a 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.”
“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 microkernel 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, e 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 a 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 ve-
niva 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.”
Nessun commento:
Posta un commento