x

x

Protezione del segreto e tutela del software: convergenze, sovrapposizioni, conflitti

Protezione del segreto e tutela del software: convergenze, sovrapposizioni, conflitti
Protezione del segreto e tutela del software: convergenze, sovrapposizioni, conflitti

Il tema della tutela dei programmi per elaboratore elettronico è oggetto della querelle probabilmente più lunga nella storia del diritto industriale. Come noto, il dibattito nacque negli Usa alla fine degli anni sessanta nel solco di una contrapposizione tra gli strumenti giuridici di protezione allora esistenti: e cioè il diritto d’autore, da una parte, ed il brevetto per invenzione industriale dall’altra.

La necessità di promuovere un’industria ancora agli albori, quale quella informatica, e di lasciare impregiudicata la libertà di utilizzo degli algoritmi, considerati come “the basic tools of science”, divenne l’obiettivo prioritario. I più temevano, infatti, che l’adozione dello strumento brevettuale, essendo questo un paradigma di protezione assai più incisivo di quello autoriale, avrebbe portato alla monopolizzazione degli algoritmi di base, a detrimento dell’innovazione successiva e dello sviluppo dell’industria intera.

Ecco, dunque, spiegata per un verso la novella della CBE del 1973, la quale annoverava – e tutt’oggi annovera – il software tra quei subject matter esclusi dalla tutela in quanto non considerabili “invenzioni” per il diritto brevettuale, al pari delle scoperte, delle teorie scientifiche e dei principi matematici. E per altro verso l’introduzione da parte del legislatore (com)unitario di una Direttiva, la 250/91/CEE – oggi la Direttiva

2009/24/CE – tesa a codificare una speciale tutela autoriale per i programmi per elaboratore elettronico. Speciale sì, è bene ricordare, sotto molti profili. Ed invero, oltre alla nota fictio iuris che equiparando i listati dei programmi alla prosa di un romanzo sancisce l’assimilazione del programma per elaboratore elettronico alle opere dell’ingegno, la Direttiva si spinge ben oltre, dettando un articolato di disposizioni applicabili unicamente al software ora qualificato alla stregua di opera dell’ingegno. Ma procediamo con ordine.

E torniamo, dunque, a parlare della appena menzionata finzione giuridica. Si trattava, era evidente già all’epoca, di un’assimilazione forzata, indubbiamente, e per ovvie ragioni, in quanto spinta e indotta da logiche di politica dell’innovazione.

Ed infatti sebbene sia innegabile la presenza di una componente «testuale» nel software, che potrebbe renderlo latamente comparabile alla prosa di un romanzo ovvero ad uno spartito musicale, è altresì risaputo che i codici non rappresentano, in quanto tali, oggetto di interesse per il fruitore del programma, il quale sceglierà il prodotto da acquistare unicamente sulla scorta di considerazioni di natura funzionale.

In ragione di ciò, un’attenta dottrina ha opportunamente criticato l’adozione di una tutela di diritto d’autore appuntata su di una fittizia natura rappresentativa degli elementi testuali del programma, evidenziando piuttosto come questi ultimi, a differenza di altri linguaggi pure protetti dal diritto d’autore, si pensi al linguaggio musicale, mirassero unicamente ad istruire una macchina al fine di ottenere un determinato risultato.

Ora, è vero che la disciplina autoriale è tutt’altro che estranea alla tutela di opere passibili di una realizzazione pratica materiale ovvero di opere aventi carattere scientifico: si pensi, da una parte, ai progetti di architettura, o di ingegneria  e, dall’altra parte, agli scritti accademici e alle pubblicazioni di stampo didattico. Tuttavia, i progetti di architettura e di ingegneria producono sempre, al momento della loro realizzazione, un risultato esteticamente  – o comunque  intellettualmente – apprezzabile  per  l’uomo. E a tal proposito, mi fa piacere ricordare le parole sempre efficaci del Prof. Mario Fabiani il quale, proprio con riferimento alle opere di carattere scientifico, spiegava che esse «non sono protette dal diritto d’autore per quel che di scientifico dicono, ma per come lo dicono e, quindi, per la loro forma espressiva di rappresentazione all’esterno di un certo contenuto intellettuale (di carattere scientifico)».

Al contrario, il programma per elaboratore né nella sua veste testuale (sotto forma di codice sorgente o oggetto), né nel  risultato pratico finale che consente di compiere, riesce a trasmettere al pubblico alcun godimento o arricchimento intellettuale di sorta, essendo privo di ogni valenza rappresentativa.

Nonostante, dunque, ripeto fossero ben evidenti già all’epoca le forzature che la scelta imponeva, il legislatore europeo decise di adottare il paradigma autoriale come strumento ufficiale di protezione per le innovazioni di software. Una scelta, si diceva, dettata più da ragioni di “convenienza economica” potremmo dire, più che da una rigorosa analisi giuridica. Si ricordi, infatti, che il paradigma autoriale, rispetto al  brevetto, presenta indubbi vantaggi per le imprese in termini non solo di immediatezza della protezione, senza bisogno di ottemperare ad alcuna formalità di sorta, né di attendere il vaglio positivo di alcun ufficio, ma anche in termini di gratuità della tutela e di una estensione temporale ben più lunga.

Non solo. La Direttiva pareva effettivamente volta a promuovere lo sviluppo dell’innovazione tecnologica nel campo informatico, in particolar modo premurandosi di tutelare la libera circolazione e appropriabilità delle idee e degli algoritmi sottesi ad ogni programma. Il riferimento va chiaramente all’art. 2, comma 2 della Direttiva, dove si statuisce che se per un verso la tutela si applica a qualsiasi forma di espressione di un programma per elaboratore, “Le idee e i principi alla base di qualsiasi elemento di un programma per elaboratore, compresi quelli alla base delle sue interfacce, non sono tutelati dal diritto d'autore a norma della presente direttiva.”

Ancora, sempre con l’idea di promuovere la circolazione delle idee e dei principi scientifici alla base dei programmi, il legislatore ha previsto due eccezioni ai diritti esclusivi dell’autore.

  • La c.d. “black box analysis” che consente -- al legittimo acquirente del programma -- nel momento in cui effettui “le operazioni di caricamento, visualizzazione, esecuzione, trasmissione o memorizzazione del programma che ha il diritto di effettuare” di compiere quegli atti che gli sono necessari per osservare, studiare e sperimentare il funzionamento del programma.
  • E in secondo luogo, l’eccezione relativa alla attività di decompilazione del programma, ove finalizzata allo specifico fine di conseguire la c.d. l’interoperabilità fra software.

 Questa seconda eccezione consente un qualcosa di più incisivo rispetto alla prima.

Non si limita, infatti, allo studio, dal di fuori, del funzionamento del programma, bensì permette tutti quegli atti di riproduzione e traduzione di porzioni di un primo programma “qualora l'esecuzione di tali atti al fine di modificare la forma del codice sia indispensabile per ottenere le informazioni  necessarie  per  conseguire l'interoperabilità”. In altre parole, la decompilazione di un primo programma per ottenere informazioni necessarie a garantire l’interoperabilità ad un altro programma, creato in via autonoma e indipendente, sarà sempre consentita senza bisogno di chiedere autorizzazione del titolare dei diritti.Sembrerebbe, dunque, uno scenario ottimale.

Ed invero di recente la Corte di Giustizia dell’UE, nella recente sentenza SAS Institute Inc. v. World Programming Ltd., è tornata ad analizzare il perimetro della tutela autoriale concessa al software chiarendo dei principi fondamentali e spiegando, ad esempio, come:

“il vantaggio principale offerto dal paradigma autoriale come strumento di protezione del software “[…] risiede nel fatto che ess[o] concerne soltanto l’espressione individuale dell’opera e offre quindi uno spazio sufficiente a permettere ad altri autori di creare programmi simili, o perfino identici, purché si astengano dal copiare” (corsivi aggiunti)”.

chiarendo così come la soglia di accesso alla tutela sia estremamente esigua e di come l’atto di contraffazione si sia limitato sostanzialmente alla copia pedissequa del listato del programma.

Ancora, in un successivo passaggio, la Corte ha ribadito come in nessun caso la tutela di diritto d’autore apprestata ai programmi può estendersi alla funzionalità del software giacché, come pure evidenziato dall’Avvocato Generale, ciò equivarrebbe “[…] ad offrire la possibilità  di monopolizzare le idee, a scapito del progresso tecnico e dello sviluppo industriale”.

Se tuttavia queste aperture pro-concorrenziali sono certamente apprezzabili, ecco che dei profili d’ombra tuttavia permangono.

Ed in particolar modo pare lecito chiedersi se effettivamente la protezione di diritto d’autore applicata al software riesca, poi, in maniera efficace, a preservare la libera fruibilità degli algoritmi e la loro libera circolazione.

A tal proposito, infatti, si ricordi come se per un verso la  protezione attraverso il diritto d’autore del software fu inizialmente concepita con riferimento al programma espresso in forma di codice sorgente, unica forma del programma comprensibile per l’uomo (recte per il programmatore), l’escamotage giuridico con il quale si giungeva ad equiparare i listati del programma ad un’opera dell’ingegno servì poi ad estendere ulteriormente la protezione anche al software in forma di codice oggetto, che rimane invece sempre qualcosa di incomprensibile per l’essere umano.

Il programma in veste di sorgente, tuttavia, nella maggior parte dei casi non viene divulgato alla  collettività, né tantomeno ne viene fornita copia al legittimo acquirente del software. Le software houses, infatti, preferiscono tenerlo rigorosamente segreto, distribuendo copie del programma “blindate” nella loro veste oggetto. In ultima istanza, quindi, nella gran parte dei casi il codice sorgente, l’unico per il quale la protezione autoriale parrebbe latamente giustificabile, non viene pubblicato e dunque divulgato alla collettività, come accade per ogni opera dell’ingegno, ma funge solo da tramite, da strumento per consentire la protezione della sua traduzione, in forma di codice oggetto, la quale tuttavia, non essendo intelleggibile, non arricchisce in alcun modo l’intelletto umano.

Questa situazione paradossale riflette l’inidoneità del paradigma autoriale a proteggere un bene dalla spiccata valenza funzionale, quale il software e, di conseguenza, a promuovere la libera circolazione degli algoritmi e dei principi matematici sottesi al programma.

Se, infatti, la previsione di un onere di divulgazione sarebbe superflua per le tradizionali opere dell’ingegno, il cui contenuto informativo o rappresentativo diviene immediatamente accessibile al momento della pubblicazione, una siffatta disposizione sarebbe oltremodo necessaria nel caso dei  programmi per elaboratore. Di contro, non solo una tale disposizione manca nell’articolato della Direttiva, ma a ben rileggere quelle che la Direttiva etichetta come “libere utilizzazioni” ecco che si scorgono, invero, delle limitazioni serratissime per l’utilizzatore finale volte proprio a precludergli il compimento di quelle condotte che potrebbero consentirgli di risalire a quelle idee e a quei principi matematici che la  Direttiva stessa profila professa come non proteggibili dal diritto d’autore e, di conseguenza, liberamente posti a disposizione della collettività.

Ed infatti giova ricordare come la black box analisi consente solo quegli atti di riproduzione e di caricamento utili a studiare, come si diceva, dal di fuori il funzionamento del programma e i principi matematici sui quali è  stato stilato. Parimenti, la c.d. opera di decompilazione del programma, l’unica che consente per contro financo quegli atti di traduzione di porzioni del programma da un linguaggio ad un altro, e dunque l’unica eccezione che consentirebbe di risalire in una certa misura alla veste sorgente del programma, è ammessa solo al fine di derivare informazioni necessarie a conseguire l’interoperabilità  del detto programma con altri realizzati in via del tutto indipendente. In nessun altro caso il legislatore ammette il ricorso al c.d. reverse  engineering: una situazione  quasi paradossale  se si riflette, ancora una volta, sulla circostanza che l’attività di decompilazione sarebbe finalizzata a portare alla luce quei principi e quelle idee che non sono proteggibili da diritto d’autore e dunque non coperti dalla privativa.

Ecco, dunque, che si inizia ad intravedere la reale finalità della Direttiva. Ed invero quegli elementi che il legislatore europeo proclama liberi dalla tutela e dunque a disposizione del dominio pubblico di saperi sembrano ricadere, di fatto, a pieno titolo nella disciplina del segreto industriale. Un segreto industriale, per di più, fortificato e reso inespugnabile dalla protezione autoriale: è infatti proprio la tutela del codice oggetto che consente al titolare del diritto di distribuire il software al pubblico, tenendo segrete le sue componenti più preziose.

Un tale sentore è ampiamente confermato dalle disposizioni contenute all’art. 6 della Direttiva software, là dove non solo vengono vietati tout court tutti gli atti di decompilazione del programma, ad eccezione di quelli intesi al perseguimento dell’interoperabilità, ma si introduce una puntuale disciplina circa l’utilizzo delle informazioni segrete ottenute attraverso l’opera di reverse engineering. La decompilazione, infatti, potrebbe portare alla luce informazioni importanti che non sono sottese a quella parte di software deputata a garantire l’interoperabilità con periferiche esterne o altri software. Ecco, allora, che il secondo comma dell’art. 6 introduce, per un verso, un divieto tassativo di comunicazione a terzi delle informazioni  acquisite durante e per il tramite dell’opera di decompilazione e, per altro verso, un ulteriore divieto di impiego di siffatte informazioni per lo sviluppo, la produzione o la commercializzazione di un software sostanzialmente simile nella sua forma espressiva a quello decompilato.

Si tratta, in conclusione, del peggiore dei possibili scenari perché lo strumento del diritto d’autore, adottato per venire incontro alle esigenze di un  settore  industriale allora emergente, si presta, di fatto, ad essere «manipolato» al fine di consentire l’ottenimento di una «super-tutela» per quelle informazioni che, per contro, non dovrebbero essere proteggibili, dando spazio ad una forma di segreto industriale che da una parte è impropria, in quanto cumulativa (e non alternativa) al diritto d’autore  e dall’altra, è eccessiva, nel senso che consente una protezione ben maggiore di quella generalmente garantita dal paradigma del segreto industriale (che ammette, per converso, la decompilazione con mezzi e modalità lecite).