LibrePlanetItalia/Progetti/traduzioni/end-software-patents.it
Documento originale: http://www.fsf.org/bulletin/2009/fall/end-software-patents/
Testo dell'originale al: italiano
Traduzione a cura di: xiaoy
Stato traduzione: completata il ? ore ?
Revisione a cura di: ?
Stato revisione: da revisionare
Note:
Porre fine ai brevetti software (End Software Patents) Creato da root - Ultima modifica 18/12/2009 19:01
Ciaran O'Riordan, porre fine dei brevetti software
Il caso Bilski è il primo caso, dal 1981, che affronta apertamente il tema dei “soggetti brevettabili”. L'allora decisione della Corte d'Appello degli Stati Uniti (vedi: http://en.wikipedia.org/wiki/In_re_Bilski), potrebbe definire le regole sui brevetti per i decenni a venire; le decisioni prese nell'udienza di quel 9 novembre 2009, indicano che le Istituzioni hanno aperto gli occhi sui problemi concernenti la brevettabilità del software. Ciò pone nelle nostre mani una grande opportunità, ma anche una pesante responsabilità.
Alcuni esperti legali hanno ipotizzato che la sentenza sarà emessa agli inizi della primavera del 2010. Altri hanno suggerito che qualunque sia il risultato, sarà proposta comunque una modifica legislativa. L'attuale interesse della Corte Suprema sul caso in questione, rende più facile per noi aumentare l'interesse dei media su questo argomento e, se si tratterà di intervenire sulla legislazione, avremo bisogno di un ampio sostegno pubblico per l'abolizione dei brevetti software. Nei prossimi tre mesi, abbiamo quest'unica possibilità per costruire le fondamenta per l'abolizione dei brevetti software negli Stati Uniti. È lì che abbiamo bisogno di te!
La Corte Suprema non è tenuta a pronunciarsi sulla “brevettabilità” delle idee che sono alla base del software. Il brevetto Bilski è un brevetto sulle metodologie commerciali, non si tratta di un brevetto software. Allora perché il giudice dovrebbe allargare la sua sfera d'azione pronunciandosi su un brevetto che riguarderebbe il software?
Il basso costo di investimento richiesto per intraprendere lo sviluppo del software ha implicato la nascita di un folto numero di piccole imprese del settore; per il proseguimento della nostra analisi, però, non ci occuperemo di questo aspetto, per analizzarne un altro di maggiore rilevanza. Nella maggior parte dei campi del “brevettabile”, la serie di grandi e piccole imprese redigono una descrizione dei prodotti realizzati, argomentando “come sono fatti”. Se questo fosse vero anche per il software, allora la decisione di brevettabilità dei programmi per computer avrebbe conseguenze esclusivamente economiche, e i brevetti servirebbero, quindi, solo a sollevare problemi economici. Ma questa è solo metà della storia.
Nel software, a differenza di altri settori, ci sono due ulteriori categorie di sviluppatori. La prima è quella degli sviluppatori software che si siedono nei reparti IT di ogni azienda di medie dimensioni. Sono le persone che permettono alle e-mail di “scorrere”, che scrivono software da utilizzarsi all'interno dell'azienda ed estendono quello acquistato, e che gestiscono i siti web. La seconda categoria è costituita da singoli individui, gruppi informali e comunità che programmano per il proprio vantaggio o per motivi sociali: come, ad esempio, fornire alternative al software visto come eccessivamente restrittivo.
L'esistenza di queste due categorie cambia tutto, perché è poco pratico imporre loro di lavorare all'interno del lento sistema dei brevetti e sostenere i rischi legali e finanziari che questo sistema involve. Ovviamente, gli incentivi dei brevetti non sono necessari per motivare i dipartimenti IT a risolvere i problemi del software. Inoltre, quando un dirigente d'azienda segnala un problema legato, ad esempio, ad un sito Web, non si aspetta che il reparto IT, prima di attivarsi, chieda una consulenza legale per una ricerca di brevetto; e non si aspetta di ricevere più tardi una fattura o una lettera del titolare del brevetto che inviti a cessare le operazioni a causa del modo in cui ci si è disposti per risolvere il suddetto problema.
Una seconda questione riguarda il fatto che l'applicazione di norme industriali per le attività che le persone fanno per divertimento o per il bene della loro comunità è ingiusto. Per le comunità di utenti programmare serve a soddisfare i propri bisogni; ma il potere di veto che ha il titolare del brevetto per la distribuzione del software è, purtroppo, ancora troppo potente. Se il software è scritto col fine di avere un programma liberamente ridistribuibile, allora il veto di una parte terza può rovinare gli sforzi degli sviluppatori, in qualsiasi momento. Non ci saranno utili diretti da cui partire per offrire il pagamento delle royalty, così il risultato è una situazione di mancato guadagno in cui viene distrutto il lavoro dello sviluppatore. È inoltre assurdo che non ci sia nulla da guadagnare, nemmeno per il titolare del brevetto (anche se il brevetto verrà comunque fatto rispettare per affondare il pezzo di software in modo che gli utenti di computer siano spinti verso un programma che paghi le royalty al titolare del brevetto).
Nel software, piuttosto che sostenere gli innovatori, i brevetti proteggono il vecchio contro il nuovo.
Questa questione è ulteriormente esasperata da un problema che si applica a tutti i tipi di sviluppatori di software: in nessun altro campo sono così fondamentali gli “standard” moderni come lo sono nel mondo del software. Se il lupo vuole mangiare l'agnello, ci sono molti modi per farlo. Quando i brevetti bloccano lo sviluppatore di un prodotto fisico nell'utilizzo di un determinato metodo di produzione, esiste comunque una possibilità di innovazione quando lo stesso cerca un metodo alternativo per rimediare alla produzione. Nel software, l'essere bloccato nell'uso di un'immagine, di un e-mail, o un formato di documento equivale ad essere bloccati nella scrittura di un funzionale lettore di e-mail, visualizzatore di immagini o word processor. Un elaboratore di testi innovativo, che però non può leggere tutti i documenti esistenti, è semplicemente inutile, e le eventuali innovazioni applicabili ad esso sono quindi fatica sprecata.
Per i video, il problema degli “standard” è molto reale. Il gruppo MPEG-LA sostiene di rappresentare più di venti titolari di brevetti, che posseggono a loro volta uno o più brevetti essenziali per l'implementazione del comune formato video MPEG. Non esiste licenza per la ridistribuzione libera di software che utilizzi questo formato video; così anche i contribuenti delle royalty sono costretti ad accettare i termini della MPEG-LA. La commissione che sta sviluppando il prossimo standard per le pagine Web, l'HTML5, ha speso mesi per la ricerca e la discussione su quale formato video potrebbero consigliare per il loro “standard”, e la risposta finale è stata che, a causa dei brevetti software, non c'è oggi nessun formato che possano raccomandare.
Ora, è importante guardare l'output della comunità di utenti che abbiamo appena citato. Se fossero persone come, ad esempio, orologiai hobbisti, che professano per sé e per pochi amici, o per una clientela abbastanza piccola, che non attirano l'attenzione dei titolari dei brevetti, allora il problema degli standard e dei brevetti non sarebbe un grosso problema. Il sistema sarebbe comunque ingiusto, ma se l'ingiustizia si manifestasse mai, allora si tratterebbe di un problema soltanto teorico.
Tuttavia (come i sostenitori della FSF sanno), il software liberamente ridistribuibile – e il lavoro che è stato iniziato da idealisti e appassionati – ha portato alla realizzazione del server web più utilizzato al mondo, al secondo web browser più utilizzato, e al sistema operativo GNU / Linux. Infatti, gli “utenti” sono oggi spesso i dipendenti, e i loro modelli di sviluppo collaborativo sono emersi come i principali competitor nei molti campi del software. Bloccare la collaborazione, quindi, risulta essere non solo una limitazione sulle attività individuali, ma soffoca anche la concorrenza e la produzione in serie di software utili. Elenchi infinite di ricerche e statistiche suggeriscono che i brevetti riducono l'innovazione del software.
Anche se le imprese di grandi dimensioni ora contribuiscono a questi progetti molti sviluppatori sono ancora “ singoli individui”, e persone che non ne traggono direttamente profitto. I termini di distribuzione di questo software sono gli stessi del passato: non sono per nulla cambiati. È una formula collaudata, e una clausola chiave è che non è possibile ridistribuire il software se le royalties sui brevetti saranno richieste.
Il kernel del sistema operativo GNU / Linux fu stato esaminato all'avvocato esperto di brevetti Dan Ravicher, che ha annunciato il 2 agosto 2004, che non aveva trovato, nel codice al suo interno, nessun brevetto violato ma ben 283 brevetti già rilasciati, che potrebbero potenzialmente essere utilizzati per sostenere dei risarcimenti per l'utilizzo di software registrato. Successivamente, la Microsoft ha iniziato nel 2007 ad affermare che il kernel Linux viola 235 dei suoi brevetti - anche se i brevetti non sono mai stati specificati. Né potrebbe essere così, ma ciò ci fornisce un'idea sull'entità della cifra di brevetti in questione.
Il kernel è una componente, e poiché il codice sorgente - scritto dall'uomo - è on-line, possiamo osservare che è lungo circa 4.000.000 di linee. Dato che una distribuzione di il sistema operativo GNU / Linux, completo di applicazioni, può contenere software con oltre 225 milioni di righe di codice sorgente, quando estrapoliamo numeri dal kernel, si arriva alla possibilità di 13.160 o 15.848 violazioni di brevetto per distribuzione completa. Tutto questo in qualcosa che può essere distribuito una volta o mille volte, di solito senza alcun costo, a volte da grandi aziende, a volte da singole persone.
Questo è un grado di incertezza che non può essere risolto con cambiamenti negli standard di valutazione.
Ci fu un tempo in cui quando scrivevi qualcosa, era di tua proprietà. Lo potevi distribuire, lo potevi usare come punto di partenza per una collaborazione. Se la proprietà è un bene o un male per la società dipende da che libertà si concede ai destinatari di un opera. Ma almeno quelli che facevano una cosa giusta avevano la certezza legale. Ora, la proprietà di un pezzo di software è una speranza di speculazione. Non vi è alcun modo affidabile per avere una aspettativa consolidata per quanto riguarda i limiti o la misura in cui si possiede un pezzo di software. La Corte Suprema ha ora la possibilità di liberarci da questa situazione di incertezza e del presente regolamento ingiusto, dando l'United States Patent and Trademark Office uno strumento affidabile per escludere le idee alla base del software dalla materia brevettabile. È possibile sostenere i nostri sforzi e seguire le notizie in corso e come si svolge il caso Bilski a news.swpat.org.