• Non ci sono risultati.

DALLA TUTELA DEL DIRITTO D’AUTORE

3. Le idee e i principi

4.4. Diritti riconosciuti al fruitore del software

Antonino Geraci… 103 Secondo l’interpretazione fornita dalla Corte, quindi, una siffatta previsione tutela non solo il diritto del fruitore di poter utilizzare il software ma anche la possibilità di rendere operante il principio di esaurimento313.

La soluzione della Corte appare particolarmente attenta al bilanciamento dei contrapposti interessi manifestati dagli utenti e dai titolari del diritto d’autore sul software.

Una siffatta soluzione, peraltro, ha accolto, come sottolinea Sammarco, anche il plauso della dottrina oltre oceano314.

Occorrerà verificare, tuttavia, se l’applicazione pratica dei principi enunciati dalla Corte si tradurrà effettivamente in un benefico incremento del fattore concorrenziale nel mercato del software ovvero comporterà una recrudescenza delle violazione dei diritti patrimoniali dei titolari del diritto d’autore.

Antonino Geraci… 104 detto, è liberamente derogabile dalle parti. Nelle licenze d’uso del software non è affatto infrequente, infatti, rinvenire clausole che escludano espressamente l’attribuzione al licenziatario di un siffatto diritto.

Appare, invece, più incisivo quanto previsto dal secondo comma dell’articolo 64ter LDA. Tale disposizione ha carattere imperativo e cogente prevedendo la nullità di qualsiasi pattuizione volta ad impedire “a chi ha il diritto di usare316 una copia del programma per elaboratore di effettuare una copia di riserva del programma, qualora tale copia sia necessaria per l'uso”.

Il tenore letterale della disposizione consente di affermare come ciò implichi che sia sempre possibile per il fruitore del software effettuare una propria copia di riserva (back-up) al fine di garantirsi la possibilità di utilizzare il software317.

La dottrina318 ha dunque osservato come la realizzazione della copia di riserva debba invece ritenersi vietata quando il titolare dei diritti patrimoniali sul software abbia già provveduto a dotare il singolo fruitore di una copia di riserva del programma.

L’articolo 64ter ultimo comma consente, inoltre, al fruitore del programma, senza l'autorizzazione del titolare dei diritti, di “osservare, studiare o sottoporre a prova il funzionamento del programma, allo scopo di determinare le idee ed i principi su cui è basato ogni elemento del programma stesso, qualora egli compia tali atti durante operazioni di caricamento, visualizzazione, esecuzione, trasmissione o memorizzazione del programma che egli ha il diritto di eseguire” Anche tale disposizione ha carattere inderogabile essendo prevista la nullità della clausole contrattuali volte ad escludere un tale diritto.

Come si è osservato nel precedete terzo paragrafo, la Corte di Giustizia si è basata anche sul contenuto di tale norma per affermare che la realizzazione di un programma, deliberatamente simile ad un software già protetto dal diritto d’autore, non costituisce necessariamente una contraffazione del medesimo. L’autore del software, infatti, non aveva avuto accesso al codice sorgente del software già esistente ma si era limitato ad un

316 La giurisprudenza ha avuto modo di precisare che rientrano nel campo di applicazione di tale disposizione sia l’acquirente che il licenziatario. Cfr. Cassazione, sentenza n. 15968/2002.

317 Cfr. Barbuto, La nuova legge sul software - è in vigore il decreto n. 518/1992 di attuazione della dìrettiva Cee sulla tutela giuridica dei programmi per elaboratore, Impresa, 1993, pag. 1080.

318 A.A. V.V., La legge sul software. Commentario sistematico, Ubertazzi (a cura di), Giuffré, 1994, pag.

150.

Antonino Geraci… 105 attento studio di tale programma al fine di sviluppare un software dalle caratteristiche simili.

E’ opportuno, infatti, precisare come tale diritto non consenta di per sé al fruitore del software di procedere alla decompilazione del programma ossia alla conversione del codice oggetto in codice sorgente. Affinché si possa procedere a tale attività è necessario che ricorrano le condizioni previste dall’articolo 64quater della LDA.

Il tenore di tale norma è il seguente:

‹‹1. L'autorizzazione del titolare dei diritti non è richiesta qualora la riproduzione del codice del programma di elaboratore e la traduzione della sua forma ai sensi dell'art. 64-bis, lettere a) e b), compiute al fine di modificare la forma del codice, siano indispensabili per ottenere le informazioni necessarie per conseguire l'interoperabilità, con altri programmi, di un programma per elaboratore creato autonomamente purché siano soddisfatte le seguenti condizioni:

a) le predette attività siano eseguite dal licenziatario o da altri che abbia il diritto di usare una copia del programma oppure, per loro conto, da chi è autorizzato a tal fine;

b) le informazioni necessarie per conseguire l'interoperabilità non siano già facilmente e rapidamente accessibili ai soggetti indicati alla lettera a);

c) le predette attività siano limitate alle parti del programma originale necessarie per conseguire l'interoperabilità.

2. Le disposizioni di cui al comma 1 non consentono che le informazioni ottenute in virtù della loro applicazione:

a) siano utilizzate a fini diversi dal conseguimento dell'interoperabilità del programma creato autonomamente;

b) siano comunicate a terzi, fatta salva la necessità di consentire l'interoperabilità del programma creato autonomamente;

c) siano utilizzate per lo sviluppo, la produzione o la commercializzazione di un programma per elaboratore sostanzialmente simile nella sua forma espressiva, o per ogni altra attività che violi il diritto di autore.››

Attraverso una siffatta disciplina si mira a tutelare la segretezza del codice sorgente con l’obiettivo di evitare facili imitazioni del software già tutelato dal diritto d’autore319.

Non si può non osservare tuttavia come tale divieto comporti che il software assuma la fisionomia di “una scatola nera, un oggetto opaco (non analizzabile, non

319 Cfr. Pardolesi e Granieri, Il software, AIDA Annali italiani del diritto d'autore, della cultura e dello spettacolo, 2007, pag. 299.

Antonino Geraci… 106 smontabile) cui l’utente ha accesso solo attraverso la descrizione contenuta nei manuali d’uso e attraverso il comportamento osservabile”320.

Il divieto di procedere alla decompilazione del software, tuttavia, non è assoluto in quanto sono previste alcune limitate eccezioni. Come osserva Guglielmetti 321 il legislatore ha avvertito la necessità di contemperare la previsione del divieto di decompilazione con l’esigenza di evitare la creazione di un monopolio delle conoscenze. L’impossibilità di comprendere a pieno il funzionamento del software, analizzandone il codice sorgente, infatti, riduce la libertà di ricerca scientifica e provoca conseguentemente un minor sviluppo di software da parte di operatori economici non ancora affermatesi sul mercato.322

Le deroghe previste, dunque, mirano ad incentivare lo sviluppo di un mercato concorrenziale nel settore del software facilitando la interoperabilità tra diversi programmi.

La decompilazione è quindi lecita se finalizzata a conseguire sia la compatibilità del software che si intende sviluppare con il programma decompilato sia che tale attività sia necessaria al fine di conseguire piena operabilità con altri programmi323.

Secondo la dottrina324, inoltre, la decompilazione non necessita del consenso del titolare dei diritti patrimoniali sul software anche qualora sia finalizzata a conseguire l’interoperabilità del software con componenti hardware. Anche in tale ipotesi, infatti, sussistono le medesime esigenze di tutela del mercato concorrenziale che hanno giustificato le deroghe al divieto di decompilazione previsto dall’articolo 64quater LDA.

In ogni caso, la disciplina contenuta nell’articolo 64quater subordina la possibilità di avvalersi delle deroghe, alla necessità di ottenere il consenso del titolare dei diritti patrimoniali sul software, anche al rispetto di ulteriori condizioni. Ancora una volta il legislatore si preoccupa di evitare che l’attività di decompilazione possa facilitare lo

320 Sartor e Scorza, L’accesso al codice sorgente: alcune considerazioni su libertà, conoscenza e concorrenza in margine al caso Microsoft, Diritto dell’internet, 2006, 4, pag. 329.

321 Guglielmetti, Analisi e decompilazione dei programmi, in A.A. V.V., La legge sul software.

Commentario sistematico, Ubertazzi (a cura di), Giuffré, 1994, pag. 169 e ss.

322 Sartor e Scorza, L’accesso al codice sorgente: alcune considerazioni su libertà, conoscenza e concorrenza in margine al caso Microsoft, Diritto dell’internet, 2006, 4, pag. 330.

323 Guglielmetti, Analisi e decompilazione dei programmi, in A.A. V.V., La legge sul software.

Commentario sistematico, Ubertazzi (a cura di), Giuffré, 1994, pag. 183.

324 Guglielmetti, Analisi e decompilazione dei programmi, in A.A. V.V., La legge sul software.

Commentario sistematico, Ubertazzi (a cura di), Giuffré, 1994, pag. 184.

Antonino Geraci… 107 sviluppo di software contraffatti. In tale ottica si giustifica la previsione di limitare il diritto di effettuare tale attività a coloro che già possiedono legittimamente un esemplare del software325. E’ poi previsto che l’attività di decompilazione, in assenza del consenso del titolare, possa essere posta in essere unicamente qualora la interoperabilità non sia realizzabile mediante il ricorso ad informazioni già facilmente e rapidamente accessibili.

In tale ipotesi, infatti, verrebbe meno la necessità di una deroga al divieto poiché l’obiettivo di facilitare lo sviluppo di raggiungere la piena compatibilità tra diversi software potrebbe essere raggiunto avvalendosi delle predette informazioni.

Per evitare un abuso delle deroghe previste ai fini del raggiungimento della interoperabilità tra diversi programmi è inoltre previsto che l’attività di decompilazione debba essere limitata alle parti del programma originale necessarie per conseguire l'interoperabilità. La dottrina326 ha avuto modo di segnalare, tuttavia, come l’individuazione delle parti necessarie al raggiungimento della interoperabilità, in taluni casi, possa non risultare agevole. In una simile evenienza, sarebbe quindi lecito procedere alla decompilazione del software nel suo complesso.

L’articolo 64quater, infine, prevede tre clausole volte ad evitare l’elusione delle condizioni dettate per beneficiare delle deroghe previste per l’attività di decompilazione.

E’, infatti, fatto divieto di utilizzare le informazioni ottenute per fini diversi dall’interoperabilità e di comunicare quanto appreso a terzi salvo che ciò sia necessario per l’interoperabilità del programma. E’ infine prevista una norma di chiusura che sancisce il divieto assoluto di ricorrere alla decompilazione al fine di realizzare un programma di forma espressiva simile a quello decompilato o comunque per porre in essere violazione del diritto d’autore.

Nonostante le ragioni che hanno portato il legislatore ad introdurre una disciplina così restrittiva in materia di decompilazione non siano prive di fondamento, non può non osservarsi come tale scelta appaia disarmonica rispetto ai principi generali del diritto d’autore.

325 Cfr. Guglielmetti, Analisi e decompilazione dei programmi, in A.A. V.V., La legge sul software.

Commentario sistematico, Ubertazzi (a cura di), Giuffré, 1994, pag. 184.

326 Cfr. Guglielmetti, Analisi e decompilazione dei programmi, in A.A. V.V., La legge sul software.

Commentario sistematico, Ubertazzi (a cura di), Giuffré, 1994, pag. 189.

Antonino Geraci… 108 Come osservano Sartor e Scorza, infatti, “il titolare del software gode di una privativa d’autore pur non ponendo integralmente a disposizione della collettività il proprio sforzo creativo” 327.

Salvo il caso in cui il software sia distribuito attraverso le licenze d’uso a codice disponibile, infatti, l’utente riceve unicamente il codice oggetto del programma, privo del corrispondente codice sorgente.

Il codice sorgente viene mantenuto segreto e di sovente i produttori di software ricorrono anche a misure tecnologiche di protezione, come ad esempio la cifratura, volte a rendere impossibile o quanto meno particolarmente difficoltoso l’accesso al codice sorgente del programma.

L’impenetrabilità del codice sorgente è infine completata attraverso la tutela giuridica di siffatta segretezza, mediante l’imposizione di stringenti limiti alla possibilità di procedere alla decompilazione del programma.

Viene così reciso il connubio tra la protezione giuridica che l’autore riceve per la sua opera creativa ed il corrispondente apporto che tale creazione fornisce allo sviluppo della conoscenza328.

Si verificano, inoltre, ipotesi di una “doppia tutela”, in quanto il codice sorgente è protetto sia tutelandone la segretezza sia attraverso la disciplina prevista per le opere dell’ingegno.

Un contemperamento a tale eccesso di tutela si è avuto, tuttavia, mediante le decisioni assunte dalla Commissione Europea quale organismo preposto alla tutela della concorrenza. Ci si riferisce, in particolare a quanto affermato nell’ambito del caso Microsoft329 nella quale la Commissione Europea ha statuito che il titolare dei diritti patrimoniali sul software è obbligato a rendere accessibili le parti del codice sorgente necessarie affinché possa essere garantita l’interoperabilità tra diversi software330. Pur

327 Sartor e Scorza, L’accesso al codice sorgente: alcune considerazioni su libertà, conoscenza e concorrenza in margine al caso Microsoft, Diritto dell’internet, 2006, 4, pag. 331.

328 Sartor e Scorza, L’accesso al codice sorgente: alcune considerazioni su libertà, conoscenza e concorrenza in margine al caso Microsoft, Diritto dell’internet, 2006, 4, pag. 331.

329 C(2004)900 final Commission decision of 24.03.2004 relating to a proceeding under Article 82 of the EC Treaty (Case COMP/C-3/37.792 Microsoft).

330 “this Decision does not contemplate compulsory disclosure of Windows source code as this is not necessary to achieve the development of interoperable products. The disclosure order should concerns the interface specifications only. Furthermore, as regards the subsequent use of the specifications, the specifications should also not be reproduced, adapted, arranged or altered, but should be used by third

Antonino Geraci… 109 precisando che tale obbligo giuridico è imposto al titolare dei diritti patrimoniali sul software solo ove questo sia un operatore in posizione dominante sul mercato, tale affermazione rappresenta un traguardo importante331. E’ stato infatti pienamente riconosciuto che la segretezza del codice sorgente può rappresentare un serio ostacolo allo sviluppo di un mercato concorrenziale. Sulla base di tale considerazioni, quindi, si impone un ridimensionamento di tale segretezza ogni qualvolta la stessa possa costituire un ostacolo effettivo alla concorrenza.