Il rischio di “dipendenza” dal fornitore tecnologico e come tutelarsi con il Software Escrow

Grandi imprese, PMI e imprenditori si affidano sempre più ai software per la gestione delle loro operazioni quotidiane e del loro business. Questa dipendenza può causare interruzioni del servizio, problemi di proprietà intellettuale e controversie con i fornitori, soprattutto in assenza di contratti e altri meccanismi di tutela legale adeguati, come il software escrow. Scopriamo come funziona e perché è fondamentale per proteggere le aziende.

Software Escrow: cos’è e come funziona

L’escrow è un concetto di cui si sente parlare spesso quando si tratta di proteggere i diritti legati al software e alla tecnologia. Vediamo di esplorare questo concetto in maniera, per quanto possibile, semplice e diretta.

Cos’è l’escrow? Immaginiamo che un’azienda, chiamata Cliente A, compri o utilizzi un software creato da un’altra azienda, che chiameremo Sviluppatore B. Questo software è molto importante per il Cliente A perché è fondamentale per la sua attività. Per esempio, potrebbe essere un programma che gestisce tutte le vendite online o l’organizzazione interna dell’azienda.

Ora, c’è un problema: normalmente, il Cliente A riceve solo la versione del software che può usare (chiamata “versione eseguibile“), ma non il codice sorgente del software. Il codice sorgente è come una “ricetta segreta” che permette di capire come funziona il software e di modificarlo o migliorarlo. Se il Cliente A non ha il codice sorgente e qualcosa va storto con lo Sviluppatore B (per esempio, fallisce o smette di offrire supporto), il Cliente A potrebbe trovarsi nei guai perché non potrebbe aggiornare o riparare il software da solo, né chiedere rapidamente aiuto ad un nuovo fornitore, mettendo in gioco la propria continuità aziendale. Ed ecco che entra in gioco l’escrow.

Come funziona l’escrow? Immaginiamolo come una “cassaforte” in cui viene conservata una copia del codice sorgente del software. Questa cassaforte non è gestiita dallo Sviluppatore B o dal Cliente A, che non ne conoscono la combinazione, ma da una terza parte neutrale e indipendente, chiamata agente di escrow. Quest’ultimo potrebbe essere un notaio o una società specializzata che si assicura che tutto sia opportunamente conservato in modo che nessuno possa accedere al codice sorgente senza una buona ragione.

Perché l’escrow è utile? La funzione principale dell’escrow è quella di proteggere il Cliente A da eventuali problemi che potrebbero sorgere con lo Sviluppatore B. Se lo Sviluppatore B fallisce, smette di fornire supporto, o non rispetta i termini del contratto, il Cliente A ha il diritto di richiedere all’agente di escrow di consegnare il codice sorgente. In questo modo, il Cliente A può continuare a usare, mantenere e migliorare il software, assicurando così la continuità delle sue attività aziendali.

L’escrow però non è solo un vantaggio per il Cliente A, ma anche per lo Sviluppatore B. Infatti, lo Sviluppatore B può proteggere il proprio lavoro (la sua “ricetta segreta“) senza dover consegnare il codice sorgente al Cliente A. Lo consegna solo se succede qualcosa di imprevisto.

In sintesi, l’escrow funziona come una forma di assicurazione per entrambe le parti. È un accordo che permette di evitare problemi e di garantire che tutti possano continuare a lavorare e a prosperare senza correre rischi inutili.

Il nuovo “paracadute” delle PMI tecnologiche

I contratti di software escrow non sono tutti uguali; possono essere fatti su misura per adattarsi a diverse situazioni. Qui esploreremo le principali tipologie e capiremo come alcune clausole contrattuali possano offrire vantaggi specifici.

1. Modalità di rilascio automatico (a prima richiesta). Pensiamo a questa modalità come a un “interruttore“. Se succede qualcosa di grave, come il fallimento dello sviluppatore del software (la “software house“) o se lo sviluppatore smette di fornire supporto, non risponde, senza alcuna ragione apparente, il cliente può richiedere immediatamente il rilascio del codice sorgente. Non c’è bisogno di discutere o di aspettare: se una di queste situazioni si verifica, il “caveau” dell’escrow si apre automaticamente, dando al cliente accesso al codice per poter continuare a operare.
2. Rilascio condizionato. In questo caso, il meccanismo è un po’ più complesso. Pensiamolo come una “cassaforte con doppia chiave“. Anche se il cliente ritiene che le condizioni per il rilascio siano state soddisfatte (ad esempio, lo sviluppatore non sta rispettando i termini del contratto), non può semplicemente aprire la cassaforte. Prima, un’autorità indipendente, come un giudice o un collegio arbitrale, deve confermare che le condizioni del contratto siano davvero state violate. Solo allora l’escrow viene rilasciato. Questa modalità protegge maggiormente lo sviluppatore, evitando abusi da parte del cliente.
3. Escrow personalizzati per eventi critici. Questa modalità è fatta su misura per situazioni particolari. Immaginiamo che la software house venga acquisita da un’altra società con il rischio che questa decida di non continuare a sviluppare o mantenere il software. In questo caso, il contratto di escrow può prevedere una clausola specifica che consente al cliente di ottenere il codice sorgente, anche se non si tratta di un fallimento o di un’interruzione dell’attività manutentiva. Occorre quindi, esplorare preliminarmente i possibili eventi critici e inserirli nel contratto.
4. Escrow per software su misura. Immagina di avere un progetto software molto complesso che viene sviluppato in più fasi dietro specifiche istruzioni del committente (che mantiene integralmente la proprietà intellettuale del software sviluppato). Questo tipo di escrow prevede che il codice sorgente venga depositato periodicamente in ogni fase di sviluppo. Così, se lo sviluppo si interrompe in qualsiasi momento (magari perché lo sviluppatore smette di lavorare al progetto), il cliente ha già accesso a tutto ciò che è stato fatto fino a quel punto. È come avere un “diario di bordo“ relativo allo sviluppo del software, sempre aggiornato e disponibile.
5. Escrow multi-livello. Questa modalità è un po’ come un “gioco a livelli“. Il codice sorgente non viene rilasciato tutto in una volta, ma in diverse fasi o “livelli”, a seconda di come procede il progetto o di specifici eventi che si verificano. Ad esempio, il cliente potrebbe ricevere parti del codice ogni volta che lo sviluppatore completa un aggiornamento importante. Questo crea un flusso costante di fiducia e collaborazione tra le parti.

Ogni tipo di contratto di escrow ha i suoi vantaggi. La modalità a rilascio automatico è ideale per chi vuole certezze concrete solo in caso di problemi gravi. La modalità a rilascio condizionato è perfetta per chi vuole circoscrivere gli abusi e garantirsi la continuità aziendale, come dovrebbe fare ogni impresa lungimirante. Le modalità personalizzate, su misura o multi-livello sono ideali per progetti più complessi che richiedono soluzioni creative e flessibili, ad esempio, in caso di sviluppo Agile (per approfondire: “Contratti software e sviluppo ‘Agile’: criticità legali e proprietà del codice” di A. Canella)

In poche parole, il software escrow è come un “paracadute di sicurezza” che può essere costruito in diversi modi per proteggere al meglio sia il cliente che lo sviluppatore del software.

La diffusione del contratto di Software Escrow

La sentenza del Tribunale di Oristano del 9 marzo 2016 viene spesso citata perché consente di comprendere meglio la logica e il funzionamento del contratto di software escrow applicato al contesto italiano. Il caso riguardava un contratto definito come “escrow e sviluppo“, in cui il codice sorgente era stato consegnato direttamente alle parti coinvolte, senza l’intervento di un agente di escrow, ovvero quel terzo soggetto imparziale che garantisce la neutralità dell’accordo.

La sentenza sottolinea che il contratto di escrow, per essere valido, deve essere considerato un “contratto accessorio” che coinvolge un terzo imparziale. Questo terzo agisce come fiduciario delle parti coinvolte in un contratto principale e ha il compito di custodire una “cosa” in garanzia per l’adempimento di un’obbligazione. Nella fattispecie del source code escrow, questa “cosa” è rappresentata dal codice sorgente di un software (per approfondire: “Codice sorgente: la software house è tenuta a consegnarlo al committente?” di A. Canella).

È inoltre stato chiarito che un contratto di escrow non può semplicemente risultare da un accordo diretto tra le due parti interessate (licenziante e licenziatario), come avvenuto nel caso discusso. L’assenza di un agente escrow terzo, indipendente e imparziale, fa sì che l’accordo non possa essere definito tecnicamente come un software escrow.

Come indicato dalla sentenza: “Nel contratto di source code escrow, si ha il deposito presso un terzo di una copia del codice sorgente di un programma prodotto da una parte (licenziante) e concesso in utilizzo a un’altra (licenziatario)… le parti possono pattuire che nel caso in cui il produttore non sia più in grado di garantire manutenzione e assistenza, il cliente possa ottenere dal terzo la consegna di una copia del codice sorgente“​.

Questa sentenza è significativa perché ha stabilito che il software escrow per essere correttamente strutturato deve sempre prevedere un terzo imparziale per garantire la neutralità e la trasparenza nell’adempimento delle condizioni contrattuali. Inoltre, la decisione ha evidenziato come il software escrow serva a proteggere entrambe le parti: 

• il cliente, che ha il diritto di continuare a utilizzare e manutenere il software anche in situazioni critiche, e 
• lo sviluppatore, che può salvaguardare il proprio know-how limitando l’accesso al codice sorgente solo ai casi strettamente necessari.

Questa decisione ha quindi creato un precedente giuridico significativo, promuovendo l’adozione di questo nuovo formato contrattuale. Nell’esperienza diretta del nostro studio legale, il software escrow sta diventando uno standard imprescindibile per ogni collaborazione lungimirante e strategica, garantendo sicurezza e fiducia tra le parti coinvolte.