Brevetti sul software? Assolutamente no!

Questi alcuni stralci significativi tratti dall’intervento di Richard Stallman al Computer Laboratory della Università di Cambridge, a Londra, il 25 marzo 2002, sotto il titolo I pericoli dei brevetti sul software.

Impariamo intanto a conoscere le norme sul copyright, e separatamente quelle sui brevetti.
Queste alcune delle maggiori differenze esistenti tra copyright e brevetti:

• Il copyright concerne i dettagli dell’espressione di un’opera, ma non copre alcuna idea. I brevetti riguardano soltanto le idee e il loro utilizzo.
• Il copyright accade in maniera automatica. I brevetti vengono concessi dal relativo ufficio dietro presentazione di apposita richiesta.
• I brevetti sono molto onerosi. Le spese legali necessarie alla stesura della richiesta sono perfino più salate della domanda stessa. Normalmente occorrono alcuni anni prima che qualsiasi richiesta venga presa in considerazione, anche se l’ufficio brevetto lavora in maniera estremamente lenta.
• La durata del copyright è estremamente lunga. In alcuni casi si arriva anche a 150 anni. I brevetti durano 20 anni, periodo breve rispetto alla vita umana ma comunque eccessivo per le scadenze di un settore come quello del software. Basti pensare a 20 anni addietro, quando il PC era qualcosa di nuovo, e immaginiamo di dover essere costretti a sviluppare software utilizzando soltanto i concetti conosciuti nel 1982.
• Il copyright interessa unicamente la copia. Se scrivo un romanzo che si scopre essere identico parola per parola a “Via col vento”, potendo al contempo dimostrare di non averlo mai visto, ciò rappresenterebbe un’ottima difesa contro ogni accusa di infrazione al copyright.
• Un brevetto è il monopolio assoluto sull’utilizzo di un’idea. Anche potendo dimostrare di aver avuto quell’idea per conto proprio, ciò sarebbe del tutto irrilevante se quell’idea è stata già brevettata da qualcun altro.

Dunque, qual è la prima cosa da fare dopo aver avuto un’idea sul tipo di programma che ci si appresta a scrivere? Tanto per cominciare, dovendo aver a che fare con il sistema dei brevetti, si potrebbe cercare di scoprire quali siano i brevetti relativi a futuro programma. Compito impossibile. Il motivo è che alcune delle domande in pendenza sono segrete. Possono essere pubblicate soltanto dopo un certo periodo di tempo dalla presentazione, tipo 18 mesi. Ma tale periodo è più che sufficiente per scrivere un programma, e finanche per distribuirlo, senza poter conoscere se sia già coperto da brevetto o meno, e rischiare di conseguenza la denuncia.
Non si tratta di una questione puramente accademica. Nel 1984 venne realizzato un programma per la compressione dei dati. All’epoca non esistevano brevetti sull’algoritmo di compressione LZW usato in quel programma. Più tardi, nel 1985, l’ufficio statunitense diffuse un brevetto su tale algoritmo, e nel corso degli anni successivi coloro che ne curavano la distribuzione iniziarono a ricevere varie minacce. Era impossibile per l’autore dell’algoritmo di compressione prevedere che potesse subire una denuncia. Non aveva capito che non si poteva più usare liberamente un’idea trovata in qualche pubblicazione.

Supponiamo di trovarci davanti a un elenco di brevetti e voler capire quel che ci è consentito fare. Quando si prova a studiarne le descrizioni, si scopre che sono molto difficili da comprendere, poiché sono redatte in un tortuoso linguaggio legale il cui significato è tutt’altro che facile da afferrare. Spesso i testi stilati dall’ufficio brevetti hanno un senso diverso da quello apparente.
Negli anni ’80 il governo australiano ha condotto una ricerca sul sistema dei brevetti. La conclusione riportava che, al di là delle pressioni internazionali, non sussisteva alcun motivo per l’esistenza di un tale sistema — non era di alcun giovamento per il pubblico — e ne raccomandava l’abolizione, se non fosse appunto per le pressioni internazionali. Lo studio segnalava tra l’altro come gli ingegneri evitassero di leggere i brevetti per imparare qualcosa, consideratane la difficoltà di comprensione. Veniva citata l’opinione di un ingegnere: “Non riesco a riconoscere le mie stesse invenzioni leggendole in brevettese.”

Qualche volta l’idea brevettata appare talmente ampia e basilare che praticamente finisce per coprire un intero settore. È ad esempio il caso della crittazione a chiave pubblica, con brevetto statunitense scaduto nel 1997. Fino ad allora fu tale brevetto ad impedire per la maggior parte il ricorso alla crittazione a chiave pubblica negli Stati Uniti. Un certo numero di programmi in corso di lavorazione vennero bloccati — non furono mai realmente disponibili perché i detentori del brevetto presero a minacciarne gli autori. Poi ne uscì fuori uno, PGP, inizialmente distribuito come software libero. In questo caso sembra che i possessori del brevetto, trascorso un certo tempo prima di lanciare l’attacco, si resero conto che avrebbero potuto subire una cattiva pubblicità. Così imposero delle restrizioni, rendendolo disponibile soltanto per usi non-commerciali, in modo che il programma non potesse conquistare troppo spazio sul mercato. In tal modo per un decennio e oltre, venne fortemente limitato parecchio l’uso della crittazione a chiave pubblica. Non c’era modo di superare quel brevetto. Era impossibile fare altro per scrivere programmi di crittazione a chiave pubblica.

Molti detentori di brevetti sono soliti offrire le relative licenze. Ma spesso richiedono cifre salate. L’azienda in possesso del brevetto per il calcolo dell’ordine naturale voleva il 5 per cento delle entrate lorde di ogni spreadsheet venduto negli Stati Uniti. Qualcuno mi disse che questo era il prezzo ridotto precedente la denuncia — se li si costringeva ad andare effettivamente in tribunale, avrebbero poi chiesto di più.
Può darsi che ci si possa permettere quel 5 per cento per la licenza su uno specifico brevetto, ma cosa succede quando occorrono le licenze su 20 diversi brevetti per realizzare un certo programma? Quanti lavorano in questo settore, mi hanno riferito che a livello pratico due o tre di tali licenze rendono inattuabili simili progetti.

È plausibile che qualcuno possa avere una buona idea la quale, insieme ad altre 100 o 200, costituisca la base per la realizzazione di un qualche tipo di prodotto, e che le grandi aziende vogliano fargli concorrenza. Vediamo perciò cosa potrebbe accadere nel caso cerchi di usare un brevetto per bloccarle. Eccolo dire all’IBM: “No, non puoi competere con me, quel brevetto è mio.” Al che l’IBM replica: “Vediamo un po’ il tuo prodotto. Noi abbiamo questo brevetto, e quest’altro, quest’altro, quest’altro, quest’altro, e quest’altro ancora, rispetto ai quali il tuo prodotto commette delle infrazioni. Se credi di poter controbattere a tutti questi brevetti nell’aula di un tribunale, di sicuro potremo trovarne di nuovi. Perché invece non ci scambiamo le licenze a vicenda?” E allora al brillante inventore non resta che cedere: “Va bene, scambiamoci pure le licenze.” Così può rimettersi al lavoro e portare a termine quel progetto. Ma lo stesso fa l’IBM, la quale ottiene “accesso” al suo brevetto e il diritto a fargli concorrenza, il che significa che tale brevetto non lo ha “tutelato” affatto. Non è questo l’obiettivo del sistema dei brevetti.

Quando i programmatori guardano parecchi dei brevetti sul software non possono far a meno di osservare: “ciò è ridicolamente ovvio!” I burocrati dell’ufficio brevetti tirano fuori ogni tipo di scuse pur di giustificare l’ignoranza su cosa pensano i programmatori. Così replicano: “Ma bisogna considerare come stavano le cose dieci o venti anni fa”. Per poi scoprire che se portate alle estreme conseguenze, simili posizioni diventano controproducenti. Qualsiasi cosa può sembrare non scontata quando se ne scompongono i pezzi, quando la si analizza abbastanza a fondo. Semplicemente svanisce ogni standard di ovvietà, o quantomeno si perde la capacità di giustificare la presenza o meno di tali standard. A quel punto, naturalmente, si finisce per descrivere chiunque presenti una richiesta di approvazione come un brillante inventore; di conseguenza, non possiamo mettere in discussione il loro potere di imporci cosa fare. E quando si decide di andare in tribunale, è probabile che i giudici si mostrino più aderenti al principio della ovvietà. Ma il problema è che per arrivarci bisogna spendere milioni di dollari.

Il software è forse diverso dagli altri campi? Le politiche sui brevetti dovrebbero forse essere diverse per ciascun settore? Se sì, perché? Questa la replica: i brevetti si pongono diversamente da altri settori perché coprono in maniera diversa i relativi prodotti.

Normalmente i pacchetti software sono di ampie dimensioni. Fanno uso di svariate idee in combinazione tra loro. Se il programma è nuovo e non soltanto copiato, allora è probabile ricorra a una diversa combinazione di idee — inserite, ovviamente, all’interno di codice scritto ex-novo, perché non è possibile soltanto enunciare tali idee e farle funzionare come per magia. Bisogna implementarle una dopo l’altra, seguendo quella combinazione.
Ne risulta che anche nella stesura di un programma si fa uso di molte idee differenti, ciascuna delle quali potrebbe essere già stata brevettata da diversa gente. In ogni programma esistono perciò migliaia di elementi, migliaia di punti vulnerabili potenzialmente già coperti dal brevetto di qualcuno.
Ecco perché i brevetti sul software tendono a impedire il progresso del software — il lavoro di sviluppo di un programma. Se fosse “un brevetto per ogni prodotto”, allora i brevetti non impedirebbero lo sviluppo dei prodotti perché ogni nuovo prodotto non risulterebbe già brevettato da qualcun altro. Ma quando un prodotto corrisponde alla combinazione di molte idee diverse, è assai probabile che il nuovo prodotto (in parte o per intero) sia già coperto da qualche brevetto precedente.

Ne risulta che il software è veramente diverso da altri settori, perché quando si lavora con elementi matematici la progettazione è qualcosa di molto più semplice. Di conseguenza bastano un paio di persone per realizzare sistemi decisamente più grandi. Il risultato è che invece di essere vicini a un brevetto per ogni prodotto ci troviamo in un sistema in cui ciascun prodotto ingloba un gran numero di idee che potrebbero essere già state brevettate.

Un modo [per risolvere la questione] è quello di stabilire un buon criterio per l’assegnazione dei brevetti. Ciò può funzionare in un paese che finora non ha ancora autorizzato il ricorso ai brevetti sul software, come accade ad esempio nella maggior parte dei Paesi europei. Una buona soluzione per l’Europa sarebbe semplicemente quella di rinforzare con chiarezza le norme dell’ufficio brevetti europeo, che stabiliscono la non brevettabilità del software. Attualmente l’Europa sta vagliando una direttiva per i brevetti sul software. (Credo cha tale direttiva possa essere di portata più ampia, ma dovrebbe comunque avere importanti implicazioni per il tema specifico). Sarebbe sufficiente modificare ciò affermando che le idee sul software non possano essere coperte da brevetti, per tenere gran parte dei problemi fuori dall’Europa, fatta eccezione per alcuni Paesi che potrebbero trovarsi davanti a dei problemi interni, e uno di questi è la Gran Bretagna.