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 ``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 è 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'FSF2, 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è, 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 è 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à 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ò 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 esecuzione.
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 numero 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 la ``novità'' e l'``attività inventiva'' 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.