Re: [www-it-traduzioni] Fwd: Traduzione di "Why Software Should Be Free"

[Andrea Pescetti]

Cristian Consonni ha scritto:
> "Why Software Should Be Free"[1] di Stallman...
> Ho scoperto quindi che non esiste una traduzione in italiano di quel
> saggio (molti altri, invece, sono tradotti) ed ho iniziato a tradurlo
> qui:
> https://etherpad.wikimedia.org/p/WhySoftwareShouldBeFree
> [1] http://www.gnu.org/philosophy/shouldbefree.html

Ciao Cristian, e benvenuto su questa lista. Come vedi dall'archivio su 
http://lists.gnu.org/archive/html/www-it-traduzioni/ negli ultimi mesi 
l'attivita' e' stata modesta, ad eccezione delle relazioni che ho 
inviato durante le vacanze. Ma quando serve ci riattiviamo.

Veniamo al saggio in questione. Hai ragione, su gnu.org non c'e' ancora 
la traduzione italiana. Ma come vedi nell'ultima riga del link che hai 
indicato, il saggio fa parte di "Free Software, Free Society".

Andiamo indietro di molti anni e non so tutti i dettagli (forse 
addirittura non usavamo ancora questa mailing list), ma quel libro e' 
stato tradotto in italiano da Bernardo Parrella nel 2003-2004 e messo a 
disposizione con una licenza che potevamo usare:
http://www.stampalternativa.it/libri/754-4/richard-stallman/software-libero.html
http://www.stampalternativa.it/libri/786-2/richard-stallman/software-libero-pensiero.html
http://it.wikisource.org/wiki/Software_libero_pensiero_libero
(queste risorse non esistevano all'epoca, le ho ritrovate adesso)

In particolare all'ultimo link ci sono molti saggi tradotti. Ma non questo.

Dato che oggi e' il tuo giorno fortunato, sull'hard disk ho trovato un 
archivio del 2008 che e' la versione elettronica del libro di Bernardo e 
contiene anche questa traduzione. Trovi il "links -dump -width 65" sotto 
questo messaggio.

Ora, c'e' un motivo per cui non tutte le traduzioni di Bernardo sono 
state caricate su gnu.org, ed e' sostanzialmente che lo stile che usa 
non e' sempre conforme a quello che usiamo noi (e inoltre alcuni saggi 
di gnu.org vengono modificati negli anni per rendere alcuni paragrafi 
piu' chiari o aggiornare gli esempi). Ma basta una revisione e lo si 
puo' pubblicare.

Insomma, un modo in cui potresti aiutarci e': rileggi la traduzione qui 
sotto e confrontala con l'originale, notando le differenze ed eventuali 
errori presenti. Nella rilettura tieni presente che noi, come hai fatto 
tu nella tua bozza appena iniziata, traduciamo "should" con "deve" e non 
con "dovrebbe", e di solito traduciamo "you" come impersonale ("you 
shouldn't accept" -> "non si deve accettare"). Per la terminologia usa 
anche questo testo analogo: 
http://www.gnu.org/philosophy/why-free.it.html (noterai che ad esempio 
"owners" e' reso come "padroni" anziche' "proprietari", per rispettare 
lo spirito con cui veniva usato in quel contesto). Poi inviaci il 
risultato (sempre in un normalissimo messaggio di posta elettronica di 
testo semplice, non serve nulla di piu': ci farai avere il testo 
aggiustato e un elenco delle differenze rispetto alla versione 
precedente). Infine convertiremo la traduzione in file PO e la 
pubblicheremo su gnu.org.

Ciao e grazie,
  Andrea.

   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.