Il termine escrow (escrow agreement) individua quel tipo particolare di contratto che si perfeziona tra un’azienda produttrice di software (il licenziante o fornitore), un cliente (il licenziatario) ed un terzo soggetto imparziale, detto “agente di escrow”. Il licenziante, secondo lo schema tipico di questo contratto, concede verso un corrispettivo l’utilizzo di un programma per elaboratore di propria produzione al licenziatario, senza trasmettergli il codice sorgente, e deposita, nel contempo, una copia del programma stesso, completa del codice sorgente, presso l’agente di escrow, con l’accordo che, nel caso in cui il fornitore non sia piu’ in grado di adempiere alle prestazioni previste nel contratto (in genere manutenzione e assistenza), il licenziatario possa ottenere dall’agente di escrow il rilascio del codice sorgente.

* Il presente scritto costituisce uno schema guida della tesina – relazione finale da presentarsi al master in Internet Law frequentato nell’a.a. 2002-2003 presso l’European School of Economics di Roma

Ma cosa si intende per codice sorgente? Il codice sorgente, che distinguiamo dal codice oggetto, viene definito come quella sequenza di istruzioni indirizzate all’elaboratore e che, una volta applicate dall’elaboratore stesso, “sostanziano e materializzano il programma” [1]. Il codice oggetto, al contrario, non e’ altro che la traduzione in linguaggio macchina del codice sorgente, che l’elaboratore effettua servendosi di un apposito programma traduttore. Per fare un paragone, si potrebbe pensare ad un codice segreto che, per essere compreso, necessita di una chiave crittografica. L’elaboratore, in altre parole, si serve delle proprie chiavi di decrittazione per decifrare il codice sorgente e permettere, in tal modo, il funzionamento del programma “comprensibile”.
Ora, va sottolineato che, per intervenire sulla struttura del programma, non basta conoscere il codice oggetto, ma occorre la piena disponibilita’ del codice sorgente, che costituisce il vero “nocciolo” del programma stesso: senza quest’ultimo, non e’ possibile effettuare quelle operazioni di adattamento, di modifica o di “riparazione” di cui il software puo’ necessitare.
Nel contratto di escrow, come abbiamo sottolineato, vengono generalmente previste l’assistenza e la manutenzione a carico del fornitore, che rimane in possesso del codice sorgente e puo’ cosi’ agevolmente intervenire sul software per effettuare le operazioni che si rendono opportune per il suo funzionamento ottimale, per la correzione degli errori originari, per l’aggiornamento e l’implementazione dello stesso. Tali operazioni, peraltro, vengono praticate piuttosto di frequente, visto che i programmi di cui parliamo sono, di norma, “personalizzati”, ossia costruiti sulle esigenze della impresa licenziataria o, molto spesso, creati appositamente per quest’ultima e che, pertanto, abbisognano di continui adattamenti e correzioni. Cio’ significa che, nel caso in cui il fornitore non potesse, per le piu’ varie cause (cessazione dell’attivita’, fallimento, e cosi’ via), continuare ad assistere il cliente, questi si troverebbe nell’impossibilita’ di usare correttamente il prodotto acquistato.

In tali casi, l’unica via per il licenziatario (che, giova ricordarlo, non dispone del codice sorgente) e’ costituita dal reverse engineering. Con questo termine si intende quell’attivita’ di “decompilazione” del programma, ovvero quella serie di operazioni che, partendo dal codice oggetto, portano alla “decifrazione” del codice sorgente. Si pongono, a tal punto, due tipi di problemi.
Il primo e’ che il reverse engineering e’ estremamente dispendioso e complesso, e richiede una enorme quantita’ di lavoro (oltremodo qualificato), in modo da compromettere del tutto l’economicita’ del contratto di fornitura di software. In altre parole, non vi e’ convenienza nel sottoporre un programma a decompilazione per modificarne le caratteristiche: e’ quasi sempre piu’ opportuno dotarsi di un programma “nuovo”.
In secondo luogo, non dobbiamo dimenticare che la legge sul diritto d’autore, che tutela il software come opera dell’ingegno, consente la decompilazione senza autorizzazione del licenziante soltanto allo scopo di consentire l’“interoperabilita’” del software [2] (art. 64quater) o, secondo un’interpretazione estensiva, al fine di correggere quegli errori che non permettono il corretto uso del programma (art. 64ter).  Tali possibilita’, ovviamente, presuppongono l’inadempimento del fornitore, il quale non voglia (o non possa) riparare o adattare il software licenziato. In questo caso, comunque, l’utente potrebbe operare una messa in mora del produttore e, in caso di inerzia di quest’ultimo, provvedere alla decompilazione del programma [3]. Ma va segnalato che, di regola, i contratti di licenza di software prevedono espressamente il divieto di praticare il reverse engineering [4]: cio’ chiude al licenziatario ogni possibilita’ di provvedere da se stesso, nei rari casi in cui risulti conveniente, alla riparazione o all’adattamento del programma acquistato.
E’ proprio qui che si evidenzia, in tutta la sua portata risolutrice, la funzione del contratto di escrow. La posizione del fornitore viene tutelata da facili abusi da parte del cliente, posto che i codici sorgente costituiscono il patrimonio di maggior valore di qualsiasi casa di software mentre, d’altro canto, anche il licenziatario si sottrae ai rischi di possibili danni derivanti da un inadempimento del produttore.
Si tratta ora di individuare la struttura del contratto di escrow sotto il profilo della causalita’. Bisogna, cioe’, una volta premessa l’esistenza di norme che vietano l’attivita’ di reverse engineering, valutare se il contratto in esame costituisca una fattispecie di negozio in frode alla legge, in quanto diretto ad eludere le suddette norme consentendo al contraente il raggiungimento di un risultato illecito: quello, appunto, di disporre del codice sorgente.

Tale ipotesi, gia’ ad una prima lettura, non sembra reggere. Il contratto di escrow, infatti, non consente assolutamente alcuna attivita’ di reverse engineering, ma prevede direttamente la possibilita’ del rilascio del codice sorgente da parte di un soggetto imparziale, il quale provvede da se’ a constatare se siano verificate le previsioni contrattuali che giustificano tale rilascio. A riprova di tale osservazione vi e’ il fatto che la cessione di un codice sorgente, di per se’, non costituisce affatto attivita’ vietata: anzi, tale cessione potrebbe ben essere (e a volte lo e’) oggetto di contratti di licenza o vendita di software. E neppure potrebbe parlarsi di negozio indiretto, visto e considerato che i contraenti non si prefiggono lo scopo ulteriore di cedere il codice sorgente, bensi’ prevedono tale eventualita’ solo in via accidentale, a garanzia della posizione del licenziatario. D’altra parte, come abbiamo appena osservato, nulla vieterebbe alle parti di concludere una cessione di software che abbia per oggetto anche il codice sorgente.
La struttura causale del contratto, quindi, si pone come fattispecie atipica ma concretizzante interessi  tutelabili, e quindi perfettamente lecita.
L’atipicita’ del contratto di escrow, alla luce di quanto finora osservato, si presenta come un dato assolutamente innegabile. E lo stesso non puo’ neppure essere qualificato come contratto “misto”, visto che non e’ riscontrabile in alcuna figura contrattuale tipizzata il meccanismo in virtu’ del quale avviene il rilascio del codice sorgente, ne’ potrebbe essere altrimenti, data la peculiarita’ assoluta dell’oggetto stesso del contratto: da una parte il codice oggetto e dall’altra il codice sorgente, entrambe figure sconosciute, fino a pochi anni fa, nel nostro mondo giuridico. Ma, lo ribadiamo, e’ il meccanismo stesso del rilascio del codice a costituire un fatto del tutto nuovo nella prassi contrattuale, che non e’ dato rinvenire in alcuna fattispecie preesistente.
Per quel che riguarda le diverse condizioni al verificarsi delle quali avviene il rilascio vanno citate: il fallimento o la bancarotta del fornitore; la mancata osservazione da parte del fornitore di una determinata previsione contrattuale; l’assorbimento dell’azienda produttrice da parte di altra azienda che non intende gestire il software licenziato, ad esempio per un conflitto di interessi; il prodursi di errori nella manutenzione del software. Ricorrendo tali eventi, che l’agente di escrow provvedera’ a certificare, il cliente potra’ ottenere il rilascio del codice sorgente. Tale rilascio, inoltre, potra’ avvenire automaticamente, con la sola notifica all’agente di escrow del verificarsi di una delle condizioni (c.d. “opzione di prima chiamata”), oppure “in seconda istanza”: in quest’ultima ipotesi il depositario rilascia il codice soltanto in seguito ad una verifica delle condizioni contrattuali, che puo’ essere riservata anche ad un’autorita’ amministrativa o a un collegio arbitrale. In genere, le parti sono obbligate a designare entro breve tempo (di norma tre giorni) sia i soggetti incaricati a condurre il negoziato, sia gli eventuali arbitri, ai quali le parti stesse presentano entro sei giorni le proprie richieste.

Entro l’ottavo giorno lavorativo, poi, gli arbitri emettono la decisione e dispongono l’eventuale rilascio del codice sorgente, in formato digitale e leggibile dal sistema operativo del licenziatario.
Le forme del contratto di escrow conosciute nella prassi odierna sono molteplici.
La piu’ diffusa e’ quella del contratto plurilaterale, stipulato dal fornitore del software, dal cliente e dall’agente di escrow, i quali negoziano l’accordo contestualmente alla licenza d’uso. Il contratto, naturalmente, costituisce un vincolo tra tutti e tre i soggetti.
Una forma differente di escrow e’ costituita da un contratto bilaterale, stipulato dal fornitore del software direttamente con l’agente di escrow, senza la sottoscrizione del cliente. Quest’ultimo, infatti, viene nominato come beneficiario dell’accordo, ma non rappresenta una delle parti del contratto. In tal modo, tutti i nuovi utilizzatori di un determinato programma possono partecipare e godere dei diritti originati dal contratto evitando di espletare complesse formalita’ legali: e’ questa una tipica fattispecie di contratto “aperto”.
Vi e’ poi il Master Software Escrow Agreement, un’ulteriore tipologia di accordo che, rispetto alle precedenti, semplifica il processo contrattuale, poiche’ prevede un accordo principale che puo’ essere utilizzato anche da diversi fornitori di software in contemporanea. Questo tipo di contratto consente all’utilizzatore finale di godere delle medesime garanzie di rilascio del codice sorgente per differenti pacchetti di software acquistati da diverse case produttrici.
Ricordiamo, inoltre, che spesso il contratto di escrow viene utilizzato per regolare i rapporti tra programmatori e distributori: in questo caso, l’escrow viene scelto perche’ non sono ne’ i licenziatari (che possono essere tanto i distributori quanto gli utenti finali) ne’ un’azienda ad essere titolari dei diritti d’autore sul software, bensi’, ovviamente, i programmatori.
Va poi sottolineata, a prescindere dalla scelta della fattispecie contrattuale da utilizzare, la rilevanza di alcuni punti che l’accordo dovrebbe in ogni caso prevedere al fine di tutelare al massimo l’utente dalle possibili patologie del contratto di licenza del software, che abbiamo visto consistere principalmente in errori originari e in difetti di aggiornamento o di implementazione dei programmi stessi.
Tra questi punti, nello specifico, si evidenzia in primo luogo la facolta’ di accedere, al verificarsi di determinate condizioni, all’intero complesso del materiale depositato, e non solo al codice sorgente. In secondo luogo, andrebbe prevista la facolta’ di utilizzare, modificare ed implementare il materiale stesso allo scopo di supportare, manutenere e sviluppare il software o i software acquistati.

Sarebbe poi utile al cliente il diritto di verificare il materiale, in particolare il codice sorgente, in modo da accertarsi che il materiale depositato sia e rimanga completo: scendendo nel dettaglio, ricordiamo che per essere completo, il materiale depositato deve contenere la documentazione particolareggiata e le informazioni riguardanti l’host, i computer sorgenti e quelli di destinazione usati dal fornitore, i sistemi operativi, i compilatori e le utility. 
Di non poca importanza, infine, la facolta’ di ricevere il materiale aggiornato, necessario per allineare costantemente la documentazione e il codice sorgente all’ultima versione del prodotto, informando dei suddetti aggiornamenti tutte le parti coinvolte nell’accordo.

In conclusione, l’utilita’ pratica dello strumento contrattuale da noi preso in esame appare in tutta la sua evidenza.
Un buon contratto di escrow puo’ evitare alle parti lunghe controversie giudiziarie, consentendo al fornitore un’ottima protezione del suo bene piu’ prezioso (il software, appunto) e tutelando con strumenti rapidi ed efficaci la posizione dell’utente, invogliandolo maggiormente all’investimento “tecnologico”, oltre ad offrire al giurista nuovi e stimolanti spunti per le proprie osservazioni.

Note del testo

[*] Il presente scritto costituisce uno schema guida della tesina – relazione finale da presentarsi al master in Internet Law frequentato nell’a.a. 2002-2003 presso l’European School of Economics di Roma 
[1] G. De Santis, La tutela giuridica del software, in Informatica e ordinamento giuridico, Milano, 2000, p. 67
[2] Si tratta, in questo caso, di consentire al software di interagire con altri programmi, ad esempio all’interno di un sistema complesso come un mainframe o una rete.
[3] E’ sempre bene tener presente che, nel caso in cui non sia configurabile un obbligo giuridico da parte del produttore, ad esempio perche’ il contratto di manutenzione viene stipulato con un altro soggetto, non e’ possibile configurare il relativo obbligo di riparazione in capo al produttore stesso. Il suo inadempimento, pertanto, sara’ irrilevante ai fini dell’attivabilita’ del reverse engineering.
[4] Va tuttavia ricordato che l’art. 5 della direttiva CE n. 250 del 1991 prevede la possibilita’ di adattare un software ove cio’ si renda necessario per permetterne l’utilizzazione secondo lo scopo a cui esso tende: cio’ implica anche la facolta’ di correggerne gli errori.

Scritto da