Traduzioni di questa pagina
I brevetti sofware sono uno dei progetti inerenti il software che più somigliano alle mine anti-uomo: ogni decisione strutturale, porta con sé il rischio di cadere nelle maglie di un brevetto che può distruggere il vostro lavoro.
Sviluppare un programma ampio e complesso significa combinare molte idee, spesso centinaia o migliaia. In un Paese che permette i brevetti sul software, le possibilità che alcune parti sostanziali delle idee nel vostro programma siano già brevettate da altre compagnie sono molte. Per di più sarebbe possibile che centinaia di brevetti coprano parti del vostro programma. Uno studio condotto nel 2004 ha concluso che in un solo importante programma si faceva uso di almeno 300 brevetti americani. Fare uno studio del genere è un lavoro così gravoso che ne è stato fatto soltanto uno.
Pragmaticamente parlando, se si è sviluppatori di software, ci si può spesso trovare ad essere messi sotto scacco da un brevetto. Qualora ciò accadesse, si potrebbe riuscire a superare il problema, restandone indenni, trovando delle argomentazioni giuridiche per scansare il brevetto. Si può provare anche a fare così e, se si riuscisse, ciò significherebbe avere una mina in meno nel nostro campo minato. Se questo brevetto è particolarmente minaccioso per il pubblico la Public Patent Foundation (pubpat.org) potrà occuparsi del caso: questa è la sua specialità. Se venisse chiesto l'aiuto della comunità degli utenti informatici per cercare precedenti pubblicazioni della stessa idea ed utilizzarle al fine di far cadere un brevetto, dovremmo tutti rispondere con ogni informazione utile che si è in grado di dare.
Tuttavia, combattere i brevetti uno ad uno non eliminerà mai il pericolo dei brevetti software, così come uccidere le zanzare non significa sconfiggere la malaria. Non ci si può aspettare di sconfiggere ogni brevetto che si incontra, così come non si può sperare di uccidere tutti i mostri di un videogioco: prima o poi, uno di questi vi vincerà e danneggerà il vostro programma. L'ufficio americano competente, rilascia circa 100.000 brevetti per anno, nonostante i nostri sforzi, non possiamo immaginare di disinnescare queste mine con la stessa velocità con cui vengono piazzate.
Alcune di queste mine non sono neutralizzabili. Ciascun brevetto software è dannoso e limita il proprio modo di usare il calcolatore; tuttavia, non tutti i brevetti software sono legalmente nulli in base ai criteri del sistema di regolamentazione competente. Quelli che possiamo far annullare, sono quelli nati da "errori", nei quali non sono state correttamente applicate le regole del sistema dei brevetti. Non possiamo fare alcunché quando l'unico errore di rilievo risulta essere la politica del permettere i brevetti software.
Per salvare il salvabile, non basta uccidere i mostri non appena ci si parano davanti: occorre eliminare cosa li produce. Far annullare uno ad uno i brevetti non rendera più sicuro il lavoro di chi programma. Per fare ciò, occorre cambiare il sistema dei brevetti in modo che questi non possano più minacciare gli sviluppatori di programmi e gli utenti.
Non c'è alcun conflitto tra queste due campagne: si può contemporaneamente lavorare sull'obiettivo a breve termine e su quello a lungo termine. Se si fa attenzione, si può fare in modo che gli sforzi necessari a far invalidare ogni singolo brevetto sul software abbiano una doppia funzione, fornendo sostegno agli sforzi necessari per correggere l'intero sistema. Il punto cruciale non è paragonare i "cattivi" brevetti sul software con brevetti sbagliati o non validi. Ogni volta che invalidiamo un brevetto, ogni volta che parliamo dei nostri piani per riuscirci, dovremmo dire senza mezzi termini: "un brevetto in meno, una minaccia in meno per i programmatori: l'obiettivo è zero".
La battaglia sui brevetti software nell'Unione Europea sta raggiungendo una fase critica. Il Parlamento Europeo ha votato un anno fa per eliminare definitivamente i brevetti. A maggio il Consiglio dei Ministri ha votato per cancellare gli emendamenti del Parlamento e rendere la direttiva ancora peggiore di quanto non lo fosse all'inizio. Ad ogni modo, almeno un paese che sosteneva questa idea ha già cambiato il suo voto. Dobbiamo fare del nostro meglio per convincere un Paese Europeo in più a cambiare il suo voto e convincere i nuovi membri del Parlamento Europeo a ritornare al voto iniziale. È possibile visitare il sito www.ffii.org per avere maggiori informazioni su come aiutare e contattare altri attivisti.
Ritorna alla pagina principale di GNU.
Per informazioni sulla FSF e GNU rivolgersi, possibilmente in inglese,
a
gnu at gnu.org.
Altri modi per contattare
la FSF.
Inviate link non funzionanti e altre correzioni relative alle pagine
web (o suggerimenti) a
webmasters at gnu.org.
Per informazioni su come coordinare o inviare traduzioni consultate il README per le traduzioni.
Copyright (C) 2004 Richard Stallman
La copia letterale e la distribuzione di questo articolo nella sua
integrità sono permesse con qualsiasi mezzo senza royalty a
condizione che questa nota sia riprodotta.
Aggiornato: $Date: 2006/10/25 14:35:20 $ $Author: puigpe $