\documentclass[10pt,a4paper]{article}
\usepackage[italian]{babel}
\usepackage{html}
\pagestyle{empty}

\begin{document}

\begin{center} 

{\Large
Una riforma del sistema brevettuale non \`e sufficiente}\footnote{
Originariamente pubblicato in \htmladdnormallink{
GNU's Bulletin, vol. 1 no. 13.}{http://www.gnu.org/bulletins/bull13.html}
}

\medskip

{\small 
\htmladdnormallink{RICHARD M. STALLMAN}{http://www.gnu.org/people/rms}
}
\end{center}

\bigskip
\
\medskip



Quando le persone scoprono per la prima volta il problema dei 
brevetti sul software, la loro attenzione viene spesso attirata dagli
esempi pi\`u eclatanti:  brevetti che coprono tecniche gi\`a
largamente conosciute.  Queste tecniche includono l'ordinamento di 
un'insieme di formule cosicch\'e nessuna variabile viene utilizzata
prima che il suo valore viene computato (chiamato ``natural order
recalculation'' nei fogli di calcolo), e l'uso dell'or esclusivo per
modificare i contenuti di una schermata grafica.

Coloro che focalizzano la loro attenzione su questi esempi spesso 
perdono di vista il resto del problema.  Sono attratti dalla posizione 
che il sistema brevettuale \`e fondamentalmente corretto e necessita 
solamente delle ``riforme'' per funzionare correttamente.

Ma una corretta regolamentazione delle leggi risolverebbe il
problema dei brevetti sul software?  Vediamo un esempio.

Nell'aprile del 1991, il programmatore Ross Williams svilupp\`o
una serie di programmi per la compressione dei dati, utilizzando algoritmi
di sua invenzione.  La velocit\`a di esecuzione e la qualit\`a
di compressione superiore di questi programmi presto attir\`o molti 
utenti.

Il settembre dello stesso anno, a una settimana dal rilascio di
uno di questi come programma di compressione standard per le distribuzioni 
software dell'FSF\footnote{Free Software Foundation}, ne venne proibito l'uso 
negli Stati Uniti a causa di un nuovo brevetto, numero 5.049.881.

Con la legge attuale, il fatto che il pubblico possa fare uso
di questi programmi o no (cio\`e, se il brevetto sia valido o meno)
dipende dalla presenza di ``prior art'': che invalida un brevetto nel caso
in cui l'idea era pubblicata prima della data in cui \`e stata 
depositata la richiesta per il brevetto, il 18 giugno 1990.  Il programma di 
Williams fu rilasciato nell'aprile del 1991, quindi non conta come 
``prior art''.

Uno studente dell'Universit\`a di San Francisco descrisse un 
algoritmo simile in una relazione accademica nel 1988-1989, ma non fu mai
pubblicato.  Dunque, secondo la legge non conta come ``prior art''.

In questo caso, non aiuterebbero riforme per correggere il funzionamento
del sistema brevettuale.  Con le regole attuali questo brevetto
sembra valido.  Non esiste ``prior art'' che lo pu\`o invalidare.
Non \`e ovvio, secondo i criteri dell'Ufficio Brevetti.  (Come
molti brevetti, non \`e n\'e fenomenale n\'e banale,
ma fra questi due estremi).  Il problema \`e nelle regole stesse,
non nella loro esecuzione.

Nel sistema giuridico americano, i brevetti rappresentano uno scambio
tra la societ\`a e un individuo; la societ\`a guadagna con la
divulgazione di tecniche che altrimenti resterebbero segrete.  \`E
evidente che la societ\`a non ha guadagnato nulla con il brevetto 
numero 5.049.881.

In base alle regole vigenti, la nostra capacit\`a di utilizzare
i programmi di Williams dipende dal fatto che qualcuno abbia pubblicato
o meno la stessa idea prima del 18 giugno 1990.  In altre parole,
\`e questione di fortuna.  Questo sistema \`e ottimo per
promuovere il lavoro degli avvocati, ma non aiuta il progresso del
software.

Insegnare all'Ufficio Brevetti come esaminare meglio una domanda di 
brevetto per determinarne la ``novit\`a'' e l'``attivit\`a inventiva'' 
pu\`o prevenire alcuni errori clamorosi.  Non aiuter\`a per\`o a eliminare il 
problema pi\`u grave: il fatto che si sta brevettando ogni {\it nuova}
caratteristica riguardante l'uso dei computer, come quello che Williams 
e altri svilupparono indipendentemente.

Questo trasformer\`a il software in un pantano.  Anche un
programma innovativo tipicamente fa uso di dozzine di tecniche
e caratteristiche che non sono nuove, ognuna delle quali \`e
potenzialmente gi\`a brevettata.  La nostra capacit\`a di
utilizzare ogni caratteristica dipender\`a dalla fortuna, e se 
saremo sfortunati met\`a del tempo, pochi programmi sfuggiranno dal 
violare un grande numero di brevetti.  Navigare nel labirinto di brevetti 
sar\`a pi\`u difficile che scrivere programmi.  Come dice 
{\it l'Economist}, i brevetti sul software sono semplicemente
dannosi per gli affari.

Se vuoi fare qualcosa, la cosa pi\`u facile \`e associarsi alla 
League for Programming Freedom.

\bigskip


\begin{flushleft}
{\small 
Copyright \copyright\/ 1996, 1997, 1998 Free Software Foundation, Inc.,
59 Temple Place - Suite 330, Boston, MA  02111,  USA 

\medskip

Questo articolo pu\`o essere ridistribuito liberamente a condizione che non venga 
alterato e che questo avviso resti intatto.
}
\end{flushleft}

\end{document}
