Una riforma del sistema brevettuale non è sufficiente

Originariamente pubblicato in GNU's Bulletin, vol. 1 #13.

Quando le persone scoprono per la prima volta il problema dei brevetti sul software, la loro attenzione viene spesso attirata dagli esempi più eclatanti: brevetti che coprono tecniche già largamente conosciute. Queste tecniche includono l'ordinamento di un'insieme di formule cosicché nessuna variabile viene utilizzata prima che il suo valore viene computato (chiamato ``ordine naturale del ricalcolo'' 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 è 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ò una serie di programmi per la compressione dei dati, utilizzando algoritmi di sua invenzione. La velocità di esecuzione e la qualità di compressione superiore di questi programmi presto attirò 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, ne venne proibito l'uso negli Stati Uniti a causa di un nuovo brevetto, #5.049.881.

Con la legge attuale, il fatto che il pubblico possa fare uso di questi programmi o no (cioè, se il brevetto sia valido o meno) dipende dalla presenza di ``arte anteriore'': che invalida un brevetto nel caso in cui l'idea era pubblicata prima della data in cui è 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 arte anteriore.

Uno studente dell'Università di San Francisco descrisse un algoritmo simile in una relazione accademica nel 1988-1989, ma non fu mai pubblicato. Pertanto, secondo la legge non conta come arte anteriore.

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

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

In base alle regole vigenti, la nostra capacità 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, è questione di fortuna. Questo sistema è 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 i meriti può prevenire alcuni errori clamorosi. Non aiuterà però a eliminare il problema più grave: il fatto che si sta brevettando ogni nuova caratteristica riguardante l'uso dei computer, come quello che Williams e altri svilupparono indipendentemente.

Questo trasformerà 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 è potenzialmente già brevettata. La nostra capacità di utilizzare ogni caratteristica dipenderà dalla fortuna, e se saremo sfortunati metà del tempo, pochi programmi sfuggiranno dal violare un grande numero di brevetti. Navigare nel labirinto di brevetti sarà più difficile che scrivere programmi. Come dice l'Economist, i brevetti sul software sono semplicemente dannosi per gli affari.

Se vuoi fare qualcosa, la cosa più facile è associarsi alla League for Programming Freedom.

Altri testi da leggere

Torna alla home page di GNU.

Informazioni e richieste su FSF e GNU a [email protected]. Altri modi di contattare la FSF.

Commenti su questa pagina web (in inglese) a [email protected], altri commenti a [email protected].

La copia letterale e la distribuzione di questo articolo nella sua integrità sono permesse con ogni mezzo, a patto che questa nota sia riprodotta. La copia e la distribuzione letterale su ogni supporto di questo articolo è permessa, purchè sia preservata questa nota.

Traduzione del martedi 18 aprile 2000