Perché il software dovrebbe essere
libero
Inevitabilmente l'esistenza del software
solleva la domanda su come dovrebbero essere prese le decisioni
per il suo utilizzo. Supponiamo ad esempio che una persona in
possesso di una copia di un programma incontra qualcun altro che
ne vorrebbe anch'egli una copia. C'è la possibilità
di copiare quel programma; a chi spetta la decisione se farlo
o meno? Alle persone coinvolte? Oppure ad un altro soggetto, definito
il "proprietario"?
Gli sviluppatori di software tipicamente affrontano simili questioni
sulla base dell'assunto che il criterio per la risposta sia quello
di massimizzare i profitti degli stessi sviluppatori. Il potere
politico dell'imprenditoria ha portato all'adozione da parte del
governo sia di questo criterio sia della risposta degli sviluppatori.
Ovvero, che esiste il proprietario del programma, tipicamente
una corporation associata con il suo sviluppo.
Vorrei affrontare la medesima domanda sulla base di un diverso
criterio: la prosperità e la libertà del pubblico
in generale.
Questa risposta non può essere decisa dall'attuale legislazione
-- dovrebbe essere la legge a conformarsi all'etica, non viceversa.
Non spetta neppure alle pratiche correnti decidere su tale questione,
pur potendo queste suggerire possibili risposte. L'unico modo
di giudicare è considerare chi viene aiutato e chi danneggiato
dal riconoscimento dei proprietari del software. In altri termini,
si dovrebbe condurre un'analisi costi-benefici per conto della
società nel suo complesso, prendendo in considerazione
la libertà individuale come pure la produzione di beni
materiali.
Nel presente saggio illustrerò gli effetti dovuti all'esistenza
dei proprietari, dimostrandone i risultati negativi. La mia conclusione
è che i programmatori hanno il dovere di incoraggiare gli
altri a condividere, ridistribuire, studiare e migliorare il software
che scriviamo: in altri termini, a scrivere software libero ("free
software") (1).
(1) Il termine "free" in "free software" si riferisce alla libertà, non al prezzo ('free' in inglese significa sia 'libero' sia 'gratuito'); il prezzo pagato per la copia di un programma libero può essere zero, basso oppure (raramente) piuttosto elevato.
In che modo i proprietari giustificano il proprio potere
Quanti traggono benefici dall'attuale sistema
in cui i programmi sono considerati una proprietà, offrono
due argomenti a sostegno delle proprie tesi a favore di tale proprietà:
l'argomento emotivo e quello economico.
L'argomento emotivo funziona così: "Ci metto il sudore
e l'anima in questo programma. Viene da me, è mio!"
Quest'argomento non richiede una seria refutazione. La sensazione
di attaccamento è qualcosa che i programmatori possono
coltivare quando meglio si adatta loro; non è inevitabile.
Consideriamo, ad esempio, con quanta decisione gli stessi programmatori
siano soliti concedere con una firma tutti i diritti ad una grande
corporation in cambio di uno stipendio; l'attaccamento emotivo
scompare misteriosamente. All'opposto, consideriamo invece i grandi
artisti e artigiani del Medioevo, che non si curavano neppure
di firmare le proprie opere. Per loro, il nome dell'artista non
era importante. Quello che contava era portare a compimento quell'opera
- e lo scopo cui era destinata. Questa la visione prevalente per
centinaia di anni.
L'argomento economico funziona così: "Voglio diventare
ricco (generalmente descritto in maniera poco accurata come 'guadagnarsi
da vivere'), e se non mi consentite di diventare ricco con la
programmazione, allora smetterò di scrivere programmi.
Tutti gli altri sviluppatori la pensano come me, per cui nessuno
vorrà mai programmare. E allora rimarrete senza alcun programma!"
In genere questa minaccia viene velata come un amichevole avviso
da una saggia fonte.
Più avanti spiegherò perché tale minaccia
non è altro che bluff. Prima vorrei affrontare un assunto
implicito che acquista maggior visibilità in un'altra formulazione
dell'argomento.
Questa formulazione parte mettendo a confronto l'utilità
sociale di un programma proprietario con l'assenza di programmi,
per poi concludere che lo sviluppo di software proprietario è,
nel suo insieme, qualcosa di benefico e andrebbe incoraggiato.
L'errore qui consiste nel contrapporre soltanto due scenari --
software proprietario contro niente software -- assumendo l'inesistenza
di ulteriori possibilità.
Considerando un sistema di copyright sul software, lo sviluppo
del software viene solitamente connesso all'esistenza di un proprietario
che ne controlli l'utilizzo. Fintantoché esisterà
questa connessione, siamo spesso costretti a confrontarci con
la scelta tra software proprietario o niente software. Tuttavia,
tale connessione non è qualcosa di inerente o inevitabile;
è una conseguenza della specifica decisione socio-legale
che mettiamo in discussione: la decisione di avere dei proprietari.
Presentare la scelta come tra software proprietario o niente software
significa travisare la questione.
L'argomento contro l'esistenza di proprietari
La domanda in ballo è, "Lo sviluppo
del software dovrebbe essere connesso con l'esistenza di proprietari
cui spetti limitarne l'utilizzo?"
Onde poter sciogliere il quesito, dobbiamo giudicare gli effetti
sulla società di ciascuna delle due attività seguenti
in maniera indipendente tra loro: l'effetto dello sviluppo
del software (prescindendo dai relativi termini di distribuzione)
e l'effetto derivante dalla limitazione del suo utilizzo (assumendo
che il software sia stato sviluppato). Se una di queste attività
dovesse risultare giovevole e l'altra dannosa, sarebbe bene lasciar
andare tale connessione e optare soltanto per quella giovevole.
In altri termini, se limitare la distribuzione di un programma
già sviluppato risulta dannoso per la società in
generale, allora lo sviluppatore etico rifiuterà una simile
opzione.
Onde stabilire l'effetto di limitazioni nella condivisione, occorre
paragonare il valore sociale di un programma ristretto (ovvero,
proprietario) con quello dello stesso programma disponibile a
chiunque. Ciò significa mettere a confronto due mondi possibili.
L'analisi affronta anche il semplice argomento talvolta contrapposto
a questo, secondo cui "il beneficio al vicino nel fornirgli
o fornirle la copia di un programma viene cancellato dal danno
procurato al proprietario". Questo contro-argomento assume
che il danno e il beneficio siano di proporzioni identiche. L'analisi
include un raffronto fra tali proporzioni, per concludere che
il beneficio risulta di gran lunga maggiore.
Per meglio illustrare l'argomento, applichiamolo ad un altro ambito:
la costruzione di una rete stradale.
Tramite i pedaggi sarebbe possibile finanziare la costruzione
di tutte le strade. Ciò comporterebbe la presenza di appositi
caselli a tutti gli angoli. Un simile sistema risulterebbe di
grande incentivo al miglioramento della rete stradale. Offrirebbe
inoltre il vantaggio di costringere quanti usano quella specifica
strada al pagamento del relativo pedaggio. Eppure un casello per
il pedaggio rappresenterebbe un'ostruzione artificiale alla fluidità
di guida -- artificiale perché non è una conseguenza
di come funzionano le strade o le autovetture.
Paragonando le strade libere e quelle a pedaggio sulla base della
loro utilità, scopriamo che (tutto il resto essendo identico)
le strade senza caselli richiedono meno denaro per essere costruite
e gestite, sono più sicure e più efficienti nell'utilizzo
(2).
(2) Le questioni relative a inquinamento e congestioni di traffico non alterano questa conclusione. Nel caso si volesse rendere più esosa la guida onde scoraggiarla in generale, è svantaggioso farlo tramite dei caselli a pedaggio, i quali contribuiscono sia all'inquinamento che al traffico. Molto meglio ricorrere a una tassa sulla benzina. Allo stesso modo, la volontà di ottenere maggior sicurezza limitando la massima velocità consentita non è un fattore rilevante; una strada ad accesso libero estende la velocità media evitando fermate e ritardi, all'interno dei limiti di velocità designati.
In un paese povero molti cittadini sarebbero
impossibilitati a usare le strade a pedaggio. Perciò le
strade senza caselli offrono alla società maggiori benefici
a costi minori; sono da preferire per la società. Di conseguenza,
la società dovrebbe scegliere di reperire i finanziamenti
in un altro modo, non tramite i caselli a pagamento. L'uso delle
strade, una volta costruite, dovrebbe essere libero.
Quando i sostenitori dei caselli li propongono unicamente
come un modo per raccogliere denaro, distorcono la scelta a disposizione.
È vero che i caselli a pedaggio portano soldi, ma provocano
anche altre conseguenze: in realtà degradano la strada.
Una strada a pedaggio non è così positiva come una
libera; pur offrendo strade in numero maggiore o tecnicamente
superiori, ciò non sarebbe un miglioramento qualora dovesse
comportare la sostituzione delle strade libere con quelle a pagamento.
Ovviamente la costruzione di una strada libera necessita di fondi,
che in qualche modo il pubblico è chiamato a sborsare.
Tuttavia ciò non implica l'inevitabilità del pedaggio.
Noi che dobbiamo comunque sostenerne le spese, ricaviamo maggior
valore dal nostro denaro acquistando una strada libera.
Non sto dicendo che una strada a pagamento sia peggiore di non
avere nessuna strada. Ciò sarebbe vero nel caso il pedaggio
fosse talmente elevato da impedirne l'utilizzo quasi a tutti --
procedura questa improbabile per chi dovesse riscuotere il pedaggio.
Tuttavia, finché i caselli provocano spreco e inconvenienti
significativi, è meglio raccogliere i fondi necessari in
maniera meno limitante.
Applicando la medesima logica allo sviluppo del software, passerò
ora a dimostrare come l'esistenza di "caselli a pedaggio"
per utili programmi risulti assai esosa per la società:
rende i programmi più costosi da realizzare, più
costosi da distribuire, meno soddisfacenti ed efficaci da usare.
Ne consegue che la costruzione dei programmi va incoraggiata in
qualche altro modo. Proseguirò poi spiegando altri metodi
per incoraggiare e (finché sia realmente necessario) per
reperire fondi per lo sviluppo del software.
Il danno provocato dall'ostruzione del software
Consideriamo per un momento lo scenario in cui un programma sia stato sviluppato, e ogni pagamento necessario al suo sviluppo sia stato coperto; ora la società deve scegliere se renderlo proprietario oppure se garantirne condivisione e utilizzo liberi. Come assunto, l'esistenza e la disponibilità del programma sono qualcosa di desiderabile. (3)
(3) Un particolare programma informatico potrebbe essere considerato dannoso fino a negarne la disponibilità, come è accaduto al database per dati personali Lotus Marketplace, ritirato dal mercato a seguito della disapprovazione del pubblico. Gran parte di quanto sostengo non si applica a casi simili, ma ha poco senso affermare la necessità di un proprietario sulla base del fatto che quest'ultimo potrebbe limitare la disponibilità del programma. Il proprietario non lo metterà mai completamente fuori commercio, come si vorrebbe nel caso di un programma il cui impiego è considerato distruttivo.
Le restrizioni sulla distribuzione e sulla
modifica del programma non possono facilitarne l'utilizzo. Possono
soltanto interferire. Così l'effetto sarà soltanto
negativo. Ma fino a che punto? E di che tipo?
Questa ostruzione produce tre diversi livelli di danno materiale:
1. Un minor numero di persone usa il programma.
2. Nessun utente può adattare o aggiustare il programma.
3. Gli altri sviluppatori non possono imparare dal programma,
né usarlo come base per nuovi lavori.
Ciascun livello di danno materiale riflette una forma concomitante
di danno psico-sociale. Ciò si riferisce all'effetto prodotto
dalle decisioni della gente sui successivi sentimenti, attitudini
e predisposizioni. Questi cambiamenti nel modo di pensare avrà
poi un ulteriore effetto sulle relazioni con i concittadini, e
potranno causare conseguenze materiali.
I tre livelli di danno materiale fanno sprecare parte del valore
che il programma potrebbe offrire, ma non possono ridurlo a zero.
Se provocano lo spreco quasi totale del valore, allora scrivere
il programma danneggia la società in misura pari allo sforzo
necessario per scriverlo. A ragione, un programma che produce
dei guadagni nelle vendite deve fornire qualche beneficio materiale
diretto.
Tuttavia, considerando il concomitante danno psico-sociale, non
esistono limiti al danno causato dallo sviluppo del software proprietario.
Ostruire l'uso dei programmi
Il primo livello di danno impedisce il semplice
utilizzo del programma. La copia di un programma ha un costo marginale
quasi vicino a zero (e si può pagare tale costo facendola
da soli), così che in un mercato libero avrebbe un prezzo
vicino a zero. Una licenza a pagamento è un disincentivo
significativo nell'uso del programma. Se un programma molto utile
è software proprietario, verrà usato da un numero
alquanto ridotto di persone.
È facile dimostrare che il contributo complessivo di un
programma rispetto alla società risulta ridotto assegnandogli
un proprietario. Ogni utente potenziale del programma, di fronte
alla necessità di dover pagare per usarlo, potrebbe scegliere
di pagare o meno, o anche di rinunciare a utilizzarlo. Quando
un utente sceglie di pagare, questo è un trasferimento
di ricchezza a quota zero tra due entità. Ma ogni volta
che qualcuno decide di rinunciare all'uso del programma, ciò
danneggia quell'individuo senza giovare a nessuno. La somma di
cifre negative e zeri risulta negativa.
Ma ciò non riduce l'ammontare di lavoro necessario per
sviluppare il programma. Come risultato, viene ridotta
l'efficacia dell'intero processo, ovvero la soddisfazione dell'utente
ottenuta per ogni ora di lavoro.
Ciò riflette una differenza cruciale tra le copie di un
programma e oggetti quali automobili, sedie o panini. Non esiste
una macchina per copiare gli oggetti materiali al di fuori della
fantascienza. Ma i programmi sono facili da copiare; chiunque
è in grado di produrne quante copie ne vuole con uno sforzo
minimo. Ciò non si applica agli oggetti materiali perché
la materia si conserva: ogni nuova copia dev'essere costruita
dal materiale grezzo nella stessa maniera con cui è stata
costruita la prima copia.
Con gli oggetti materiali ha senso creare un disincentivo al loro
impiego, perché l'acquisto di un minor numero di oggetti
significa minor materiale grezzo e minor lavoro per costruirli.
È vero che generalmente esiste anche un costo iniziale
d'ammortamento, un costo di sviluppo, che viene frazionato lungo
la fase di produzione. Ma finché il costo marginale della
produzione è significativo, l'aggiunta di una quota del
costo di sviluppo non provoca una differenza qualitativa. E non
richiede restrizioni sulla libertà dei comuni utenti.
Tuttavia l'imposizione di un prezzo su qualcosa che altrimenti
sarebbe libera rappresenta un cambiamento qualitativo. Una tariffa
sulla distribuzione del software, imposta a livello centralizzato,
diventa un potente disincentivo.
Inoltre, la produzione centrale come viene praticata oggi è
inefficace perfino in quanto mezzo per diffondere copie del software.
Questo sistema prevede la chiusura di dischi o nastri materiali
all'interno di pacchetti inutili, la loro spedizione in gran quantità
intorno al mondo, e il loro immagazzinamento per la vendita. Questo
costo viene presentato come una spesa di tale attività
commerciale; in realtà, è parte dello spreco causato
dall'esistenza dei proprietari.
Danneggiare la coesione sociale
Supponiamo che una persona e il proprio
vicino considerino utile l'impiego di un certo programma. Con
attenzione etica per il vicino, ci si dovrebbe rendere conto che
un'adeguata gestione della situazione consentirà a entrambi
di utilizzarlo. La proposta di consentire l'uso del programma
soltanto a uno dei due, impedendolo all'altro, è divisoria;
entrambi la considererebbero inaccettabile.
Firmare un tipico contratto per la licenza del software significa
tradire il vicino: "Prometto di privare il mio vicino di
questo programma in modo che possa averne una copia tutta per
me". Quanti optano per simili scelte subiscono una pressione
psicologica interna per giustificarle, diminuendo l'importanza
di aiutare il vicino -- in tal modo, lo spirito pubblico ne soffre.
Questo è il danno psicologico associato con quello materiale
di scoraggiare l'uso del programma.
Molti utenti riconoscono inconsciamente l'errore nel rifiuto a
condividere, così decidono di ignorare licenze e leggi,
e condividere comunque il programma. Ma spesso si sentono in colpa
per averlo fatto. Sanno che devono infrangere la legge onde poter
essere dei buoni vicini, ma rispettano ancora l'autorità
giuridica, e concludono che il fatto di essere dei buoni vicini
(come sono in effetti) è qualcosa di male o di cui vergognarsi.
Anche questo è un tipo di danno psicologico, che però
si può evitare decidendo che tali licenze e leggi non posseggono
alcuna forza morale.
Anche i programmatori subiscono il danno psicologico di sapere
che a numerosi utenti non verrà consentito di utilizzare
il proprio lavoro. Ciò porta a un'attitudine di cinismo
o diniego. Uno sviluppatore potrà descrivere in maniera
entusiasta un lavoro che considera tecnicamente eccitante; poi
quando gli si chiede, "Mi sarà permesso di usarlo?",
impallidisce e ammette che la risposta è no. Per evitare
di sentirsi scoraggiato, la maggior parte delle volte finisce
per ignorare questo fatto oppure adotta un atteggiamento di cinica
distanza mirato a minimizzarne l'importanza.
Fin dal periodo di Reagan (4), la maggiore scarsità degli
Stati Uniti non riguarda l'innovazione tecnica, ma piuttosto la
volontà di lavorare insieme per il bene pubblico. Non ha
alcun senso incoraggiare la prima a spese del secondo.
(4) Ronald Reagan, il 40. Presidente degli Stati Uniti, è famoso per aver tagliato numerosi programmi sociali. A lui si deve inoltre la creazione di una politica economica, definita "trickle down economics" (economia che sgocciola), considerata da molti un fallimento.
Ostruire gli adattamenti personalizzati di programmi
Il secondo livello di danno materiale è
l'impossibilità di adattare i programmi. La facilità
di modificare il software è uno dei suoi grandi vantaggi
rispetto alle vecchie tecnologie. Ma la gran parte del software
disponibile in ambito commerciale non può essere modificato,
neppure dopo averlo acquistato. È disponibile a scatola
chiusa, prendere o lasciare, tutto qui.
Un programma che è possibile far girare è composto
da una serie di numeri dall'oscuro significato. Nessuno, neanche
un buon programmatore, è in grado di modificare facilmente
tali numeri onde rendere il programma diverso in qualche modo.
Normalmente gli sviluppatori lavorano con il "codice sorgente"
di un programma, che è scritto in un linguaggio di programmazione
tipo Fortran o C. Ricorre a dei nomi per indicare i dati usati
e le parti di un programma, e rappresenta le operazioni con simboli
quali + per le addizioni e - per le sottrazioni. È progettato
per aiutare gli sviluppatori a leggere e modificare il programma.
Ecco un esempio; un programma per calcolare la distanza tra due
punti su un piano: (5)
float
distance (p0, p1)
struct point p0, p1;
{
float xdist = p1.x - p0.x;
float ydist = p1.y - p0.y;
return sqrt (xdist * xdist + ydist * ydist);
}
Ecco lo stesso programma in formato eseguibile (6), sul computer che uso normalmente:
1314258944 -232267772 -231844864 1634862
1411907592 -231844736 2159150 1420296208
-234880989 -234879837 -234879966 -232295424
1644167167 -3214848 1090581031 1962942495
572518958 -803143692 1314803317
(5) Non è importante capire in che modo operi il codice sorgente; quel che è importante è notare che tale codice sorgente viene scritto ad un livello di astrazione piuttosto comprensibile.
(6) Si noti l'incomprensibilità del codice eseguibile; è chiaramente più difficile capirne qualcosa rispetto al codice sorgente di cui sopra.
Il codice sorgente è utile (almeno
potenzialmente) per chiunque usi un programma. Ma alla maggioranza
degli utenti non è concesso avere copie di tale codice.
Normalmente il codice sorgente di un programma proprietario viene
tenuto segreto dal proprietario, prevenendo chiunque altro dall'impararne
qualcosa. Gli utenti ricevono unicamente i file di numeri incomprensibili
che il computer eseguirà. Ciò significa che soltanto
il proprietario di un programma può modificarlo.
Una volta un'amica mi raccontò di aver lavorato come programmatore
in una banca per circa sei mesi, scrivendo un programma simile
a qualcosa di commercialmente disponibile. Se avesse potuto avere
il codice sorgente di quel programma commerciale, avrebbe potuto
facilmente adattarlo alle necessità del caso. La banca
era disposta a pagare per questo, ma non le venne concesso --
il codice sorgente era un segreto. Così fu costretta a
lavorare in tal modo per sei mesi, lavoro che fa parte del prodotto
nazionale lordo ma che in realtà fu uno spreco.
Intorno al 1977 il laboratorio di intelligenza artificiale del
MIT ricevette in regalo una stampante grafica dalla Xerox. Era
gestita da un software libero a cui aggiungemmo parecchie funzioni
utili. Ad esempio, il software avrebbe notificato l'utente non
appena finito il lavoro di stampa. In caso di problemi, come l'inceppamento
dei fogli o la mancanza di carta, il software ne avrebbe informato
tutti gli utenti che avevano in corso una stampa. Queste funzioni
facilitavano il corso delle operazioni.
Più tardi la Xerox diede al laboratorio una stampante più
nuova e veloce, una delle prime stampanti laser. Veniva gestita
da un software proprietario che girava su un apposito computer
dedicato, in modo che non potemmo aggiungere alcuna delle nostre
opzioni favorite. Riuscimmo a sistemare l'invio di una notifica
quando la stampa veniva inviata al computer dedicato, ma non quando
avveniva effettivamente la stampa (e generalmente il ritardo era
considerevole). Non c'era alcun modo di sapere quando il lavoro
veniva realmente stampato, si poteva solo indovinare. E nessuno
veniva informato nel caso di fogli incastrati, così spesso
la stampante finiva fuori uso per un'ora.
Il sistema di programmatori del laboratorio di intelligenza artificiale
era in grado di sistemare simili problemi, probabilmente tanto
quanto gli autori originari del programma. Ma la Xerox non aveva
alcun interesse a risolverli, e scelse di impedircelo, di modo
da costringerci ad accettare tali problemi. Non vennero mai risolti.
Molti buoni programmatori hanno sperimentato una simile frustrazione.
La banca poteva permettersi di risolvere il problema scrivendo
un nuovo programma da zero, ma un comune utente, a prescindere
dalle proprie capacità, può soltanto rinunciare.
La rinuncia provoca un danno psico-sociale -- allo spirito della
fiducia in se stessi. È demoralizzante vivere in una casa
che non si può riarrangiare secondo i propri bisogni. Porta
a rassegnazione e scoraggiamento, che finiscono per colpire altri
aspetti della vita di una persona. Chi si trova in simili circostanze
diventa infelice e non fa un buon lavoro.
Immaginiamo come sarebbe qualora le ricette venissero trattate
alla stregua del software. Qualcuno potrebbe dire, "Come
faccio a modificare questa ricetta per toglierci il sale?"
e il grande cuoco risponderebbe, "Come osi insultare la mia
ricetta, il prodotto del mio cervello e del mio palato, cercando
di interferire? Non possiedi il giudizio necessario per poterla
modificare e farla funzionare bene!"
"Ma il dottore mi ha detto di non mangiare cibi salati!"
"Sarò contento di farlo. La mia tariffa è di
appena 50.000 dollari". (Dato che il proprietario ha il monopolio
sulle modifiche, la tariffa tende ad essere elevata). "Però
adesso non ho tempo. Sono occupato con una commissione per il
progetto di una nuova ricetta di biscotti per le navi con il Ministero
della Marina. Potrò occuparmi di te fra un paio d'anni."
Ostruire lo sviluppo del software
Il terzo livello di danno materiale colpisce
lo sviluppo del software. Solitamente questo era un processo evolutivo,
in cui una persona ne riscriveva delle parti per una nuova funzione,
e poi qualcun altro ne avrebbe riscritto altre parti per aggiungere
un'altra funzione; in alcuni casi, ciò andava avanti per
un periodo di vent'anni. Nel frattempo, parti del programma sarebbero
state "cannibalizzate" per dar forma alla nascita di
ulteriori programmi.
L'esistenza di proprietari impedisce un'evoluzione di questo tipo,
rendendo necessario partire da zero nello sviluppo di un programma.
Impedisce altresì a nuovi praticanti di studiare i programmi
esistenti onde imparare tecniche utili o anche la struttura di
programmi di ampie dimensioni.
I proprietari ostruiscono anche l'educazione. Ho incontrato brillanti
studenti d'informatica che non avevano mai visto il codice sorgente
di un programma di ampie dimensioni. Possono essere bravi a scrivere
piccoli programmi, ma non potranno acquisire le diverse capacità
necessarie per scriverne di grandi se non possono vedere come
hanno fatto gli altri.
In ogni ambito intellettuale, è possibile raggiungere altezze
maggiori stando sulle spalle di chi ci ha preceduti. Ma in genere
ciò non è più consentito nel campo del software
-- si può stare soltanto sulle spalle dei colleghi della
propria azienda.
Il danno psico-sociale associato colpisce lo spirito della cooperazione
scientifica, solitamente così solido tra i ricercatori
al punto che questi collaboravano anche quando i rispettivi paesi
erano in guerra tra loro. Sulla base di questo spirito, gli oceanografici
giapponesi abbandonati in un laboratorio su un'isola del Pacifico
conservarono con attenzione il lavoro svolto per i Marine statunitensi
in arrivo, lasciando una nota per chiedere loro di prendersene
cura.
I conflitti per denaro hanno distrutto quello che si era salvato
nei conflitti internazionali. Oggigiorno i ricercatori di molte
discipline non pubblicano dati sufficienti nelle proprie ricerche
onde consentire agli altri di replicare quegli esperimenti. Pubblicano
soltanto quanto basta per fare in modo che i lettori possano meravigliarsi
di quanto siano riusciti a ottenere. Ciò è sicuramente
vero per l'informatica, dove il codice sorgente dei programmi
su cui si scrive è generalmente segreto.
Non importa come si limiti la condivisione
Ho discusso finora gli effetti di prevenire
la gente dall'attività di copia, modifica e costruzione
su un programma. Non ho specificato il modo in cui questa ostruzione
viene portata avanti, perché ciò non ne influenza
la conclusione. Sia che ciò venga imposto tramite il divieto
di copia, o il diritto d'autore, o le licenze, o la crittazione,
o le schede ROM, o i numeri serali sull'hardware, se riesce a
impedirne l'utilizzo, allora procura dei danni.
Gli utenti considerano comunque alcuni di questi metodi più
sgradevoli di altri. Io suggerirei che i metodi più odiosi
sono quelli che raggiungono lo scopo prefissosi.
Il software dovrebbe essere libero
Fin qui ho illustrato il modo in cui la
proprietà di un programma -- il potere di limitarne la
modifica o la copia -- sia d'intralcio. I suoi effetti negativi
sono diffusi e importanti. Ne consegue che la società non
dovrebbe avere proprietari per i programmi.
Un altro modo di comprenderlo è che ciò di cui abbisogna
la società è il software libero, e il software proprietario
ne è un sostituto insoddisfacente. Incoraggiare i sostituti
non è un modo razionale di ottenere ciò di cui abbisogniamo.
Vaclav Havel ci ha messo sull'avviso dicendo, "Lavorare per
qualcosa perché è bene, non soltanto perché
si ha possibilità di riuscire". L'attività
di realizzare software proprietario contiene possibilità
di riuscita in termini ristretti, ma non è un bene per
la società.
Perché si sviluppa il software
Se eliminiamo il copyright come mezzo per incoraggiare la gente a sviluppare software, all'inizio se ne svilupperà di meno, ma tale software risulterà maggiormente utile. Non è chiaro se la soddisfazione generale degli utenti sarà minore; ma se così fosse, oppure se volessimo incrementarla comunque, esistono altri modi per incoraggiare lo sviluppo, proprio come esistono altri modi oltre i caselli a pedaggio per raccogliere denaro per la costruzione di strade. Prima di illustrare le modalità con cui ciò può esser fatto, vorrei affrontare la questione di quanto incoraggiamento artificiale sia davvero necessario.
Programmare è divertente
Ci sono alcuni tipi di lavori che pochi
accetterebbero se non per denaro; la costruzione di strade, ad
esempio. Esistono altri campi di studio e arte in cui esistono
scarse possibilità di diventare ricchi, ma che la gente
sceglie per il loro fascino o per il presunto valore agli occhi
della società. Gli esempi includono la logica matematica,
la musica classica, l'archeologia e l'attivismo politico organizzato
tra i lavoratori. La gente compete, più tristemente che
amaramente, per le poche posizioni pagate disponibili, nessuna
delle quali è remunerata granché. Qualcuno è
perfino disposto a pagare di tasca propria pur di lavorare in
quel campo, se può permetterselo.
Un certo settore può trasformarsi nel giro di una notte
se inizia ad offrire la possibilità di diventare ricchi.
Quando un lavoratore diventa ricco, altri chiedono la medesima
opportunità. Presto tutti potrebbero volere ingenti somme
di denaro per fare quel che erano soliti fare per il piacere.
Trascorsi un altro paio d'anni, chiunque coinvolto in quel campo
deriderà l'idea che si debba lavorare in quel settore senza
grossi ricavi economici. Spiegheranno ai pianificatori sociali
che è possibile assicurare tali ricavi, assegnando privilegi
sociali, poteri e monopoli man mano che si renderà necessario.
Questo il cambiamento avvenuto nel campo della programmazione
informatica durante lo scorso decennio. Quindici anni fa (7) giravano
articoli sulla "computer-dipendenza": gli utenti erano
"on-line" tutto il tempo e avevano vizi da cento a dollari
a settimana. In genere si accettava il fatto che la gente amava
a tal punto la programmazione da rompere non di rado il proprio
matrimonio. Oggi, in genere si accetta che nessuno farebbe il
programmatore se non in cambio di un lauto stipendio. La gente
ha dimenticato come stavano le cose quindici anni fa.
(7) Quindici anni prima della stesura di quest'articolo correva l'anno 1977.
Anche se fosse vero che ad un certo punto
la maggior parte della gente lavorerà in un certo campo
soltanto per un lauto stipendio, lo scenario non deve necessariamente
rimanere tale. La dinamica del cambiamento può girare all'inverso,
qualora la società fornisca l'impeto adatto. Se eliminiamo
la possibilità di grandi ricchezze, allora dopo qualche
tempo, una volta risistemate le attitudini personali, la gente
sarà nuovamente ansiosa di lavorare in quel campo per la
gioia di riuscire.
La domanda "Come fare a pagare i programmatori?" trova
facile risposta una volta compreso che non si tratta di pagarli
una fortuna. Il semplice guadagnarsi da vivere è più
facile da mettere insieme.
Finanziare il software libero
Le istituzioni che pagano i programmatori
non devono essere i produttori di software. Esistono già
parecchie altre istituzioni in grado di farlo.
I produttori di hardware considerano essenziale sostenere lo sviluppo
del software pur non potendone controllare l'utilizzo. Nel 1970
gran parte del loro software era libero perché non si curavano
di porre limitazioni. Oggi la crescente volontà di aderire
a dei consorzi dimostra che hanno compreso come possedere il software
non è una cosa veramente importante per loro.
Le università svolgono numerosi progetti di programmazione.
Oggi spesso ne rivendono i risultati, ma non così negli
anni '70. Esiste forse alcun dubbio che le università svilupperebbero
software libero qualora non fosse loro consentito di vendere il
software? Questi progetti potrebbero essere finanziati dagli stessi
contratti e borse di studio governativi che attualmente finanziano
lo sviluppo di software proprietario.
Oggi è comune per i ricercatori universitari ottenere borse
di studio per lo sviluppo di un sistema, realizzarlo fino quasi
al punto finale e definirlo "completato", per poi lanciare
delle aziende in cui portano davvero a compimento il progetto
e lo rendono usabile. Talvolta dichiarano "libera" la
versione non finita; se sono corrotti fino in fondo, ottengono
invece una licenza esclusiva dall'università. Ciò
non è certo un segreto, viene ammesso apertamente da ogni
soggetto coinvolto. Eppure se i ricercatori non fossero esposti
alla tentazione di comportarsi in questo modo, proseguirebbero
tuttora le proprie ricerche.
Gli sviluppatori che scrivono software libero possono guadagnarsi
da vivere vendendo servizi connessi al software. Io sono stato
assunto per portare il compiler GNU C su un nuovo hardware, e
per realizzare le estensioni dell'interfaccia-utente per GNU Emacs.
(Offrirò queste migliorie al pubblico una volta completate).
Insegno anche dei corsi per cui vengo pagato.
Non sono il solo a lavorare in tal modo; oggi esiste una corporation
di successo e in crescita che fa soltanto questi tipi di lavori.
Anche diverse altre aziende offrono supporto commerciale per il
software libero del sistema GNU. Questo è l'inizio dell'industria
a sostegno del software indipendente -- un'industria che potrebbe
raggiungere dimensioni piuttosto ampie se il software libero diventasse
prevalente. Ciò offre agli utenti un'opzione generalmente
non disponibile per il software proprietario, eccetto a chi è
molto ricco.
Nuove (8) istituzioni quali la Free Software Foundation possono
altresì sostenere i programmatori.
(8) Quest'articolo è stato scritto il 24 aprile 1992.
Gran parte dei finanziamenti della Foundation
arrivano dagli acquirenti di dischi e nastri tramite posta. Il
software sui nastri è libero, il che significa che ogni
utente ha libertà di copiarlo e modificarlo, ma in ogni
caso molti pagano per averne delle copie. (Ricordiamoci che "free
software" si riferisce alla libertà, non al prezzo).
Alcuni utenti già in possesso di una copia, ordinano i
nastri come modo per offrire l'obolo che secondo loro noi meritiamo.
La Foundation riceve inoltre donazioni di una certa ampiezza dai
produttori di computer.
La Free Software Foundation è un ente senza fini di lucro,
e i ricavi vengono spesi per ingaggiare quanti più programmatori
possibile. Se fosse stata impostata come attività commerciale,
distribuendo al pubblico lo stesso software libero per la medesima
cifra odierna, fornirebbe un'ottima fonte di sostentamento al
suo fondatore.
Essendo la Foundation un ente senza fini di lucro, spesso i programmatori
vi lavorano per metà della cifra che potrebbero chiedere
altrove. Lo fanno perché siamo liberi dalla burocrazia,
e perché sono soddisfatti nel sapere che il loro lavoro
non subirà ostruzioni nell'utilizzo. Ma soprattutto lo
fanno perché programmare è divertente. In aggiunta,
dei volontari non pagati hanno scritto per noi molti programmi
utili. (Abbiamo perfino scrittori tecnici volontari).
Ciò conferma come la programmazione sia tra i campi più
affascinanti di tutti, insieme alla musica e all'arte. Non dobbiamo
temere che non ci sarà gente che vorrà programmare.
Cosa devono gli utenti agli sviluppatori?
C'è una buona ragione per chi usa
il software di sentirsi moralmente obbligati a contribuire al
suo sostegno. Gli sviluppatori di software libero contribuiscono
alle attività degli utenti, e oltre che giusto è
nell'interesse a lungo termine degli stessi utenti dare loro i
finanziamenti per continuare.
Ciò tuttavia non si applica a chi sviluppa software proprietario,
perché l'ostruzionismo merita una punizione anziché
una ricompensa.
Eccoci così di fronte a un paradosso: chi sviluppa software
utile ha diritto al sostegno degli utenti, ma qualsiasi tentativo
di trasformare quest'obbligo morale in un requisito distrugge
le basi stesse di tale obbligo. Uno sviluppatore può meritare
o richiedere una ricompensa, ma non entrambe le cose.
Credo che di fronte a tale paradosso uno sviluppatore dotato di
senso etico deve fare in modo di meritare la ricompensa, ma dovrebbe
anche stimolare gli utenti alle donazioni volontarie. Alla fin
fine gli utenti impareranno a sostenere gli sviluppatori senza
costrizione, così come hanno imparato a sostenere le stazioni
radio e televisive pubbliche.
Cos'è la produttività del software?
Se il software fosse libero, esisterebbero
ancora i programmatori, ma forse in numero minore. Ciò
sarebbe un male per la società?
Non necessariamente. Oggi le nazioni avanzate hanno meno agricoltori
che nel 1900, ma non lo consideriamo un male per la società,
visto che un numero minore offre ai consumatori una quantità
maggiore di cibo. Ciò viene definito miglioramento produttivo.
Il software libero richiederebbe un numero assai minore di programmatori
per soddisfare la domanda, per via dell'accresciuta produttività
del software a tutti i livelli:
- Utilizzo più ampio di ciascun programma sviluppato.
- Capacità di adattare i programmi esistenti per la personalizzazione,
invece di partire da zero.
- Migliore educazione dei programmatori.
- L'eliminazione dei doppioni nei progetti di sviluppo.
Quanti si oppongono alla cooperazione sostenendo che provocherebbe
l'assunzione di un numero minore di programmatori vanno in realtà
opponendosi alla maggiore produttività. Eppure costoro
generalmente accettano la credenza comune secondo cui l'industria
del software necessiti un incremento produttivo. Come mai? (9)
(9) Secondo Eric Raymond, il 95% dei posti di lavoro dell'industria del software riguarda la produzione di software personalizzato, nient'affatto previsto per la pubblicazione. Ne consegue che pur assumendo lo scenario teorico peggiore, ovvero che non esisteranno posti di lavoro per lo sviluppo di software libero (e già sappiamo che ne esistono alcuni), il passaggio al software libero potrà avere uno scarso effetto sul numero totale di posti di lavoro per il software. Esiste una gran quantità di spazio per chi voglia scrivere software personalizzato e sviluppare software libero quando avanza tempo. Non esiste alcun modo per sapere se la piena conversione al software libero porterebbe all'aumento o alla diminuzione del numero di posti di lavoro nel campo del software.
La "produttività del software" può avere due significati diversi: la produzione complessiva dell'intero settore di sviluppo del software oppure la produttività di progetti individuali. La produttività complessiva è quel che la società vorrebbe migliorare, e la maniera più diretta per farlo è eliminare gli ostacoli artificiali alla cooperazione che riducono tale produttività. Ma i ricercatori che studiano il campo della "produttività del software" si concentrano unicamente sul secondo, limitato, significato del termine, dove il miglioramento richiede difficili avanzamenti tecnologici.
La competizione è inevitabile?
È inevitabile che si cerchi di competere,
di sorpassare i propri rivali nella società? Forse lo è.
Ma la competizione in se stessa non è dannosa; la cosa
dannosa è il combattimento.
Esistono molti modi di competere. La competizione può consistere
nel cercare di raggiungere sempre di più, di superare quel
che hanno fatto gli altri. Ad esempio, in passato c'era competizione
tra i maghi della programmazione -- competizione per chi riusciva
a far fare al computer le cose più incredibili, o per chi
riusciva a creare il programma più breve o più veloce
per un particolare compito. Questo tipo di competizione può
giovare a chiunque, fintantoché si mantiene lo spirito
della buona lealtà sportiva.
La competizione costruttiva è sufficientemente competitiva
da spingerci a fare grandi sforzi. Un certo numero di persone
stanno gareggiando per essere i primi ad aver visitato tutti i
paesi sulla terra; qualcuno spende anche una fortuna nel tentativo
di riuscirci. Ma non cercano di corrompere i capitani delle navi
perché abbandonino i rivali su un isola deserta. Sono contenti
di lasciar vincere la persona più in gamba.
La competizione diventa lotta quando coloro che gareggiano iniziano
a bloccarsi a vicenda invece di pensare al proprio avanzamento
-- quando "lasciar vincere la persona più in gamba"
si trasforma in "lascia vincere me stesso, più in
gamba o meno che sia". Il software proprietario è
dannoso, non perché sia una forma di competizione, ma perché
è una forma di combattimento tra i cittadini della società.
Nell'imprenditoria competizione non significa necessariamente
lotta. Ad esempio, quando due negozi di alimentari sono in competizione,
i loro sforzi si concentrano sul miglioramento delle proprie operazioni,
non sul sabotaggio del rivale. Ma ciò non dimostra un particolare
attaccamento all'etica commerciale; piuttosto, ha poco senso combattere
in questo tipo di attività senza ricorrere alla violenza
fisica. Non tutti i settori imprenditoriali condividono questa
caratteristica. Tenere segrete informazioni che potrebbero aiutare
tutti ad avanzare è una forma di combattimento.
L'ideologia commerciale non prepara la gente a resistere alla
tentazione di lottare come forma di competizione. Alcuni tipi
di combattimento sono stati vietati con legislazioni anti-monopolio,
leggi sulla veridicità della pubblicità, e così
via, ma anziché generalizzare ciò in un principio
di rifiuto della lotta in generale, i dirigenti hanno inventato
altre forme di combattimento che non sono specificamente proibite.
Le risorse della società vengono sperperate nell'equivalente
economico di una guerra civile tra fazioni.
"Perché non te ne vai in Russia?"
Negli Stati Uniti chiunque sostenga qualsiasi
posizione diversa dalla forma più estrema di laissez-faire
egoistico ha sentito spesso quest'accusa. Viene ad esempio usata
contro i sostenitori di un sistema nazionale d'assistenza sanitaria,
come ne esistono in tutte le altre nazioni industrializzate del
mondo libero. Viene usata contro i sostenitori del sostegno pubblico
alle arti, anch'esso universale nei paesi avanzati. In America
l'idea che i cittadini abbiano qualche obbligo nei confronti del
bene pubblico viene identificata con il comunismo. Ma si tratta
davvero di idee similari?
Il comunismo per come fu praticato nell'Unione Sovietica era un
sistema di controllo centralizzato dove tutta l'attività
era irreggimentata, apparentemente per il bene comune, ma in realtà
a vantaggio dei membri del partito comunista. E dove i dispositivi
per la copia erano sorvegliati da vicino onde evitare la copia
illegale.
Il sistema americano del diritto d'autore sul software impone
il controllo centralizzato sulla distribuzione di un programma,
e i dispositivi per la copia sono sorvegliati tramite sistemi
anti-copia automatici onde evitare la copia illegale.
All'opposto, il mio lavoro punta alla costruzione di un sistema
in cui la gente sia libera di decidere sulle proprie azioni; in
particolare, libera di aiutare i vicini, e libera di alterare
e migliorare gli strumenti che usano nella vita quotidiana. Un
sistema basato sulla cooperazione volontaria e sulla decentralizzazione.
Perciò, se dovessimo giudicare le posizioni sulla somiglianza
al comunismo russo, sarebbero i proprietari di software a essere
comunisti.
La questione delle premesse
In questo saggio parto dalla premessa che
l'utente di software non sia meno importante di un autore, o anche
del datore di lavoro di un autore. In altri termini, gli interessi
e le necessità di tutti costoro hanno un uguale peso quando
si tratta di decidere il miglior corso d'azione. Questa premessa
non è accettata a livello universale. Molti sostengono
come il datore di lavoro di un autore sia essenzialmente più
importante di chiunque altro. Si dice, ad esempio, che lo scopo
nell'avere proprietari di software è quello di dare al
datore di lavoro di un autore il vantaggio che merita -- prescindendo
dal modo in cui ciò possa influenzare il pubblico.
È inutile cercare di convalidare o confutare tali premesse.
Ogni prova si basa su premesse condivise. Perciò gran parte
di quanto vado sostenendo è indirizzato soltanto a quanti
condividono le premesse che uso, o almeno a quanti sono interessati
a vederne le conseguenze. Per quanti ritengono che i proprietari
siano più importanti di chiunque altro, questo saggio è
semplicemente irrilevante.
Ma perché un gran numero di americani dovrebbe accettare
una premessa che eleva l'importanza di alcuni individui su chiunque
altro? In parte perché ci si basa sulla credenza che tale
premessa faccia parte della tradizione legale della società
americana. Per qualcuno, dubitare della premessa significa mettere
in discussione le basi stesse della società.
È importante informare costoro che tale premessa non è
parte della nostra tradizione legale. Né lo è mai
stata.
Ovvero, la Costituzione dice che lo scopo del copyright è
quello di "promuovere il progresso della scienza e delle
arti utili". La Corte Suprema ha elaborato su quest'idea,
affermando nella causa Fox Film vs. Doyal che "l'unico
interesse degli Stati Uniti e l'oggetto primario nel conferire
il monopolio [del copyright] risiede nei benefici generali derivanti
al pubblico dal lavoro degli autori".
Non siamo obbligati a essere d'accordo con la Costituzione o con
la Corte Suprema. (A un certo punto, entrambi perdonarono la schiavitù).
Le loro posizioni non condannano la premessa sulla supremazia
del proprietario. Spero però che la consapevolezza per
cui ciò sia un assunto della destra radicale, piuttosto
che un fatto tradizionalmente riconosciuto, perderà il
proprio fascino.
Conclusione
Ci piace pensare che la società incoraggi
l'aiuto al vicino; ma ogni volta che ricompensiamo qualcuno perché
fa ostruzione, o li ammiriamo per la ricchezza accumulata in tal
modo, stiamo inviando il messaggio opposto.
L'accumulazione del software è una forma della nostra volontà
generale di non considerare il benessere della società
a favore del profitto personale. Possiamo notare questa mancanza
di considerazione da Ronald Reagan a Jim Bakker (10), da Ivan
Boesky (11) a Exxon (12), dalle banche fallite alle scuole fallite.
Possiamo misurarla con la quantità di gente senza casa
e di popolazione carceraria. Lo spirito antisociale si nutre da
solo, perché più ci rendiamo conto che gli altri
non ci aiuteranno, più sembra futile aiutarli. Così
la società si trasforma in una giungla.
Se non vogliamo vivere in una giungla, dobbiamo modificare il
nostro atteggiamento. Dobbiamo iniziare a veicolare il messaggio
che un buon cittadino è quello che coopera quando appropriato,
non quello che è bravo a prendere dagli altri. Spero che
il movimento del software libero possa offrire dei contributi
in tal senso: almeno in un campo, sostituiremo la giungla con
un sistema più efficace che incoraggi e giri sulla cooperazione
volontaria.
(10) Negli anni '80 Jim Bakker raccolse milioni di dollari in televisione per i suoi gruppi religiosi Heritage USA, PTL e Inspirational Network. Venne condannato a 45 anni di carcere per frode via posta e banca per le campagne di raccolta fondi a favore di PTL.
(11) Ivan Boesky fu mandato in prigione e multato per 100 milioni di dollari per trading scorretto negli anni '80. Divenne famoso per aver detto una volta, "L'avarizia è un bene. Voglio farvi sapere che ritengo salutare l'avarizia. Potete essere avari e sentirvi comunque in pace con voi stessi".
(12) Negli anni '80 la Exxon Valdez provocò la più vasta fuoriuscita di petrolio al mondo al largo delle coste dell'Alaska, causando danni immensi. Finora le multe e le operazioni di pulizia gli sono costate oltre un miliardo di dollari.
----
Originalmente scritto nel 1992, questa versione fa parte del libro Free Software, Free Society: The Selected Essays of Richard M. Stallman, GNU Press, 2002.
La copia letterale e la distribuzione di questo testo nella sua integrità sono permesse con qualsiasi mezzo, a condizione che sia mantenuta questa nota.