The Danger of software patents
http://www.cl.cam.ac.uk/~mgk25/stallman-patents.html

----------

Il pericolo dei brevetti sul software

Credo siate a conoscenza del mio lavoro a sostegno del software libero. L'intervento odierno non riguarda questo tema, ma affronta la questione degli abusi legislativi tesi a trasformare lo sviluppo del software in un'attività pericolosa. Questo è ciò che accade quando le norme sui brevetti vengono applicate al campo del software.
Il punto non è la brevettabilità del software. Una simile descrizione sarebbe decisamente errata ed equivoca, perché non si tratta di brevettare dei programmi singoli. Se così fosse, non farebbe alcuna differenza, sarebbe qualcosa di fondamentalmente innocuo. La questione riguarda invece la brevettabilità delle idee. Ciascun brevetto copre qualche idea. I brevetti sul software sono brevetti che coprono qualche idea sul software, idee che prevediamo di usare nello sviluppo del software. In tal senso ciò rappresenta un ostacolo pericoloso per lo sviluppo del software nella sua interezza.
Forse avrete sentito qualcuno usare un termine ingannevole, "proprietà intellettuale". Come potete notare, questa definizione è basata su un pregiudizio: dà per scontato che, qualunque sia il tema in discussione, il modo di trattarlo è considerarlo una sorta di proprietà, mentre in realtà è soltanto una delle molte alternative disponibili. Il termine "proprietà intellettuale" si pone come pregiudiziale sulle questioni fondamentali di qualsiasi tematica ci si stia occupando. Ciò non porta a considerazioni chiare e aperte.
Esiste un ulteriore problema in quel termine, il quale non ha nulla a che fare con la promozione delle opinioni personali: è d'intralcio nella comprensione perfino dei fatti. L'espressione "proprietà intellettuale" viene usata come una sorta di panacea generale: raggruppa insieme aree del tutto disparate del corpo legislativo quali il copyright (noto anche come diritto d'autore) e i brevetti, ambiti completamente diversi tra loro che differiscono in ogni dettaglio. Nel mucchio finiscono anche i marchi registrati, qualcosa di ulteriormente diverso, e altri elementi in cui ci s'imbatte più di rado. Nessuno di questi settori ha nulla in comune con gli altri. Storicamente hanno origini completamente distinte; le rispettive legislazioni furono progettate in maniera indipendente; interessano ambiti diversi della vita e delle comuni attività. Le questioni di politica pubblica che sollevano non presentano alcuna relazione tra loro, di modo che cercando di affrontarli come un unico insieme è garantito il raggiungimento di conclusioni folli. È letteralmente impossibile avere un'opinione motivata e intelligente sulla "proprietà intellettuale". Perciò se si vuole considerare la questione con chiarezza, evitiamo di fare d'ogni erba un fascio. Meglio affrontare il copyright di per sé, e poi occuparsi dei brevetti. Impariamo a conoscere le norme sul copyright, e separatamente quelle sui brevetti.

Queste alcune delle maggiori differenze esistenti tra copyright e brevetti:
- Il copyright concerne i dettagli dell'espressione di un opera, ma non copre alcuna idea. I brevetti riguardano soltanto le idee e il loro utilizzo.
- Il copyright è automatico. I brevetti vengono concessi dal relativo ufficio in risposta a un'apposita richiesta.
- I brevetti sono molto onerosi. In realtà le spese degli avvocati per la stesura della richiesta sono perfino più esose della domanda stessa. Normalmente occorrono alcuni anni prima che la richiesta venga presa in considerazione, anche se i vari uffici brevetti lavorano in maniera estremamente lenta nell'esame delle domande.
- La durata del copyright è tremendamente lunga. In alcuni casi si arriva anche a 150 anni. I brevetti durano 20 anni, periodo breve rispetto alla vita umana ma comunque eccessivo per i ritmi di un settore come quello del software. Basti pensare a 20 anni fa, quando il PC era qualcosa di nuovo. Immaginiamo di dover essere costretti a sviluppare software utilizzando soltanto i concetti conosciuti nel 1982.
- Il copyright copre unicamente la copia. Se qualcuno scrive un romanzo che si scopre essere identico parola per parola a Via col vento, potendo al contempo dimostrare di non averlo mai visto, ciò rappresenterebbe un'ottima difesa contro ogni accusa di infrazione al copyright.
- Un brevetto è un monopolio assoluto sull'utilizzo di un'idea. Anche potendo dimostrare di aver avuto quell'idea per conto proprio, ciò sarebbe del tutto irrilevante se quell'idea è stata già brevettata da qualcun altro.

Spero possiate dimenticarvi del copyright per il resto del mio intervento, perché parlerò invece dei brevetti, e le due questioni non dovrebbero mai essere messe insieme - unica possibilità per comprendere con chiarezza le rispettive questioni legali. Pensiamo a cosa potrebbe accadere nella comprensione della chimica pratica (o dell'arte culinaria) se dovessimo confondere l'acqua con l'etanolo.
Quando si sente qualcuno parlare del sistema dei brevetti, normalmente questo viene descritto dal punto di vista di chi speri di ottenere un brevetto - le procedure che bisognerebbe eventualmente seguire per richiederlo, la sensazione che si proverebbe nel camminare per strada avendone uno in tasca, in modo da tirarlo fuori ogni tanto e sbatterlo in faccia a qualcuno dicendo: "Dammi tutti i soldi che hai!"
C'è una ragione dietro questi pregiudizi, perché la maggior parte di quanti ci descrivono il sistema dei brevetti vanta qualche tipo di interesse in tale sistema, perciò ce ne dipingono i tratti piacevoli. Esiste un'ulteriore motivazione: il sistema dei brevetti somiglia parecchio a una lotteria, perché soltanto una minima parte dei brevetti porta effettivamente qualche beneficio ai rispettivi possessori. Non casualmente una volta la rivista The Economist lo ha paragonato a una "lotteria spreca-tempo". Se avete dato un'occhiata alle inserzioni pubblicitarie delle lotterie, avrete notato come queste ci spingano sempre a pensare alla possibilità di vincere. Non invitano certo a considerare l'eventualità di perdere, pur essendo questa la probabilità più concreta. Lo stesso vale per il sistema dei brevetti: vengono sempre presentati come un invito a considerarci tra i vincitori.
Per controbilanciare questa serie di pregiudizi, mi accingo a descrivere il sistema dei brevetti dal punto di vista delle vittime -- ovvero, dal punto di vista di qualcuno che vuole sviluppare del software ma è costretto a ma è costretto a convivere con un sistema di brevetti sul software che potrebbe risultare in una denuncia.

Dunque, qual'è la prima cosa da fare dopo aver avuto un'idea sul tipo di programma che ci si appresta a scrivere? Tanto per cominciare, dovendo aver a che fare con il sistema dei brevetti, si potrebbe cercare di scoprire quali siano i brevetti che coprono il futuro programma. Compito impossibile. Il motivo è che alcune delle domande pendenti sono segrete. Possono essere pubblicate soltanto dopo un certo tempo dalla presentazione, qualcosa tipo 18 mesi. Si tratta tuttavia di un periodo più che sufficiente per scrivere un programma, e finanche per distribuirlo, senza poter conoscere se sia già coperto da brevetto o meno, e rischiare di conseguenza la denuncia.
Non è una faccenda puramente accademica. Nel 1984 venne realizzato compress, un programma per la compressione dei dati. All'epoca non esistevano brevetti sull'algoritmo di compressione LZW usato in quel programma. Più tardi, nel 1985, l'ufficio statunitense diffuse un brevetto su tale algoritmo, e nel corso degli anni successivi coloro che ne curavano la distribuzione iniziarono a ricevere minacce legali. Era impossibile per l'autore dell'algoritmo di compressione prevedere che potesse subire una denuncia. Non aveva fatto altro che usare un'idea trovata in una pubblicazione, proprio come era sempre successo tra i programmatori. Non aveva capito che non era più possibile usare liberamente un'idea trovata in qualche pubblicazione.

Dimentichiamo questo problema. I brevetti approvati vengono pubblicati dall'apposito ufficio, così da poterne reperire il lungo elenco e vedere con esattezza cosa dicono. Ovviamente, in realtà è impossibile leggere la lista per intero, perché ne comprende una quantità enorme. Negli Stati Uniti esistono centinaia di migliaia di brevetti sul software. Non c'è alcun modo di tener traccia di tutte le aree coperte. L'unica possibilità è provare a cercare quelli più rilevanti.
Qualcuno sostiene che dovrebbe trattarsi di un compito semplice nell'attuale epoca informatica. Si può ricorrere a ricerche per parole chiave e così via, ma ciò funziona soltanto fino a un certo punto. Si troveranno alcuni brevetti riguardanti l'area d'interesse, ma non necessariamente tutti.
Ad esempio, c'era un brevetto sul software (che oggi potrebbe essere estinto) relativo alle operazioni di ricalcolo secondo l'ordine naturale per i fogli di calcolo elettronici. In pratica ciò significa che facendo dipendere determinate celle da altre precedenti, si procede sempre al ricalcolo di tutti gli elementi inseriti dopo quelli da cui dipendevano, in modo che dopo ogni operazione il totale risulta sempre aggiornato. Nei primi fogli di calcolo elettronici si procedeva dall'alto verso il basso, e facendo dipendere una cella da quella sottostante, impostando al contempo una serie di simili passaggi, occorreva ricalcolare il totale svariate volte per far propagare il nuovo valore verso l'alto. (Si presupponeva che ogni elemento dipendesse dalla cella sovrastante).
Allora qualcuno ha pensato, perché non rifare i calcoli in modo che ogni valore venga ricalcolato immediatamente dopo quello da cui dipende? Questo algoritmo è conosciuto col nome di classificazione topologica. Il primo riferimento che sono riuscito a trovare è datato 1963. Il brevetto copriva diverse dozzine di modalità in cui si poteva implementare la classificazione topologica.
Non era tuttavia possibile reperire tale brevetto cercando con "fogli di calcolo elettronici". Né lo si trovava provando con "ordine naturale" oppure "classificazione topologica". La spiegazione non comprendeva nessuno di questi termini. Veniva in realtà descritto come un metodo per "compilare formule in codici oggetto". Quando lo vidi per la prima volta non credevo fosse quello giusto.

Supponiamo di trovarci davanti a un elenco di brevetti e di volerci rendere conto di quel che sia consentito fare. Quando si prova a studiarne le descrizioni, si scopre che sono molto difficili da comprendere, poiché sono scritte in un tortuoso linguaggio legale il cui significato è tutt'altro che facile da capire. Spesso quanto dice l'ufficio brevetti ha un significato diverso da quello apparente.
Negli anni '80 il governo australiano ha condotto una ricerca sul sistema dei brevetti. La conclusione fu che, al di là delle pressioni internazionali, non c'era alcun motivo per l'esistenza di un tale sistema -- non portava alcun giovamento al pubblico -- e ne raccomandava l'abolizione, se non fosse per le pressioni internazionali. Lo studio riportava che gli ingegneri non cercavano neppure di leggere i brevetti per imparare qualcosa, consideratane la difficoltà di comprensione. Veniva citata l'opinione di un ingegnere: "Non riesco a riconoscere le mie stesse invenzioni in linguaggio brevettese."
Questo non è uno scenario teorico. Verso il 1990 un programmatore di nome Paul Heckel denunciò la Apple, sostenendo che Hypercard infrangeva un paio di suoi brevetti. Quando lo vide per la prima volta, gli sembrò che Hypercard non avesse nulla a che fare con quei brevetti, con le sue "invenzioni". Non pareva simile a queste. Ma quando l'avvocato gli fece notare che quei brevetti potevano essere interpretati a coprire una parte di Hypercard, decise di attaccare la Apple. Nel corso di un mio successivo intervento a Stanford menzionai quella circostanza, con Heckel presente tra il pubblico. Mi interruppe per ribattere: "Non è vero, è solo che non compresi la portata della tutela legale!" Io replicai: "Si, proprio quello che intendevo dire."
Così, in pratica occorre spendere un sacco di tempo a parlare con gli avvocati per capire quel che i brevetti proibiscono di fare. Alla fine se ne usciranno con qualcosa tipo: "Se fai qualcosa in quest'area, sei sicuro di perdere; se intervieni in quest'altra area (Stallman fa dei gesti circolari con le mani), in sostanza si rischia di perdere; e se vuoi essere davvero al sicuro, meglio star lontano da quest'area (facendo gesti circolari più ampi). E tieni comunque conto che qualsiasi denuncia comporta qualche elemento di rischio sostanziale".
Ora che avete un terreno prevedibile su cui basare i vostri affari(!), cosa pensate di fare? Bé, si può scegliere fra tre diverse eventualità, ciascuna delle quali è applicabile in determinate circostanze. Eccole:

1) evitare il brevetto;
2) ottenere la licenza per il brevetto;
3) ribaltare il brevetto in tribunale.

Consentitemi di illustrare questi tre scenari per capire cosa li renda praticabili o meno.

Evitare il brevetto

"Evitare il brevetto" vuol dire non usare l'idea già coperta da qualche brevetto. Posizione semplice o difficile da seguire, dipende dal tipo di idea in oggetto.
In alcuni casi, soltanto una funzione risulta brevettata. In tal caso si può eludere il brevetto evitando di implementarla. Il punto sta nell'importanza di tale funzione. In alcune situazioni, se ne può fare a meno. Tempo fa gli utenti dell'elaboratore testi XyWrite vennero notificati di un downgrade (declassamento) del programma. Ne fu rimossa una funzione che consentiva la predefinizione delle abbreviazioni. Ovvero, quando si digitava un'abbreviazione seguita da un carattere d'interpunzione, questa sarebbe stata immediatamente sostituita dalla relativa espansione. In tal modo per alcune frasi lunghe era possibile definire l'abbreviazione, digitare soltanto quest'ultima e l'intera frase sarebbe apparsa nel documento. Gli sviluppatori mi scrissero riguardo questa opzione perché sapevano che l'editor Emacs presentava una funzione analoga. Infatti ne faceva parte fin dagli anni '70. Fu interessante perché ciò dimostrò che in vita mia avevo avuto almeno un'idea meritevole di essere brevettata. Posso affermarlo con certezza perché poco tempo dopo è proprio quel che fece qualcun altro!
In realtà gli sviluppatori considerarono tutte e tre le strategie. Prima tentarono di negoziare con il detentore del brevetto, il quale si rivelò trattare in cattiva fede. Poi analizzarono le probabilità concrete di poter ribaltare il brevetto in tribunale. Alla fine decisero che la cosa da fare fosse l'eliminazione di quella funzione. È possibile farne a meno. Se l'elaboratore testi difetta di quest'unica opzione, forse gli utenti continueranno a utilizzarlo ugualmente. Ma se le mancanze cominciano ad accumularsi, alla fine si avrà un programma non troppo soddisfacente, ed è probabile venga ignorato.
In questo caso si trattava di un brevetto limitato su una funzione assai specifica. Come la mettiamo con il brevetto in possesso di British Telecom sugli hyperlink [i link del world wide web] accoppiato con l'accesso tramite la comune chiamata telefonica? Il ricorso agli hyperlink è assolutamente essenziale nell'odierno uso del computer, al pari della connessione via telefono. Come faremmo senza tale opzione? Per chiarezza, questa non può neppure considerarsi una singola funzione, bensì la combinazione di due opzioni arbitrariamente interconnesse tra loro. Qualcosa di analogo al possesso di un brevetto su divano e televisione in una stessa stanza.

Talvolta l'idea brevettata appare talmente vasta e basilare che praticamente finisce per coprire un intero settore. È ad esempio il caso della crittazione a chiave pubblica, il cui brevetto statunitense è scaduto nel 1997. Fino ad allora fu quel brevetto ad impedire per la maggior parte il ricorso alla crittazione a chiave pubblica negli Stati Uniti. Un certo numero di programmi in corso di lavorazione vennero bloccati -- non furono mai realmente disponibili perché i detentori del brevetto presero a minacciarne gli autori. Poi ne uscì fuori uno, PGP, che inizialmente venne distribuito come software libero. In questo caso sembra che i possessori del brevetto lasciarono passare del tempo prima di minacciare la denuncia, e a quel punto si resero conto della cattiva pubblicità che avrebbero potuto subire. Così imposero delle restrizioni, rendendolo disponibile soltanto per usi non-commerciali, onde impedirne l'eccessiva diffusione. In tal modo per un decennio e oltre l'uso della crittazione a chiave pubblica venne fortemente limitato. Non c'era modo di superare quel brevetto. Era impossibile inventarsi qualcos'altro per scrivere programmi di crittazione a chiave pubblica.

Altre volte viene brevettato un algoritmo specifico. Esiste ad esempio un brevetto su una versione ottimizzata del Fast Fourier Transform, grazie al quale quest'ultimo gira a velocità doppia. Per evitarlo basta usarne una comune versione, anche se questa parte del programma impiegherà il doppio del tempo. Forse non è poi una funzione così importante, forse ciò riguarda una parte minima del tempo totale in cui gira il programma. Anche se è due volte più lento, può darsi che nessuno se ne accorga. Oppure, al contrario, il programma non si lancerebbe affatto perché richiede il doppio del tempo reale per operare come previsto. Gli effetti possono variare.
In qualche caso si può cercare un algoritmo migliore. Ciò può tornare utile o meno. Non potendo usare 'compress' all'interno del progetto GNU, iniziammo a cercare un algoritmo alternativo adatto alla compressione dati [compress è una utility per i sistemi Unix con algoritmo brevettato, per cui non poteva essere utilizzata nel progetto GNU: il brevetto avrebbe posto una limitazione alla redistribuzione, rendendo impossibile distribuire il software con licenza GPL].
Qualcuno ci informò di averne uno disponibile; aveva scritto un programma e decise di offrircelo come contributo. Eravamo sul punto di distribuirlo. Per pura coincidenza mi capitò di vedere una copia del New York Times che casualmente aveva la rubrica settimanale dedicata ai brevetti. (Non sfogliavo quel quotidiano più di una volta ogni paio di mesi). Così inizio a dargli un'occhiata e leggo che qualcuno aveva ottenuto un brevetto per "aver inventato un nuovo metodo per la compressione dei dati". Decido che è meglio capire come stanno le cose. Ne prendo una copia e scopro che tale brevetto copriva proprio il programma che ci apprestavamo a distribuire nel giro di una settimana. Il programma morì prima ancora di esser nato.
In seguito trovammo un altro algoritmo non coperto da brevetto. Divenne il programma gzip, oggi l'efficace standard de facto per la compressione dati. Come algoritmo per essere usato in simili programmi, risultò perfetto. Chiunque volesse ricorrere alla compressione dei dati poteva usare gzip invece di compress.

Lo stesso algoritmo di compressione già brevettato LZW veniva impiegato anche in formati per immagini, tra cui GIF. Ma in questo caso, poichè la gente non voleva semplicemente comprimere dei dati bensì avere un'immagine che fosse possibile visualizzare con il proprio software, si rivelò estremamente difficile trovare un algoritmo diverso. Non ci siamo ancora riusciti dopo 10 anni! Si, gli utenti ricorrevano all'algoritmo 'gzip' con cui definire un altro formato per l'immagine, una volta piovute minacce di possibili denuncie per l'uso di file GIF. Quando iniziammo a dire in giro di smetterla di usare quei file GIF per passare all'altro formato, la replica fu: "Non possiamo cambiare, il browser non supporta ancora il nuovo formato". Gli sviluppatori di browser ribatterono: "Non abbiamo alcuna fretta, dopo tutto nessuno usa quel formato".
In effetti la società ha dimostrato così tanta inerzia nell'utilizzo del formato GIF che non siamo riusciti a convincere la gente a cambiare. In pratica il continuo ricorso della comunità a tale formato forza tuttora i vari siti a farne uso, con il risultato che si rivelano vulnerabili a possibili minacce legali.
Anzi, la situazione è ben più strana. In realtà sono due i brevetti che coprono l'algoritmo LZW. L'ufficio brevetti non si è reso conto che stava assegnando due brevetti su una medesima idea; non erano riusciti ad esaminare adeguatamente le richieste. Ciò però poggia su una buona ragione: occorre parecchio tempo per studiare con attenzione i due brevetti prima di rendersi conto che coprono veramente la stessa cosa.

Se si fosse trattato di due brevetti su dei processi chimici, sarebbe stato assai più semplice rendersene conto. Bastava identificare le sostanze impiegate, gli ingredienti e i risultati, quali le azioni concrete intraprese. Prescindendo dal modo in cui ciò veniva descritto, si sarebbe visto di cosa si trattava e ci si sarebbe accorti della somiglianza. Se un'azione è puramente matematica, è possibile descriverla in molti modi anche assai diversi tra loro. Non appaiono simili neppure a livello superficiale. Bisogna comprenderli fino in fondo prima di accorgersi che stanno descrivendo qualcosa d'identico. L'ufficio brevetti non ha abbastanza tempo. Alcuni anni fa l'ufficio brevetti degli Stati Uniti dedicava mediamente 17 ore a ciascuna richiesta presentata. Un periodo di tempo insufficiente per analizzarle con attenzione, ovvio quindi che si possano commettere errori come questo. Lo stesso è accaduto al programma menzionato sopra, quello morto prima ancora di nascere. Anche quell'algoritmo è coperto da due brevetti, entrambi rilasciati negli Stati Uniti; sembra si tratti di una circostanza nient'affatto insolita.
Evitare i brevetti può quindi essere semplice, oppure impossibile. Se è semplice, può darsi che renda inutile il programma -- dipende dalla situazione specifica.
Vorrei puntualizzare un'altra questione. Talvolta un'azienda o un consorzio riesce a imporre un formato o un protocollo come standard de facto. Nel caso tale formato o protocollo venga poi brevettato, è un vero e proprio disastro. Esistono perfino degli standard ufficiali soggetti alle limitazioni dei brevetti. Nel settembre del 2001 ci fu una grande sollevazione politica quando il World Wide Web Consortium propose di iniziare ad adottare degli standard coperti da brevetti. La comunità si oppose, costringendoli a ripensarci. Il consorzio fece marcia indietro, ribadendo che qualsiasi brevetto doveva essere liberamente applicabile da chiunque e che gli standard dovevano essere liberi in modo che tutti potessero implementarli. Si trattò di una vittoria interessante. Credo che quella fu la prima volta in cui un'organizzazione sugli standard prese quel tipo di decisione. È normale per tali organizzazioni voler inserire all'interno degli standard qualche elemento coperto da brevetto, impedendo agli utenti di procedere liberamente all'implementazione. Bisogna far pressione su entità organizzative analoghe per costringerle a modificare quelle norme.

Ottenere la licenza per il brevetto

La seconda possibilità, oltre quella di evitare il brevetto, consiste nell'ottenerne la licenza. Non è detto ciò possa essere necessariamente un'opzione fattibile. Chi detiene il brevetto non deve offrirvi alcuna licenza; non è obbligato a farlo. Dieci anni fa, la League for Programming Freedom ricevette una richiesta d'aiuto da parte di qualcuno la cui attività familiare riguardava la costruzione di macchine per i giochi d'azzardo nei casinò, e già allora usavano i computer. Aveva ricevuto la lettera di un'altra azienda che minacciava: "Quel brevetto l'abbiamo noi. Non ti è consentito fare quelle cose. Smettila!"
Decisi di dare un'occhiata a quel brevetto. Copriva una situazione in cui un certo numero di computer venivano collegati in rete in modo che ciascuna macchina fosse in grado di gestire più giochi diversi e l'utente potesse giocarvi simultaneamente.
Si scopre così che l'ufficio brevetti ritiene davvero brillante la capacità di fare più di una cosa in contemporanea. Non si rendono conto che in campo informatico ciò rappresenta la maniera più ovvia per generalizzare qualsiasi cosa. Lo hai fatto una volta, perciò adesso puoi rifarlo quante volte vuoi, si può creare una subroutine [una funzione del programma]. Credono che se riesci a fare qualcosa più di volta, ciò in qualche modo significa che sei brillante e che nessuno è in grado di tenerti testa, hai il diritto di dare ordini agli altri come ti pare e piace.
Comunque sia, al tipo in questione non venne offerta alcuna licenza. Fu costretto a smettere. Non poteva neppure permettersi le spese legali per il tribunale. Direi che quel particolare brevetto copriva un'idea piuttosto ovvia. È possibile che il giudice si fosse dichiarato d'accordo, ma non potremo mai saperlo perché non c'erano i soldi per avviare il procedimento.
Tuttavia, parecchi possessori di brevetti sono soliti offrire le relative licenze. Ma spesso chiedono cifre salate. L'azienda in possesso del brevetto per il ricalcolo secondo l'ordine naturale pretendeva il 5 per cento delle entrate lorde di ogni foglio di calcolo elettronico venduto negli Stati Uniti. Qualcuno mi riferì che si trattava del prezzo ridotto precedente l'eventuale denuncia -- se fossero stati costretti ad andare veramente in tribunale e avessero vinto, avrebbero preteso di più.
Può darsi che su uno specifico brevetto ci si possa permettere quel 5 per cento per la licenza, ma cosa succede quando occorrono le licenze su 20 brevetti diversi per realizzare un certo programma? A quel punto tutti i ricavi servono a pagare le licenze. Cosa succederebbe se fossero necessarie le licenze su 21 brevetti? Persone che operano nel settore mi hanno spiegato che a livello pratico due o tre di tali licenze porterebbe al fallimento di qualsiasi attività.
Esiste una situazione in cui ottenere la licenza è un'ottima soluzione. Ovvero nel caso di una mega-corporation multinazionale. Dato che queste aziende possiedono una gran quantità di brevetti, possono offrirsi le licenze a vicenda. In tal modo evitano gran parte del danno insito nel sistema dei brevetti e usufruiscono soltanto degli aspetti positivi.
Tempo fa l'IBM pubblicò sulla rivista Think -- credo fosse il numero 5 del 1990 -- un articolo sul pacchetto di brevetti aziendale, dove si illustravano i due tipi di vantaggi derivanti alla stessa IBM dal possesso di 9.000 brevetti statunitensi. (Credo che oggi tale cifra sia più ampia). Si trattava, primo, di incassarne le quote sui diritti, e, secondo, di ottenere "accesso ai brevetti altrui". Spiegavano come quest'ultimo beneficio fosse notevolmente maggiore del primo. I vantaggi derivanti all'IBM dalla possibilità di utilizzare le idee brevettate da altri equivaleva a dieci volte il beneficio diretto ottenuto dall'offerta di licenze sui propri brevetti.
Cosa significa veramente tutto ciò? Quali vantaggi ricava l'IBM da un simile "accesso ai brevetti altrui"? Si tratta in pratica del beneficio di essere esenti dai problemi provocati dal sistema dei brevetti. Un sistema analogo a una lotteria: qualsiasi brevetto può finire in un nonnulla, o rivelarsi una fortuna per alcuni detentori, oppure un disastro per chiunque altro. Ma consideratene le ampie proporzioni, per l'IBM lo scenario risulta vantaggioso. Un'azienda simile è in grado di valutare sia i danni sia i benefici di quel sistema. In questo caso, i guai causati da un tale sistema avrebbero superato di dieci volte gli aspetti positivi.
Ho detto "avrebbero" perché, grazie allo scambio vicendevole delle licenze, l'IBM può evitare ogni problema. Questi esistono soltanto a livello potenziale, non si concretizzeranno mai per una tale azienda. Eppure quest'ultima, calcolando i benefici derivanti dalla possibilità di evitarli, ne stima in dieci volte il valore del denaro raccolto dai brevetti di cui è titolare.
Questo fenomeno del trasferimento reciproco delle licenze serve a confutare un mito comune, quello del "genio morto di fame", il mito secondo cui i brevetti servano a "tutelare" il "piccolo inventore". (Si tratta di termini di propaganda. Non andrebbero usati).
Questo lo scenario che ci troviamo di fronte: supponiamo che qualcuno abbia in mente un progetto "brillante". Supponiamo che abbia trascorso "anni in soffitta morendo di fame" nella stesura di un progetto nuovo e meraviglioso di qualcosa, ed ora vuole passare a produrlo. Non è forse un'ingiustizia che qualche grande azienda decida di fargli concorrenza, di rubargli il mercato e farlo "morire di fame"?
Devo sottolineare che quanti lavorano nel settore dell'alta tecnologia generalmente non operano in proprio, che le idee non prendono forma nel vuoto -- sono basate su quelle altrui -- e che oggigiorno vantano ottime probabilità di ottenere un buon impiego qualora ne avessero bisogno. Perciò un tale scenario -- il fatto che un'idea brillante sia scaturita da qualcuno che lavora in solitudine -- è inverosimile, così come impensabile è l'eventualità che sia in pericolo di morire di fame.
È invece plausibile che qualcuno possa avere una buona idea che, insieme ad altre 100 o 200, sia alla base della realizzazione di un qualche tipo di prodotto, e che le grandi aziende vogliano fargli concorrenza. Vediamo perciò cosa potrebbe accadere nel caso costui tenti di usare un brevetto per bloccarle. Eccolo dire all'IBM: "No, non puoi competere con me, quel brevetto è mio." Al che l'IBM replica: "Vediamo un po' il tuo prodotto. Noi abbiamo questo brevetto, e quest'altro, quest'altro, quest'altro, quest'altro, e quest'altro ancora, rispetto ai quali il tuo prodotto commette delle infrazioni. Se credi di poter controbattere a tutti questi brevetti in tribunale, sicuramente ne troveremo degli altri. Perché invece non ci cediamo reciprocamente le licenze?" E allora al brillante inventore non resta che cedere: "Va bene, scambiamoci pure le licenze." Così può rimettersi al lavoro e portare a termine quel meraviglioso progetto. Ma lo stesso fa l'IBM, la quale ottiene "l'accesso" al suo brevetto e anche il diritto a fargli concorrenza, il che significa che tale brevetto non lo ha "tutelato" affatto. Non è questo l'obiettivo del sistema dei brevetti.
Per la gran parte, le mega-corporation evitano i pericoli di tale sistema; ne sperimentano principalmente i lati positivi. Questo il motivo per cui vogliono avere i brevetti sul software: saranno loro a trarne vantaggio. Ma ciò non funziona il piccolo inventore o chi lavora in una piccola struttura. Possono provarci, ma il problema è che un'azienda di proporzioni limitate non arriverà mai a possedere una quantità adeguata di brevetti per riuscirci (cioè, costringere gli altri allo scambio reciproco delle licenze).
Ciascun brevetto punta in una certa area. Così se una piccola azienda possiede dei brevetti relativi a determinati settori, e laggiù (Stallman indica in una direzione diversa) c'è qualcuno che gliene punta uno contro e vuole tutti i soldi, alla piccola azienda non resta che arrendersi. L'IBM può permetterselo, perché con 9000 brevetti copre ogni settore; a prescindere dall'area in cui si operi, è probabile esista già un brevetto dell'IBM. Questa può così costringere quasi sempre gli altri allo scambio reciproco delle licenze. Le piccole aziende possono riuscirci invece solo occasionalmente. Sostengono di volere i brevetti a scopo difensivo, ma non riescono mai ad accumularne abbastanza da poterlo fare realmente.
Esistono tuttavia dei casi in cui neppure l'IBM può costringere qualcuno a scambiare delle licenze a vicenda. Ovvero quando l'unica attività di un'impresa è quella di prendere un brevetto e spremere soldi dagli altri. Esattamente ciò che faceva l'azienda detentrice del brevetto per il ricalcolo secondo l'ordine naturale. L'unica sua pratica consisteva nel minacciare gli altri di denuncia e incassare le quote di chi stava effettivamente sviluppando qualche prodotto.
Non esistono brevetti sulle procedure legali. Credo che gli avvocati comprendano bene gli affanni di avere personalmente a che fare con il sistema dei brevetti. Il risultato è che diventa impossibile ottenere brevetti che possano costringere questo tipo di aziende allo scambio reciproco. Così vanno in giro a spremere soldi agli altri. Ma credo che entità quali l'IBM considerino ciò parte del prezzo insito nell'attività commerciale, e si siano adattate di conseguenza.
Questo dunque il quadro sulle possibilità di ottenere la licenza di un brevetto, cosa realizzabile o meno, e di cui è possibile o meno sostenere il peso economico -- il che ci porta alla terza strategia.

Ribaltare il brevetto in tribunale

Normalmente, qualsiasi cosa venga brevettata deve risultare nuova, utile e non ovvia. (Questa la terminologia usata negli Stati Uniti; credo che in altri paesi il linguaggio sia pressoché analogo). Naturalmente, quando entra in ballo l'ufficio brevetti inizia a dare la propria interpretazione di "nuovo" e "originale". Si scopre così che "nuovo" equivale a "non presente nel nostro archivio" e "non ovvia" tende a significare "non ovvia per qualcuno con un quoziente d'intelligenza di 50" [per una persona comune è intorno ai 140].
Secondo qualcuno che studia la maggior parte dei brevetti sul software assegnati negli Stati Uniti -- almeno, una volta era solito farlo, non so se riesce ancora a starci dietro -- il 90 per cento non avrebbe superato "l'esame di Crystal City", per intendere che nel caso gli addetti all'ufficio brevetti avessero deciso di passare in edicola e procurarsi qualche rivista d'informatica, avrebbero scoperto come quelle idee fossero già note.
L'ufficio brevetti prende decisioni così chiaramente folli che non occorre neppure essere aggiornati sulle ultima novità per rendersi conto della loro assurdità. Ciò non si limita soltanto al software. Una volta ho visto il famoso brevetto sul topo di Harvard, ottenuto dopo che i ricercatori locali avevano modificato geneticamente il topo iniettandogli il gene portatore del cancro. Tale gene era già conosciuto, e venne inserito ricorrendo a tecniche note all'interno di una catena preesistente di cellule di topo. Il brevetto concesso loro copriva l'inserimento di qualsiasi gene portatore di cancro in qualunque mammifero usando un metodo qualsiasi. Non occorre saper nulla di ingegneria genetica per rendersi conto di quanto ciò sia ridicolo. Mi si dice che questo "eccesso di rivendicazione" sia pratica comune, e che talvolta l'ufficio brevetti statunitense invita i richiedenti a estendere ulteriormente il campo coperto dal brevetto. Praticamente si finisce per coprire il massimo possibile fino a quando non ci si accorge di essere vicini a un'area certamente già occupata da opere precedenti. Si cerca di arraffare quanto più territorio possibile dello spazio mentale a disposizione.
Quando i programmatori considerano molti brevetti sul software, non possono far a meno di osservare: "quest'idea è ridicolmente ovvia!" I burocrati dei brevetti tirano fuori ogni tipo di scuse pur di giustificare la loro ignoranza del pensiero dei programmatori. Replicano così: "Bisogna però considerarla rispetto a come stavano le cose dieci o venti anni fa". Per poi scoprire che se portate alle estreme conseguenze, simili posizioni diventano controproducenti. Qualsiasi cosa può apparire originale quando se ne scompongono i pezzi, quando la si analizza abbastanza a fondo. Semplicemente svanisce ogni standard di ovvietà, o quantomeno si perde la la capacità di giustificare qualunque standard di ovvietà o non ovvietà. A quel punto, naturalmente, si finisce per descrivere tutti coloro che possiedono un brevetto come dei brillanti inventori; di conseguenza, non possiamo mettere in discussione il loro diritto a imporci cosa fare.
Se si decide di andare in tribunale, è probabile che i giudici mostrino maggiore attenzione alla questione della ovvietà o meno. Ma il problema è che per arrivarci bisogna spendere milioni di dollari.
Ho sentito parlare di un caso, l'accusato ricordo era la Qualcomm, in cui credo la sentenza finale fu di 13 milioni di dollari, la maggior parte dei quali servì a coprire l'onorario degli avvocati di entrambe le parti. Rimasero un paio di milioni di dollari per il querelante (fu la Qualcomm a perdere la causa).
In un contesto più ampio, la questione della validità o meno di un brevetto dipende dalle circostanze storiche. Meglio, da una gran quantità di indizi storici, tipo cosa e quando venne pubblicato, il materiale che si riesce a recuperare, quello non andato perduto, le date precise e così via. È la presenza di un certo numero di prove storiche a determinare la validità di un brevetto.
In realtà, è alquanto strano che British Telecom presentò domanda nel 1975 per il brevetto sugli "hyperlink accoppiato alla connessione telefonica". Credo fosse nel 1974 che il sottoscritto sviluppò per la prima volta il pacchetto Info, grazie al quale è possibile collegare tra loro gli hyperlink, mentre gli utenti usavano il telefono per accedere al sistema. Di fatto avevo realizzato un'invenzione precedente a quel brevetto. Questa è la seconda idea brevettabile che so di aver avuto in vita mia.
Ma non credo di avere alcuna prova al riguardo. Non l'avevo considerata sufficientemente importante da pubblicarla. Dopo tutto, l'idea di seguire gli hyperlink mi venne dalla dimostrazione dell'elaboratore creato da Doug Engelbart. Fu lui ad avere un'idea interessante da pubblicare. Quel che feci io lo definii "ipertesto del pover'uomo", poiché dovetti implementarlo nel contesto del TECO [acronimo per Text Editor and COrrector, era l'aggiornamento di un elaboratore testi per telescriventi, adattato da Stallman alla macchina PDP-6 operante nel laboratorio di intelligenza artificiale del MIT, con innovazioni importanti per quei tempi, primi anni '70, come i testi a tutto schermo]. Non risultò altrettanto potente del suo ipertesto, ma almeno si dimostrò utile per navigare nella documentazione, che era poi l'obiettivo finale. E per quanto concerne l'accesso via telefono al sistema, bé, funzionava così, non mi venne in mente che esistesse una relazione particolare tra le due cose. Non pensai di dover pubblicare una ricerca per dire: "Ho realizzato l'ipertesto del pover'uomo, e indovinate un po', c'è la linea telefonica anche nel computer!"
Sospetto non esista alcun modo per stabilire con esattezza la data in cui riuscii ad implementare tutto ciò. Venne forse pubblicato in qualche modo? Bé, invitammo alcuni ospiti dal giro di ARPANET a collegarsi online dalla nostra macchina -- può darsi che navigando nella documentazione usando il pacchetto Info si siano accorti della cosa. Se ce l'avessero chiesto, avrebbero scoperto l'esistenza dell'accesso tramite la chiamata telefonica. Come è possibile notare, quindi, sono le circostanze storiche a determinare l'esistenza o meno di un'opera precedente. Naturalmente esiste una pubblicazione sull'ipertesto curata da Engelbart che loro, gli imputati, si apprestano a mostrare. Non credo tuttavia dica nulla sul fatto dell'accesso telefonico presente nel computer, per cui non è chiaro se ciò potrà risultare sufficiente.
La possibilità di andare in tribunale per ribaltare il brevetto rappresenta un'opzione possibile. A causa delle spese necessarie, però, viene considerata di rado pur potendo provare l'esistenza certa di un'opera precedente che sembri sufficiente a ribaltare il brevetto. Come risultato, un brevetto non valido, un brevetto che a livello nominale non avrebbe dovuto esistere (come infatti dovrebbe essere per moltissimi brevetti), rappresenta un'arma pericolosa. Se qualcuno vi attacca con un brevetto non valido potrebbe davvero procurarvi grossi guai. Potreste bluffare tirando fuori un'opera precedente. Dipende dal fatto se ciò possa essere sufficiente per spaventarli. Potrebbero invece pensare, "Bé, stai soltanto bluffando, non ce la farai ad andare in tribunale, non puoi permettertelo, per cui ti denunciamo lo stesso."

Tutte e tre questi scenari costituiscono altrettante opzioni a disposizione, ma spesso è impossibile usarle. In pratica occorre affrontare un brevetto dopo l'altro. Ogni volta può darsi sia possibile ricorrere a una di tali opzioni, ma subito dopo c'è un altro brevetto e poi un altro ancora. È come attraversare un campo minato. È difficile che a ogni passo, a ogni decisione progettuale, si possa cadere su un brevetto esistente, e per un raggio limitato è probabile non ci sia alcuna esplosione. Ma le probabilità di riuscire ad attraversare indenni il campo minato e sviluppare il programma che si ha in mente senza mai inciampare in un brevetto, diminuiscono in maniera direttamente proporzionale all'ampiezza del programma.
A questo punto, qualcuno è solito chiedermi, "Anche in altri settori esistono i brevetti, perché mai il software dovrebbe esserne esente?" Notiamo la stranezza di questa supposizione, per cui in qualche modo saremmo tutti costretti a soffrire passando attraverso il sistema dei brevetti. È come dire, "C'è gente che si prende il cancro, perché non dovresti averlo anche tu?" Per come la vedo io, è un bene che non tutti siano malati di cancro.
Ma dietro quest'aspetto si nasconde una domanda meno pregiudiziale, una buona domanda: il software è forse diverso da altri settori? Le politiche sui brevetti dovrebbero forse essere diverse per ciascun ambito? Se sì, perché mai?
Consideriamo l'intera questione: i brevetti hanno funzionalità diverse a seconda dei settori, perché si comportano altrettanto diversamente con i rispettivi prodotti.
Ad un estremo abbiamo l'industria farmaceutica, dove una determinata formula chimica ottiene il brevetto in modo tale che questo copra un unico e singolo prodotto. Una nuova medicina non può essere coperta da un brevetto preesistente. Se dev'esserci un brevetto per questo nuovo prodotto, verrà assegnato a chiunque lo abbia sviluppato.
Ciò è coerente con l'idea infantile del sistema dei brevetti che abbiamo oggi: se hai realizzato qualcosa di nuovo, te ne spetta "il brevetto". L'idea è che a ciascun prodotto corrisponda un brevetto in grado di coprire l'idea alla base di quel prodotto. In alcuni settori tale scenario è vicino alla realtà; in altri assai lontano.
Il software rientra all'estremo opposto di questa seconda categoria: ciascun programma interseca numerosi brevetti. Ciò per via del fatto che normalmente i pacchetti software sono di ampie dimensioni. Fanno uso di molte idee diverse in combinazione tra loro. Se il programma è nuovo e non soltanto copiato, allora è probabile ricorra a una differente combinazione di idee -- inserite, ovviamente, all'interno di codice sorgente interamente riscritto, perché è impossibile limitarsi a enunciare tali idee e farle funzionare come per magia. Bisogna implementarle una dopo l'altra all'interno di quella combinazione.
Ne risulta che anche nella stesura di un programma si fa uso di molte idee differenti, ciascuna delle quali potrebbe essere stata brevettata da persone diverse. In ogni programma esistono perciò migliaia di elementi, migliaia di punti vulnerabili potenzialmente già coperti dal brevetto di qualcuno.
Ecco perché i brevetti sul software tendono a ostacolare il progresso del software -- il lavoro di sviluppo di un programma. Se fosse "un brevetto, un prodotto", allora i brevetti non impedirebbero lo sviluppo di nuovi prodotti perché è impossibile che ciascuno di questi sia stato già brevettato da qualcuno. Ma quando un programma è il risultato della combinazione di parecchie idee diverse, è assai probabile che il nuovo prodotto (in parte o per intero) sia già coperto da qualche brevetto precedente.
Non a caso una recente indagine economica rileva proprio come l'imposizione del sistema dei brevetti in un settore basato sull'innovazione per incrementi possa rallentarne il progresso. I sostenitori del sistema dei brevetti dicono, "Sì, è vero, possono nascere dei problemi, ma ancora più importante è il fatto che i brevetti debbano promuovere l'innovazione, e ciò è talmente importante che non importa quanti problemi possano provocare". Naturalmente si guardano bene dal dirlo ad alta voce perché è un'affermazione ridicola, ma implicitamente vogliono farci credere che fino a quando il sistema dei brevetti riesce a stimolare il progresso ciò supera qualsiasi costo possibile. Ma in realtà non esiste motivo per ritenere che ciò sia effettivamente in grado di stimolare il progresso. Oggi esiste un modello preciso a dimostrazione delle modalità con cui i brevetti possono rallentare il progresso. Il caso in cui applicare tale modello descrive abbastanza bene il campo del software, un campo/sistema ad innovazione incrementale.
Perché il software si trova all'estremità opposta dello spettro? Il motivo è che nel software sviluppiamo oggetti matematici astratti. Si può costruire un castello complicato e poggiarlo su una linea sottile, si reggerà perché non pesa nulla. In altri settori, si ha a che fare con la perversità della materia, degli oggetti fisici. La materia è qualcosa di ben preciso. Possiamo tentare di modellarla, ma se il comportamento reale non corrisponde al modello predisposto allora sono guai, perché la sfida consiste nel costruire oggetti materiali capaci di funzionare sul serio.
Se voglio inserire un costrutto "if" all'interno di un "while" non devo preoccuparmi se il costrutto "if" possa oscillare ad una determinata frequenza e collida con il ciclo "while" provocando la rottura delle due strutture. [L'intero esempio è basato su "if" e "while", due costrutti usati nella programmazione]. Non ho bisogno di preoccuparmi se ciò possa oscillare ad una frequenza così alta da indurre una iniezione di segnale che provochi un cambiamento di valore di qualche altra variabile. Né devo preoccuparmi di quanta corrente attraversi il costrutto "if" e se questo possa dissiparla in calore all'interno del ciclo "while", o se possa verificarsi un calo di voltaggio all'interno del ciclo "while" tale da impedire il funzionamento del costrutto "if". Neppure devo preoccuparmi del fatto che, nel caso faccia girare il programma in un ambiente con acqua salata, il sale possa infilarsi tra il costrutto "if" e il ciclo "while" e causare corrosione. [Il pubblico ride durante tutto il corso della descrizione].
Non devo preoccuparmi, quando utilizzo il valore di una variabile, se stia superando il limite di fan-out utilizzandola 20 volte. Né devo preoccuparmi della sua capacità massima, e se esista tempo sufficiente per caricarla alla giusta tensione.
Quando scrivo un programma, non ho bisogno di preoccuparmi di come in seguito dovrò assemblare materialmente ogni copia del programma, e se possa riuscire ad avere spazio sufficiente per infilare quel costrutto "if" all'interno del ciclo
"while". Né devo preoccuparmi di come aprire l'apparato nell'eventualità di una rottura del costrutto "if" per rimuoverlo e sostituirlo con uno nuovo. Ci sono così tanti problemi di cui non dobbiamo preoccuparci con il software; ciò rende sostanzialmente più semplice scrivere un programma anziché progettare un oggetto materiale capace di funzionare.
Ciò potrà apparire strano, perché probabilmente avrete sentito dire in giro quanto sia difficile progettare del software, e quanto sia complicato trovare soluzioni adeguate ai vari problemi. Non si tratta della medesima questione che sto illustrando ora. Il confronto cui mi riferivo riguarda i sistemi di software e quelli materiali aventi una complessità analoga, un identico numero di componenti. Ritengo che un sistema di software sia molto più facile da progettare di un sistema fisico. Ma l'intelligenza usata in questi campi diversi è la stessa, e allora cosa facciamo quando ci troviamo a operare in un contesto semplice? Decidiamo di andare più avanti! Spingiamo al limite massimo le nostre capacità. Di fronte alla semplicità dei sistemi di dimensioni analoghe, ne aumentiamo la grandezza di dieci volte -- allora sì che diventeranno difficili! Ecco cosa facciamo: costruiamo sistemi di software molto più estesi, in termini di numero dei componenti, dei sistemi fisici.
Un sistema fisico il cui progetto preveda un milione di pezzi diversi diventa un megaprogetto. Un programma informatico che includa un milione di pezzi raggiunge forse le 300.000 righe di codice; un pugno di persone impiegheranno un paio d'anni per scriverlo. Non si tratta di un programma particolarmente gigantesco. Oggi GNU Emacs conta svariati milioni di pezzi, credo. È composto da un milione di righe di codice. Si tratta di un progetto realizzato essenzialmente senza alcun tipo di sostegno economico, in gran parte scritto da varia gente nel proprio tempo libero.
Il software offre anche un altro grosso risparmio. Dopo aver progettato un prodotto fisico, il passo successivo concerne la costruzione edificare della fabbrica dove produrlo. Operazione che potrà costare milioni o decine di milioni di dollari, laddove per fare delle copie di un programma è sufficiente digitare "copia". Lo stesso comando consente di copiare qualsiasi programma. Volendo copiare su un CD, basta realizzare il master e spedirlo a un produttore di CD. Qui verranno utilizzate le medesime apparecchiature impiegate per copiare qualsiasi contenuto su un comune CD. Non bisogna costruire una fabbrica specializzata capace di produrre ogni articolo specifico. Il tutto comporta una semplificazione enorme e la drastica riduzione dei costi nella fase di progettazione.
Un'azienda automobilistica, che spenderà 50 milioni di dollari nella costruzione della fabbrica in cui verrà prodotto un nuovo modello di autovettura, può assumere degli avvocati per occuparsi delle trattative sulle licenze dei brevetti. Volendo, potranno anche risolvere felicemente eventuali denuncie legali. La progettazione di un programma di analoga complessità potrà costare 50.000 o 100.000 dollari. Al confronto, le spese per trattare con il sistema dei brevetti sono schiaccianti -- anzi, la progettazione di un programma avente le stesse complessità del progetto meccanico di un'autovettura richiede forse un mese di lavoro. Di quante parti è composta un'automobile... meglio, un'automobile priva di sistemi computerizzati? Ciò non vuol dire che sia facile progettare un buon modello, soltanto che questo non include poi così tante componenti.
(La trasmissione automatica è composta da circa 300-400 pezzi unici, e generalmente questa è la parte più complicata di un autoveicolo. La fase di progettazione della trasmissione può richiedere dai sei mesi a un anno, e a quel punto ci vorrà ancora più tempo per costruirla e renderla operativa. Invece un programma dotato di 500-800 parti funzionanti sarà praticamente composto da 200-300 righe di codice, e probabilmente un buon programmatore impiegherà da un giorno a una settimana per realizzarlo, incluse prove e collaudi.)
Ne risulta che il software è veramente diverso da altri settori, perché quando si lavora con elementi matematici la progettazione di qualcosa è infinitamente più semplice. Di conseguenza possiamo realizzare regolarmente sistemi molto, molto più grandi grazie appena a un paio di persone. Il risultato è che invece di essere vicini a "un brevetto, un prodotto", ci troviamo in un sistema in cui ciascun prodotto ingloba un enorme quantità di idee che potrebbero essere già state brevettate.
Il modo migliore per illustrare questa situazione è l'analogia con le sinfonie di musica classica. Anche una sinfonia è lunga e comprende parecchie note diverse, e probabilmente usa un gran numero di idee musicali. Proviamo ad immaginare cosa accadrebbe se i governi dell'Europa del 1700 avessero deciso di promuovere il progresso della musica sinfonica tramite l'attivazione di un ufficio brevetti per la musica europea, con il compito di assegnare i brevetti ad ogni tipo di idea musicale che fosse possibile descrivere a parole.
Immaginiamo di trovarci verso il 1800 e di impersonare Beethoven alle prese con la stesura di una sinfonia. Scoprirete ben presto come metterne insieme una che non infranga nessun brevetto, sia qualcosa di assai più arduo che scrivere una buona sinfonia.
Quando ve ne lamentate, i vari detentori brevetti potrebbero rispondere: "Ah, Beethoven, ti lamenti soltanto perché non hai idee originali. Tutto quello che vuoi fare è rubare le nostre invenzioni". In realtà Beethoven ha un sacco di nuove idee musicali -- ma deve anche usarne parecchie tra quelle esistenti per rendere riconoscibile la sua musica, in modo che possa piacere agli ascoltatori, i quali devono identificarla in quanto musica. Nessuno è talmente brillante da poter reinventare della musica completamente differente e realizzare al contempo qualcosa a cui si voglia prestare ascolto. Pierre Boulez disse di volerci provare, ma quanta gente ne ascolta la musica?
Nessuno è così brillante da poter reinventare tutta l'informatica, per rifarla completamente da capo. Se qualcuno potesse riuscirci, il risultato sarebbe talmente strano che gli utenti si rifiuterebbero di utilizzarla. Quando consideriamo un elaboratore testi odierno, vi scopriremo, credo, centinaia di funzioni diverse. Se qualcuno sviluppa un elaboratore testi nuovo e ben fatto, ciò vuol dire che presenta delle idee nuove, ma dovrà comprendere anche centinaia di idee preesistenti. Nel caso fosse illegale usarle, risulterebbe impossibile realizzare un elaboratore testi innovativo. Poiché il lavoro dello sviluppo del software è così ampio, ne risulta che non abbiamo alcun bisogno di schemi artificiali per incentivare nuove idee. Basta avere qualcuno che voglia scrivere del software e l'ispirazione non mancherà di arrivare. Se volete scrivere un programma di buon livello, vi verranno sicuramente delle idee e troverete il modo di applicarne alcune.
Visto che opero nel campo del software fin da prima dell'arrivo dei relativi brevetti, di solito succedeva che la maggior parte degli sviluppatori pubblicava qualsiasi nuova idea ritenuta valida, per le quali ritenevano di poter meritare qualche lode o riconoscimento. Le idee troppo ridotte o non sufficientemente valide non venivano pubblicate perché sarebbe stato sciocco farlo. Ora, si suppone che il sistema dei brevetti debba incoraggiare la manifestazione delle idee. In realtà in passato nessuno le custodiva gelosamente. È vero che tenevano segreto il codice. In fondo scrivere codice rappresentava il grosso dell'attività. Non rivelavano il codice e ne pubblicavano le idee, in modo che gli sviluppatori potessero ottenerne qualche riconoscimento e sentirsi apprezzati.
Dopo l'introduzione del sistema dei brevetti, continuarono a tenerne segreto il codice brevettando al contempo le idee, e di fatto non viene fatto assolutamente nulla per incoraggiare la diffusione delle idee. Quello che veniva tenuto segreto allora rimane tale ora, ma le idee che solitamente venivano pubblicate in modo che altri potessero usarle oggi è probabile vengano brevettate e tenute fuori portata per 20 anni.
Cosa può fare un paese per cambiare questa situazione? In che modo dovremmo riformare l'attuale politica onde risolvere il problema?
Due sono fronti che è possibile attaccare. Uno è il luogo fisico addetto al rilascio dei brevetti, l'omonimo ufficio. L'altro è laddove tali brevetti trovano applicazione. Questa faccenda riguarda quel che copre effettivamente un brevetto.
Un modo è quello di stabilire un buon criterio per l'assegnazione dei brevetti. Ciò può funzionare in un paese che finora non ha ancora autorizzato il ricorso ai brevetti sul software, come accade ad esempio nella maggior parte dei paesi europei. Una buona soluzione per l'Europa sarebbe semplicemente quella di rafforzare con chiarezza le norme dell'ufficio brevetti europeo, che stabiliscono la non brevettabilità del software. Attualmente l'Europa sta vagliando una direttiva per i brevetti sul software. (Credo che tale direttiva sia di portata più ampia, ma una delle implicazioni più importanti riguarda i brevetti sul software). Sarebbe sufficiente modificarla ribadendo che le idee sul software non possono essere coperte da brevetti, così da tenere gran parte dei problemi fuori dall'Europa, fatta eccezione per alcuni paesi che potrebbero trovarsi davanti a problemi interni, e uno di questi purtroppo è la Gran Bretagna (purtroppo per voi).
Un approccio simile non funzionerebbe negli Stati Uniti. Il motivo è che qui esiste già un'ampia quantità di brevetti sul software, e qualsiasi mutamento nel criterio per l'assegnazione non potrà liberarsi di quelli precedenti.
(Quando parlo di "brevetti sul software" cosa intendo dire in realtà? L'ufficio brevetti statunitense non divide ufficialmente i brevetti sul software dagli altri. Così qualsiasi brevetto che è possibile applicare a qualche tipo di software viene considerato la base presumibilmente valida per poter denunciare chiunque scriva dei programmi. I brevetti sul software sono brevetti che si possono potenzialmente applicare al software, brevetti che potenzialmente possono motivare la denuncia contro chi sviluppa del software.)
Così per gli Stati Uniti la soluzione dovrebbe materializzarsi tramite il cambiamento dell'applicabilità, dello scopo dei brevetti: affermando cioè che la pura implementazione del software, operante su un hardware generico che in sé non infrange il brevetto, non è coperta da alcun brevetto e non si può subire alcuna denuncia unicamente su tali basi. Questo è l'altro tipo di soluzione possibile, mentre la prima, quella relativa ai tipi di brevetti che possono risultare validi, è una buona soluzione da applicare in Europa.

Quando negli Stati Uniti venne introdotto il sistema dei brevetti non ci fu alcun dibattito politico. Anzi, non se ne accorse nessuno. Per la maggior parte, neppure quanti operavano nel campo del software ne presero nota. Nel 1981 una decisione della Corte Suprema prese in esame il brevetto su un procedimento per la lavorazione della gomma. Secondo la sentenza, il fatto che l'apparecchiatura in questione fosse dotata di computer e di programma come parte del processo per la lavorazione della gomma, non ne impediva la brevettabilità. L'anno successivo, la corte d'appello che si occupa di tutti i casi relativi ai brevetti chiarì meglio il concetto: l'esistenza di un computer e di un programma rende il prodotto brevettabile. Il fatto che all'interno di un oggetto qualsiasi ci sia un computer e un programma, consente la brevettabilità di tale oggetto. Ecco perché negli Stati Uniti piovvero le richiesta di brevetti sulle procedure commerciali: queste venivano eseguite tramite un computer e ciò le rendeva brevettabili.
Così venne emanata quella sentenza, e subito dopo credo che il brevetto per il ricalcolo secondo l'ordine naturale fosse uno dei primi ad essere assegnato, se non addirittura il primo.
Per tutti gli anni '80 non ne sapemmo nulla. Fu intorno al 1990 che i programmatori statunitensi iniziarono a rendersi conto dei pericoli cui andavano incontro con il sistema dei brevetti. Ho visto come operava il settore prima di quel periodo e come lo fece dopo. Dopo il 1990 non notai alcuna particolare accelerazione del progresso operativo.
Negli Stati Uniti non si ebbe alcun dibattito politico, ma in Europa se ne è avuto uno di ampie proporzioni. Parecchi anni fa vennero segnalate forti pressioni per apportare degli emendamenti al trattato di Monaco che implementava l'ufficio europeo dei brevetti. Una clausola del documento stabilisce la non brevettabilità del software. Le pressioni miravano a modificare tale clausola in modo da iniziare a consentire i brevetti sul software. Ma la comunità si accorse di questa manovra. Furono anzi gli sviluppatori e gli utenti di software libero a guidare le proteste. Non siamo soli noi a subire i pericoli del sistema dei brevetti. Ogni sviluppatore ne è minacciato, e lo stesso vale anche per gli utenti.

Ad esempio, Paul Heckel -- dopo che la Apple non venne intimidita dalle sue minacce -- avvertì che avrebbe preso a denunciarne gli utenti. L'eventualità preoccupò non poco la Apple, la quale comprese che non poteva permettersi di lasciar denunciare i propri clienti a quel modo, anche se in ultima analisi avrebbero vinto la causa. Ma il punto è che anche gli utenti posso subire una denuncia, sia come modo per attaccare gli sviluppatori sia soltanto per spremere loro dei soldi o provocare gravi danni. Tutti gli sviluppatori e gli utenti sono vulnerabili.
Ma in Europa è stata la comunità del software libero ad organizzare l'opposizione. Fu così che per due volte i paesi responsabili dell'ufficio europeo dei brevetti votarono no all'emendamento del trattato. Allora intervenne l'Unione Europea e le varie commissioni si mostrarono divise sulla questione. Quella il cui compito riguarda la promozione del software è contro i brevetti, almeno così pare, ma non aveva potere decisionale su questo tema. Ne è responsabile la commissione sul libero mercato, e chi la presiede sembra favorevole ai brevetti sul software. In pratica tale commissione non ha tenuto alcun conto delle posizioni espresse dal pubblico, proponendo una direttiva che consente i brevetti sul software.
Il governo francese ha già dichiarato la propria opposizione. Molta gente sta facendo pressione sui vari governi nazionali affinché si oppongano ai brevetti sul software, ed è vitale iniziare a muoversi anche qui in Gran Bretagna. Secondo Hartmut Pilch, uno dei leader europei nella battaglia contro i brevetti sul software, l'impeto maggiore arriva dall'ufficio brevetti britannico, il quale è aprioristicamente a favore dei brevetti sul software. L'ufficio britannico ha condotto una serie di consultazioni pubbliche, rivelatesi in maggioranza di segno contrario. Poi ha diffuso un documento in cui si sostiene che la gente sembra apprezzare quei brevetti, ignorando completamente le risposte ricevute dal pubblico. In ogni caso, la comunità del software libero aveva avvisato gli utenti, "Per favore inviate le risposte sia a loro che a noi". Così hanno pubblicato tali risposte, che in genere esprimevano opposizione. Sarebbe stato impossibile desumere tutto ciò dal rapporto pubblicato dall'ufficio brevetti britannico.
Questo ricorre spesso a un termine chiamato "effetto tecnico". È una definizione che può essere ampliata in maniera tremenda. Dovremmo credere che questa stia ad indicare che l'idea di un programma possa essere brevettata soltanto nel caso in cui si riferisca a specifiche azioni fisiche. Se questa è l'interpretazione corretta, in gran parte risolverebbe ogni problema. Se fosse davvero possibile brevettare soltanto le idee di un programma effettivamente correlate allo specifico risultato tecnico, fisico brevettabile in assenza di tale programma, ciò andrebbe bene. Il problema sta nel fatto che quel termine può subire delle estensioni. Quel che si ottiene facendo girare un certo programma può essere descritto come un effetto fisico. In che modo quest'ultimo si differenzia da qualsiasi altro risultato? Bé, lo è in quanto deriva da quel calcolo specifico. Di conseguenza l'ufficio brevetti britannico sta proponendo qualcosa che sembra condurre per lo più alla soluzione del problema, ma che in realtà offre carta bianca per poter brevettare quasi ogni cosa.
I responsabili dello stesso dipartimento sono coinvolti anche sulle tematiche del copyright, che in realtà non c'entra nulla con i brevetti sul software, eccetto per il fatto che in questo caso se ne occupano le stesse persone. (Forse sono stati indotti dal termine "proprietà intellettuale" a mettere insieme le due questioni). Si tratta di interpretare la recente direttiva dell'Unione Europea in tema di copyright, normativa orribile tanto quanto il Digital Millennium Copyright Act statunitense, pur se i singoli paesi hanno qualche spazio di manovra sulla sua implementazione. La Gran Bretagna vorrebbe massimizzare l'effetto tirannico della direttiva. Sembra che sia un certo gruppo -- forse il Ministero del Commercio e dell'Industria? -- a meritare la nostra attenzione. È necessario monitorarne le attività, in modo da bloccare la creazione di nuove forme di potere.

I brevetti sul software possono incastrare ogni sviluppatore e ogni utente informatico in una nuova forma di burocrazia. Se gli imprenditori che utilizzano i computer riuscissero a comprendere il gran numero di problemi che ciò finirà per provocare loro, sarebbero pronti a dar battaglia, e sono sicuro che riuscirebbero a fermare queste iniziative. L'imprenditoria non ha alcuna voglia di farsi legare le mani dalla burocrazia. Naturalmente talvolta questa è utile al raggiungimento di obiettivi importanti. Esistono alcuni settori in cui vorremmo che il governo britannico si fosse dimostrato più rigoroso nell'imporre maggiore burocrazia a certe aziende, come per lo spostamento e il commercio di animali (onde rendere difficile la diffusione della variante del morbo di Creutzfeldt-Jacob, meglio noto come "mucca pazza"). Ma nei casi in cui ciò non persegue altro scopo se non la creazione di monopoli artificiali in modo che qualcuno possa interferire con lo sviluppo dei programmi -- spremendo denaro dagli sviluppatori e dagli utenti -- allora dovremmo opporre un rifiuto. Dobbiamo informare i dirigenti imprenditoriali sulle conseguenze dei brevetti sul software nei loro confronti, così da ottenerne il sostegno nella lotta contro i brevetti sul software in Europa.
La battaglia non è ancora finita. Possiamo ancora vincerla.

-----

Trascrizione dell'intervento tenuto all'Università di Cambridge, Londra, il 25 marzo 2002. 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.