Questo articolo è un estratto del capitolo 2 del libro "Software licensing & data governance. Tutelare e gestire le creazioni tecnologiche" (Apogeo/Feltrinelli, settembre 2020) ed è già stato pubblicato liberamente online sul sito Apogeonline.com in questo post sotto licenza Creative Commons Attribution - Non Commercial - Share Alike 4.0.
I temi di questo articolo verranno approfonditi nel corso online "Strategie e modelli contrattuali per cedere e acquisire software" che si terrà a inizio dicembre (maggiori dettagli).
______________________________________
Dopo che le scelte legislative degli anni Ottanta e Novanta avevano indicato la strada del copyright a scapito del brevetto, il dibattito sulla tutela del software non si assopì del tutto e a tratti registrava qualche voce a favore di un’introduzione della possibilità di brevettazione. E non come soluzione sostitutiva del copyright, bensì come soluzione aggiuntiva e complementare al copyright. Il software sarebbe quindi diventato uno dei più importanti casi di creazione intellettuale soggetto a una duplice tutela, o forse triplice se aggiungiamo la prassi ormai radicata di sfruttare l’istituto del segreto industriale sul codice sorgente.
L’aspetto bizzarro era che tra queste voci vi erano anche quelle di alcune aziende che invece solo un decennio prima avevano spinto decisamente verso la strada del copyright perché ritenuta meno complessa e dispendiosa. Una volta uscite dal mondo delle startup e diventate solide aziende multinazionali, quasi monopoliste nel loro settore, quelle stesse realtà magicamente avevano cambiato idea e iniziavano a trovare appetibile la strada del brevetto.
Il dibattito arrivò presto anche nelle corti statunitensi, che, sfruttando il diverso livello di creatività giuridica consentito ai giudici degli ordinamenti di common law, iniziarono a delineare alcuni casi di applicabilità del modello brevettuale al software in sovrapposizione al copyright e in sostanza a legittimare la prassi. L’ultimo step fu opera dell’Ufficio Brevetti degli Stati Uniti (USPTO), il quale nel 1996 pubblicò un documento intitolato Final Computer Related Examination Guidelines (Linee guida definitive per l’esame dei brevetti relativi ai computer) nel quale si stabiliva:
L’applicazione pratica di un’invenzione relativa al computer è passibile di brevettazione. Questo requisito può essere separato dai divieti variamente formulati contro la brevettazione di idee astratte, leggi della natura o fenomeni naturali.
L’USPTO iniziò quindi ufficialmente ad accettare brevetti per quelle che vengono più propriamente chiamate computer implemented invention (ossia, invenzioni implementate attraverso il computer) ma che di fatto integrano una brevettazione di algoritmi e codice dunque di semplice software.
Il dibattito non riguardò solo gli USA ma arrivò anche da quest’altra parte dell’oceano, pur con qualche anno di ritardo. Si giunse quindi a una proposta di direttiva europea che aprisse formalmente la strada alla brevettazione di software anche nel vecchio continente: la Proposta di Direttiva CE COM(2002)0092 sulla brevettabilità delle invenzioni a mezzo elaboratore.
L’iter di approvazione (Francesco Paolo Micozzi nell’articolo I software e i brevetti offre una breve cronologia della proposta di direttiva. L’articolo è uscito sul numero 31 del 2005 della rivista LinuxPro ed è disponibile liberamente online sul sito dell’autore) venne però fermamente bloccato dal Parlamento Europeo con una storica votazione ad amplissima maggioranza che si è tenuta il 5 luglio 2006 e ha chiuso definitivamente un acceso confronto politico durato circa cinque anni. Visto il risultato schiacciante, la Commissione Europea all’epoca dichiarò che non avrebbe più riprovato a proporre una direttiva volta a introdurre la brevettazione di software.
Ciò nonostante, almeno negli USA i brevetti software rimangono una realtà ormai consolidata. E in Unione Europea, pur con la netta decisione del Parlamento, le aziende software riescono lo stesso a ottenere dall’Ufficio Brevetti Europeo la registrazione di computer implemented invention sfruttando l’elasticità delle maglie del sistema. Benché sia indiscusso il divieto di brevettare software in sé, le aziende interessate a ottenere una tutela brevettuale trovano il modo di camuffare le domande di brevetto e di dimostrare che l’invenzione oggetto della domanda di brevetto non è puro software ma qualcosa di più complesso di cui il software è solo una componente (anche se il più delle volte è la componente principale).
Commenti