Software libero pensiero libero/Volume II/Parte prima/Perché il software dovrebbe essere libero
 |
Questo testo è completo. | |
Traduzione dall'inglese di Bernardo Parrella (2003)
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.
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'utilizzo2.
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 desiderabile3.
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 Reagan4, 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.
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 piano5:
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 eseguibile6, sul computer che uso normalmente:
1314258944 -232267772 -231844864 1634862
1411907592 -231844736 2159150 1420296208
-234880989 -234879837 -234879966 -232295424
1644167167 -3214848 1090581031 1962942495
572518958 -803143692 1314803317Il 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."
Impedire 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 fa7 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.
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.
Nuove8 istituzioni quali la Free Software Foundation possono altresì sostenere i programmatori.
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 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 Bakker10, da Ivan Boesky11 a Exxon12, 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.
Note
- ↑ 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.
- ↑ 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.
- ↑ 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.
- ↑ 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.
- ↑ 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.
- ↑ Si noti l'incomprensibilità del codice eseguibile; è chiaramente più difficile capirne qualcosa rispetto al codice sorgente di cui sopra.
- ↑ Quindici anni prima della stesura di quest'articolo correva l'anno 1977.
- ↑ Quest'articolo è stato scritto il 24 aprile 1992.
- ↑ 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.
- ↑ 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.
- ↑ 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".
- ↑ 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.