Pagina pubblicata tra il 1995 e il 2013
Le informazioni potrebbero non essere più valide
Documenti e testi normativi non sono aggiornati

Diritto d'autore

I brevetti software sono morti, viva i brevetti!

di Carlo Piana* – 12.09.05

 

Uno spettro si aggirava per l'Europa, anzi, ancora si aggira: i brevetti software. Il voto del Parlamento europeo ha spedito un siluro alle proposte originali, nessuno si aspettava fino a pochi giorni prima una soluzione così chiara e netta.
Ma siamo sicuri che si sia detta la parola fine?
Non staremo a ripetere la storia, se n'è scritto a sufficienza su questa e su altre riviste, così come dei pericoli che si sarebbero corsi con l'accoglimento dell'originaria proposta della Commissione, approvata telle quelle dal Consiglio Europeo. Parliamo invece di cosa succederà domani in Europa.

Per capire il domani, tuttavia, dobbiamo vedere cosa è successo ieri. In pochi lo dicono chiaramente, ma la realtà è che i brevetti software, sul puro software, sono già una realtà. Lo sono negli Stati Uniti, dove addirittura società che in Europa spingevano per l'adozione di una politica assolutamente sbracata nella brevettabilità, iniziavano a spendere parole critiche verso un sistema che da tutti è visto come fuori controllo. Lo sono, purtroppo, in Europa. Lo sono nonostante una norma precisa li vieti, e questa norma (l'art. 52 della Convenzione Europea sui Brevetti, CEB) sia proprio quella che istituisce e regola l'Ufficio Europeo dei Brevetti (EPO, European Patent Office). Lo sono perché le parole, a differenza dei numeri e dei linguaggi stretti e formali, sono materia duttile, e le norme – compreso l'art. 52 CEB – sono fatte di parole.

Computer implemented inventions

Parole... Le parole in questione sono “brevettare software in quanto tale” e “invenzioni correlate al computer” (computer implemented inventions). Una bella mattina di pochi anni fa qualcuno in quel di Monaco (sede dell'EPO) si sveglia è ha una rivelazione. Il software non vive da solo, ovviamente da solo non ha rilevanza industriale, non consente il miglioramento di un processo o di un prodotto.

Ma il software viene utilizzato su apparecchiature che vengono chiamate “computer”, e chi può negare che il software faccia funzionare meglio un computer: perché migliora l'interrelazione tra uomo e macchina (ed ecco i brevetti sulle interfacce grafiche), perché migliora la capacità di computer di comunicare tra di loro (ed ecco i brevetti sui protocolli e sulle interfacce), perché consente di conservare più dati in uno spazio fisico dato (ed ecco i brevetti sugli algoritmi di compressione), perché consente al computer di proteggere meglio dall'accesso i dati che conserva (ed ecco i brevetti sugli algoritmi di cifratura). Tutte le volte che un principio astratto come un algoritmo può essere usato per far funzionare meglio un computer è allora una “computer implemented invention”. Non viene protetta in quanto tale, ma “solo” quando viene usata per far funzionare meglio un computer. Come dire “io non odio i [neri, bianchi, rossi, gialli] sempre, ma solo quando respirano”, perché è ovvio che un programma per computer non serve a nulla... se non viene fatto “girare” su un computer. Il discorso pare invece funzionare, perché oggi sono registrate come validi brevetti migliaia di “invenzioni” che fanno funzionare un computer.

Come mai, si dirà, non è illegale? No, o meglio, dipende dall'interpretazione che si dà. A persone di buon senso, ovviamente, il trucchetto non sembra avere gran merito, ma pare che ciò sia sufficiente per l'EPO. Una più precisa regolamentazione che impedisse la continuazione della pratica poteva essere presa, così da definire le zone di possibilità di brevettazione, per le invenzioni effettivamente tali che facciano uso di software, e le zone di divieto, ovvero ciò che è brevetto software in quanto tale.

Gli emendamenti apportati dal Parlamento, ancorché non ottimali, si proponevano tale intendimento. Secondo altri, invece, tali emendamenti (e ancor più quelli ulteriori ipotizzati durante la seconda lettura) avrebbero introdotto solo confusione in una norma che era convenientemente disegnata per il compito affidatole. Tali voci sostenevano che la voce per cui essa fosse un grimaldello verso la completa liberalizzazione dei brevetti software era solo uno spauracchio di chi non voleva chiarezza. Ci si chiede come mai allora i maggiori sponsor di tale normativa, che hanno fatto quasi letteralmente carte false perché fosse approvata nella sua originaria estensione, fossero proprio i membri di BSA (Business Software Association), che realizzano quasi esclusivamente software “puro”. Cui prodest?
Brevettare il software o le invenzioni che usano il software?

Ma questa è storia. Ora il problema è se ci accontentiamo di un sistema di incertezza, o se vogliamo dare una vera certezza al sistema? Non ci illudiamo, prima o poi il tema tornerà di attualità, anzi, lo è già oggi. Occorre definire normativamente il dominio di brevettabilità, per consentire la brevettazione delle genuine invenzioni che utilizzino il software. Occorre che tali invenzioni proteggano solo l'utilizzo del software per determinati e limitati compiti, e solo quando la parte inventiva sia nel “mondo reale”, non nel mondo delle idee. In altre parole, occorre che uno sviluppatore di software non sia in pericolo solo perché ha creato e rilasciato puro software.

A me pare molto semplice. Se un'invenzione non è di puro software, nessuno dovrebbe essere contraffattore solo perché ha distribuito software o perché ha installato software in un computer in cui la parte hardware, comunque combinata, non ricada nelle rivendicazioni. Se l'invenzione è di tecnologia, la parte inventiva è nella tecnologia. Senza tecnologia, non è invenzione. Il principio è semplice, si tratta di avere buona fede nel seguirlo, senza tentazioni di proteggere il software oltremisura, con strumenti che hanno come effetto quello di imporre un monopolio ventennale su intere categorie di programmi e, attraverso la brevettazione di protocolli, interfacce, e algoritmi di cifratura, su interi sistemi, e categorie di sistemi.

Mi pare francamente che partendo da tali presupposti, l'individuazione di una più chiara distinzione tra ciò che sia brevettabile e ciò che non lo è sia facile. Almeno per chi pensa e agisce in buona fede e con un minimo di cognizione di causa.

Software e concorrenza: chi vince, chi perde?

Altro discorso è se l'attuale normativa sul copyright, estesa e perfezionata per includere il software tra le opere protette, sia il non plus ultra della protezione, o non necessiti invece di un adeguamento. È mia ferma opinione che il copyright non sia la migliore protezione, ma che se dobbiamo comparare il sistema brevettuale e il sistema del diritto d'autore, il secondo mi sembra sicuramente più adatto. Coloro che affermano che l'insufficiente protezione del software dia una mano a chi non fa altro che inseguire i reali innovatori (ovvero i free rider) non dicono sicuramente una menzogna, ma non colgono nel segno. Il sistema attuale ha garantito una forte innovazione e una certa concorrenza, che ancorché non perfetta è stata sufficientemente vivace, almeno sino ad ora. Ma come tutte le realtà umane anche l'attuale sistema è perfettibile, si tratta di vedere in che direzione e con quali strumenti.

Tuttavia, se una considerazione è possibile su quali siano i reali freni all'innovazione nel settore del software – e dubito che lo sia con certezza – questi non vanno trovati nell'insufficiente protezione degli innovatori, ma dalla scarsità della concorrenza e dalle sacche di immunità da essa. Un caso recentemente riemerso dalle ceneri della memoria dei primi anni novanta lo conferma, ed è il caso di Go Corp. La società aveva concepito un sistema operativo per dispositivi palmari, con un avanzato riconoscimento della scrittura manuale, che avrebbe probabilmente sfondato soprattutto nel mercato asiatico, per consentire un facile riconoscimento dei caratteri pittografici. L'iniziativa non ebbe successo non perché un secondo operatore ha invaso il mercato con un clone, ma perché sfruttando un proprio potere di mercato un concorrente ha fatto “vaporware”, affermando di avere quasi pronto un progetto concorrente, che invece esisteva solo sulle diapositive di Powerpoint (da cui la dizione “Powerpointware”) e poi non vide mai la luce (per chi è curioso, si chiamava PenWindows).

Anche in altri campi la tecnologia migliore non ha “vinto” per demerito tecnico o commerciale, ma per motivi inerenti le barriere tecnologiche e le incompatibilità più o meno artificiali introdotte. Come avvenne in un altro caso storico, nella lotta DR-DOS/MS-DOS, in cui si dimostrò in un'epica causa che erano state introdotte modifiche apparentemente destinate a creare sconcerto in chi si fosse avventurato a sostituire il primo sistema operativo al secondo per far funzionare MS Windows.

Ecco allora che chi si occupa di protezione del software non può ignorare che tale protezione non è un diritto naturale accordato dalle sacre scritture, ma una privativa che eccezionalmente l'ordinamento accorda in quanto la tutela del diritto individuale sposa anche un interesse pubblico, quello a che le opere siano pubblicate (per il copyright), o che una determinata invenzione venga utilizzata e rientri nello stato della tecnica per la sua completa pubblicazione (per i brevetti). Tale protezione dunque incontra i propri limiti nel perseguimento dei fini e come tutti i diritti deve essere contemperata rispetto ai diritti altrui e agli interessi generali.

Accordando un limitato monopolio su un particolare bene giuridico, il diritto di privativa è particolarmente a rischio di eccedere in tale monopolio, contraddicendo il beneficio generale e innalzando le barriere anticompetitive, risolvendosi in un danno all'innovazione. Per cui chi sostiene che il diritto antitrust deve cedere di fronte ai superiori interessi di chi detiene “diritti di proprietà intellettuale”, afferma una cosa inesatta e smentita oltre che dallo spirito della normativa, anche dalle eccezioni che essa consente espressamente. I “diritti di proprietà intellettuale” non sono assoluti, o di rango superiore, ma hanno un rango simile ai diritti concessori, e data la pericolosità del loro abuso nei confronti di altri diritti confliggenti, la loro forza deve essere misurata e bilanciata con attenzione. Sicuramente va tutelato ogni abuso contro di essi (la cosiddetta pirateria), ma vanno consentiti gli usi in buona fede, anche violando i sistemi di protezione che di fatto impediscono tali usi (come i sistemi antiduplicazione, che colpiscono solo gli acquirenti legittimi impedendo di trarre copie di backup di materiale registrato su supporti particolarmente labili, ma non hanno ovviamente nessun deterrente verso le varie mafie della copia abusiva).

La tutela del software è migliorabile?

Questa lunga specificazione serve per illustrare quali sono i punti che il legislatore dovrebbe tener presente nell'estendere la protezione del software introducendo elementi di “brevettualità” nella tutela del copyright. Mi pare di poter apportare alla discussione alcuni ulteriori elementi che, benché non necessariamente originali, possono risultare utili. Il primo è che secondo me non desterebbe scandalo l'allargamento dell'oggetto della tutela dall'espressione letterale del software a tutte le varianti innocue che hanno il solo scopo di aggirare la protezione, e che nella dottrina nordamericana si chiama il “non literary copying”. Il software, infatti, non è una lingua letteraria, e non è necessariamente la sequenza espressiva che determina il valore dell'opera, ma il merito tecnico di essa, per cui i semplici “rimescolamenti” di lavoro di altri dovrebbero essere illeciti.

D'altra parte però non possiamo spostarci in un'ottica interamente brevettuale, ovvero della protezione del trovato in sé. Da un punto di vista nessuno è in grado di affermare la quantità di innovazione in un programma in relazione al complesso delle conoscenze già acquisite che vi stanno alla base. Da un altro punto di vista perché la protezione dell'idea non ha nel software un sufficiente corrispettivo che invece esiste in altri campi, ovvero dell'acquisizione dell'idea nello stato dell'arte, tramite la sufficiente descrizione (che dovrebbe semmai essere dell'intero codice sorgente), e la sua ricaduta nel pubblico dominio in un periodo in cui tale acquisizione ha una sua utilità tecnologica.

Ciò introduce un criterio per bilanciare la privativa, accorciando drammaticamente il tempo di privativa. Né il tempo di protezione del copyright, né quello dei brevetti è nell'ordine di grandezza utile per un'efficacia generale di una privativa siffatta, che è quello delle (poche) decine di mesi (dieci-venti, intendo).
Un'area di completa libertà dovrebbe invece essere consentita per i protocolli, i formati e le interfacce, che non potrebbero mai essere “privatizzati”, perché ciò contraddice l'esperienza degli ultimi cento e più anni di normalizzazione, che hanno consentito importanti risparmi e di concentrarsi nell'innovazione tecnologica, piuttosto che nella disponibilità giuridica di formati e protocolli (dallo scartamento unico dei treni fino a Internet, ma non ancora, ad esempio, nelle prese elettriche!). Invece è proprio lì che oggi si gioca la partita più importante, sull'interoperabilità.
 

* Avvocato, studio legale Tamos Piana & Partners - http://www.avvocatinteam.com

Inizio pagina  Indice della sezione  Prima pagina © InterLex 2005 Informazioni sul copyright