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à.
|