Newsgroup: it.diritto
Titolo: Come si brevetta il software?

Ho saputo che lo schema a blocchi del software si puň brevettare in Italia.
Quali sono le fonti del diritto dalle quali si desumerebbe ciň?
Mi sapete dare qualche link a qualche guida o giurisprudenza che lo spiega?
Grazie
Lara

 Mi sapete dare qualche link a qualche guida o giurisprudenza che lo
spiega?
C'è ancora incertezza sulla brevettabilità del sw attesa la tutela di esso
per il tramite del diritto d'autore e la possibilità di depositare il
programma su CD presso la SIAE.
In ogni caso ti suggerisco di presentare domanda di brevetto europeo - che
compende quello italiano - per il quale non sussiste alcun dubbio in
proposito.
Cordialità
J.


Nel senso che permette "di buon grado" di tutelare il software?
Mi puoi indicare qualche link a qualche guida o giurisprudenza che spiega
più in dettaglio?
Grazie
Lara

 ha scritto nel messaggio
news:b9n2hk$uu9$1...@lacerta.tiscalinet.it...

Cmq non pagerei mai per un sw brevettato
lo prevetti e te lo tieni
dato che siamo sull'argomento
hanno anche pensato di brevettatre il visus della sars
a che scopo brevettare il visus se non per utilizzi futuri ?

 più in dettaglio?
Non ho link né giurisprudenza non foss'altro perché la brevettabilità di una
invenzione come brevetto europeo viene valutata da tecnici dell'Uffico
Brevetti di Monaco.
Se credi devi fidarti della mia esperienza.
Cordialità
J.

 per il momento si berevetta solo in usa
Negativo.
Ho presentato domanda di brevetto internazionale per un sw e il primo
referaggio (dopo circa un anno dalla presentazione) ha gią avuto esito
positivo.
J.

 J.
non per sapere i fatti tuoi ma cosa fa' il tuo software?


Brevetto internazionale? americano vorrai dire...

 Brevetto internazionale? americano vorrai dire...
Forse c'è un po' di confusione.
Conosci il PCT? Il registro di Ginevra? Si presenta domanda di brevetto
internazionale e poi si può estendere la tutela ai singoli paesi
d'interesse.
Oggi "Internazionale" ancora non vuol dire tout court "americano".
J.

 ha scritto nel messaggio
news:b9su5d$20en$1...@newsreader2.mclink.it...


Un link per informarti:
pensaci seriamente: i brevetti software sono la morte del software.
http://petition.eurolinux.org/index_html

Economia
Recenti studi teorici e statistici basati su modelli dinamici tendono a
dimostrare che l'eccessiva diffusione dei brevetti non solo riduce la
concorrenza ma anche l'innovazione nell'industria del software o in
qualsiasi industria che produca sistemi complessi basati sull'"innovazione
sequenziale" (Web, consulenza, educazione, management, ecc.). I principi
come "più proprietà, più innovazione" o " brevetti più vincolanti promuovono
innovazione nelle PMI" sono certamente sbagliati nel caso del software.
Un qualche tipo di debole protezione che permetta l'imitazione parziale e
proibisca allo stesso tempo una completa scopiazzatura sembra essere il
modello ottimale da raggiungere. Il copyright, che proibisce la copia ma
consente di imitare funzionalità o tecnologie sembra essere la scelta
ottimale nel caso del software. Per questo motivo non è consigliabile
concedere brevetti sul software.
Tuttavia, se questi brevetti sul software venissero concessi, è
consigliabile ridurre quanto più possibile i diritti di proprietà concessi
al titolare del brevetto al fine di prevenire situazioni di blocco o effetti
di market linkage. Il modello "software useright" raggiunge questo obiettivo
distinguendo tra due mercati indipendenti, un primo mercato per i diritti di
copiatura del software (ma non di utilizzo) e un secondo mercato per i
diritti di utilizzo di tecniche software. In questo modello, gli effetti più
indesiderabili dei brevetti sul software tendono a scomparire.
Sequential Innovation, Patents and Imitation - James Bessen, Eric Maskin.
MIT e Harvard.
Questo articolo presenta un modello dinamico più appropriato all'innovazione
sequenziale del tipo presente in industrie come quella del software, della
micro-elettronica. Mostra che politiche brevettuali diffuse e vincolanti
tendono a ridurre l'innovazione. Un'analisi statistica dell'innovazione
nell'industra del software tende a confermare questo modello.
http://www.researchoninnovation.org/patent.pdf
Software Useright, Solving Inconsistencies of Software Patents. Jean-Paul
Smets.
Questo articolo "tutto-in-uno" confronta l'economia del copyright e
l'economia dei brevetti nel caso di software con un approccio stratificato
(inventori, venditori, editori). Dimostra che i brevetti sul software
tendono a promuovere il segreto industriale, il che è incoerente con il loro
obiettivo storico di promuovere la condivisione della conoscenza, e di
eliminare concorrenti innovativi, il che è anche incoerente con i loro
supposti effetti economici. Dimostra inoltre che è possibile creare un
mercato stratificato per i diritti della proprietà intellettuale in cui i
brevetti e il copyright vengono venduti indipendentemente. Questo approccio
stratificato tende ad eliminare i brevetti bloccanti così come quelli banali
senza intervento dello Stato.
http://www.smets.com/it/policy/useright/useright.pdf
Software Patents Tangle the Web. Seth Shulman. Techreview. Rivista
sull'innovazione del MIT
Questo articolo ricorda che brevetti troppo diffusi tendono a soffocare
l'innovazione nelle industrie emergenti e che non è mai stato l'obiettivo
dei brevetti concedere un monopolio per ogni minima ombra di idea.
http://www.techreview.com/articles/ma00/shulman.htm

 più in dettaglio?
http://internet.cybermesa.com/~berny/brevetti.html
http://linuxtoday.com/news_story.php3?ltsn=2000-05-26-004-04-OP-LF

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 cont
ro 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.