Brevetti software: un commento

di Andrea Rossato
Pubblicato anche su Punto Informatico 

Prendo spunto dal pacato e lucido intervento di Paolo Zocchi  per entrare nel dibattito in tema di brevettabilità del software, dibattito che trovo, sia detto con franchezza, alquanto deludente. Esso infatti si svolge quasi esclusivamente sul problema dell'incentivo alla creatività ed al progresso tecnologico, ed è volto non solo a comprendere se e quanto i brevetti operino in questa direzione, ma, specialmente da parte di chi risponde affermativamente, a come configurare le norme da adottarsi al fine di incrementarne l'effetto benefico.

In questa sede voglio dare per ammessa l'affermazione secondo la quale i brevetti operino nel senso di "ricollocare la ricerca all'interno delle imprese come un vero investimento e non un costo secco", per usare l'espressione di Paolo Zocchi, sebbene debba ricordare a me stesso che essa è, in base alle evidenze storiche, innegabilmente controfattuale. I primi linguaggi di programmazione ed i primi compilatori, i sistemi operativi, il concetto stesso di sistema operativo, i primi linguaggi di alto livello, le tecniche di programmazione orientata agli oggetti, per citare solo alcuni degli strumenti che quotidianamente ancor oggi usiamo, sono nati in un periodo nel quale non solo la brevettabilità non era concessa per il software, ma financo il suo inquadramento nell'ambito del diritto d'autore era oggetto di dibattito.

Ritengo però che non sia questa la questione sulla quale dovremmo dibattere, quanto se l'istituto del brevetto sia, per come sviluppatosi nei numerosi secoli, quasi sei, dalla sua invenzione, adatto a svolgere le funzioni per le quali viene invocato. E temo la risposta non possa che essere negativa.

Il diritto dei brevetti nasce per dare protezione ad invenzioni o procedimenti industriali che si esprimono nel mondo fisico. Esso attribuisce all'inventore un diritto esclusivo di sfruttamento economico della cosa inventata alla condizione che egli sia disposto a fornire alla collettività tutte le informazioni per riprodurla, al fine di condividere le idee e le conoscenze che condussero alla sua realizzazione. Ciò viene fatto mediante una dettagliata descrizione dell'invenzione, descrizione che deve consentire, ad ogni persona esperta del ramo, di attuarla.

Ora, vi è certamente uno iato tra la descrizione ed il suo oggetto e tale iato costituisce uno dei problemi fondamentali del diritto dei brevetti. Una descrizione è necessariamente una rappresentazione astratta, ma il requisito della riproducibilità dell'oggetto contribuisce a ridurre tale iato. Tuttavia il problema sussiste e ne abbiamo evidenza allorquando vi sia una controversia per supposta violazione. Il giudice, al fine di verificare la sussistenza della violazione, dovrà operare un giudizio di equivalenza per stabilire se due oggetti o due procedimenti siano il prodotto della stessa invenzione. Ma a che livello di astrazione deve essere operato questo giudizio di equivalenza? A quello della descrizione, a quello dell'oggetto concreto, o in un qualche livello intermedio?

Per dare un esempio che possa chiarire la questione, si possono citare casi nei quali un interruttore elettrico fu considerato equivalente ad uno elettronico implementato mediante software. In questo caso, si vede, l'equivalenza è rilevata ad un livello molto astratto, che elimina tutte le differenze materiali della cosa e si concentra sulle sue funzioni.

Si badi però che nell'ambito dei brevetti, in particolare per quel che concerne i procedimenti, opera un limite, quello che impedisce la brevettabilità del risultato. Si pensi al Velcro. Esso può essere utilizzato per chiudere un portafogli, o al posto dei lacci delle scarpe. Ma il brevetto copriva lo specifico utilizzo del Velcro, non il risultato di chiudere un portafogli. Ciò risulta banale, ma cosa succede quando l'oggetto del brevetto diviene il software?

Se osserviamo le descrizioni dei brevetti software nell'ordinamento statunitense vediamo che in esse mai vi si potrà leggere del codice sorgente. Si tratta sempre di descrizioni astratte. Il problema è che un algoritmo, anche dettagliatamente descritto, può essere implementato in un'infinità di modi, con molti linguaggi di programmazione, con costrutti, funzioni od oggetti assai diversi gli uni dagli altri. Si pone quindi il problema della riproducibilità dell'invenzione descritta, e del giudizio di equivalenza tra implementazioni analoghe. A che livello questa deve essere rilevata?

Ciò mostra come lo iato tra descrizione ed il suo oggetto sia, nel caso del software, estremamente amplificato. Con i problemi di gestione di questo iato, demandata al giudice, che si presentano come estremamente problematici.

Ma l'ampiezza dello iato, la distanza tra la descrizione di un algoritmo e la sua implementazione specifica mediante un determinato segmento di codice sorgente, iato che nell'ambito delle invenzioni industriali e dei procedimenti che si esprimono nel mondo fisico è mitigata dalla materiale riproducibilità, non configura la descrizione come una mera idea computazionale, per usare una felice espressione di Stallman? Non serve infatti citare Platone per affermare che un'idea altro non è che un concetto spogliato di ogni concretezza.

E tale iato è gestibile ad opera di un giudice? O non rischiamo forse il piú totale degli arbitri? Quello che dobbiamo domandarci, in altri termini, è se, data la natura del software e il tradizionale operare del diritto dei brevetti, questo sia lo strumento istituzionale adatto per gli scopi che vogliamo attribuirgli.

Una soluzione sarebbe proponibile: la concessione del brevetto potrebbe essere subordinata al deposito, in allegato alla descrizione, del codice sorgente che implementa l'invenzione, e questo solo sarebbe l'oggetto della protezione.

Si comprende però come questa sia una soluzione non certo caldeggiata dalle software house. Il giudizio di equivalenza sarebbe ora molto stringente, e, dall'altro lato, facilmente eludibile. Un tale brevetto rischierebbe di essere inutile.

Ma vi è un'altra ragione che disincentiva i produttori di software dall'approvare un tale compromesso: oggi il codice sorgente è protetto dal segreto industriale; il codice oggetto è protetto dal diritto d'autore e da sistemi di Digital Right Management.
Ora, che le idee che esso esprime, non coperte dal copyright, siano infine oggetto di brevetto non pare tanto dovuto dalla necessità di incentivare il progresso tecnologico, quanto... dall'ingordigia.