Source code escrow: clausole e controlli per proteggere la continuità del software

Risposta in breve. Il source code escrow è un accordo con cui il fornitore deposita presso un soggetto indipendente il codice sorgente e i materiali necessari a ricostruire un software. Il cliente non acquista automaticamente il codice: ottiene l’accesso solo al verificarsi di condizioni di rilascio definite in anticipo, per esempio l’interruzione definitiva della manutenzione o un’inadempienza essenziale non sanata. Un escrow efficace deve specificare cosa viene depositato, con quale frequenza viene aggiornato, come si verifica che sia completo e compilabile, quali diritti d’uso nascono dopo il rilascio e come vengono protetti segreti, componenti di terzi e dati.

A cura dell’Avv. Carmine Coviello — aggiornato all’11 ottobre 2026.

L’escrow interessa imprese che dipendono da software proprietari, piattaforme SaaS, sistemi industriali, applicazioni sviluppate su misura o soluzioni integrate nei propri prodotti. Il valore non è il semplice possesso di un archivio: è la possibilità concreta di garantire continuità operativa senza trasformare il deposito in una cessione indiscriminata della proprietà intellettuale.

Che cos’è il source code escrow e quando serve?

Nel modello più comune partecipano tre soggetti: il titolare o fornitore del software, il cliente beneficiario e l’agente di escrow. Il fornitore deposita codice, istruzioni e materiali tecnici; l’agente li custodisce e, se previsto, li controlla; il cliente può riceverli soltanto quando ricorre una delle condizioni contrattuali di rilascio.

Lo strumento è utile quando un’applicazione è essenziale e non può essere sostituita in tempi compatibili con l’attività dell’impresa. Può riguardare software installato presso il cliente, soluzioni cloud, firmware, algoritmi incorporati in macchinari o codice sviluppato nell’ambito di un progetto congiunto. La valutazione dovrebbe partire dall’audit delle licenze software e dei diritti effettivamente acquisiti, perché l’escrow non corregge una catena di titolarità incompleta.

La Direttiva 2009/24/CE sulla protezione giuridica dei programmi per elaboratore inquadra il software nel diritto d’autore e disciplina gli atti riservati, l’uso da parte dell’avente diritto e la decompilazione nei limiti previsti. In Italia il riferimento è la Legge 22 aprile 1941, n. 633, nel testo vigente. Da questo quadro deriva un punto decisivo: consegnare una copia del sorgente non equivale, da solo, a trasferire i diritti patrimoniali o ad autorizzare qualsiasi modifica e distribuzione.

Che cosa deve contenere davvero il deposito?

Il perimetro deve essere scritto in un allegato tecnico aggiornabile. Depositare soltanto i file sorgente può essere inutile se mancano dipendenze, chiavi, istruzioni di build o documentazione. Per ogni componente conviene indicare versione, hash o altro identificativo, repository di origine, data e responsabile.

Elemento	Controllo minimo	Rischio se manca
Codice sorgente	Versione coerente con quella in produzione	Archivio obsoleto o non utilizzabile
Dipendenze e librerie	Versioni, licenze e modalità di reperimento	Build impossibile o violazione di diritti di terzi
Istruzioni di compilazione	Ambiente, comandi, strumenti e configurazioni	Codice disponibile ma non ricostruibile
Documentazione tecnica	Architettura, database, API e procedure operative	Manutenzione lenta o incompleta
Credenziali e chiavi	Gestione separata, cifrata e soggetta a rotazione	Accesso non sicuro o servizio non ripristinabile
Dati di test	Dati sintetici o anonimizzati e casi di prova	Impossibilità di validare la build o rischi privacy

Per software sviluppato da più soggetti occorre ricostruire la titolarità di ogni modulo. L’accordo di co-sviluppo e la disciplina della titolarità IP aiutano a distinguere codice preesistente, nuove funzionalità, componenti del cliente e contributi dei subfornitori. Nessun agente di escrow può garantire al beneficiario diritti che il depositante non possiede o non è autorizzato a concedere.

Quali verifiche rendono l’escrow realmente utilizzabile?

La semplice conferma di ricezione prova che un archivio è stato consegnato, non che funzioni. Il contratto dovrebbe scegliere un livello di verifica proporzionato al rischio.

1. Verifica formale: controllo del supporto, dell’integrità, della leggibilità e dell’elenco dei file.
2. Verifica di completezza: confronto tra distinta di deposito, versione in produzione e documentazione.
3. Build test: compilazione in ambiente controllato seguendo le istruzioni depositate.
4. Test funzionale: esecuzione di casi concordati per controllare che l’artefatto ricostruito svolga le funzioni essenziali.

Devono essere stabiliti frequenza, responsabilità e conseguenze dell’esito negativo. Un deposito annuale può essere insufficiente per un servizio aggiornato ogni settimana; al contrario, non ogni correzione minore richiede una procedura completa. È preferibile collegare l’aggiornamento a release, patch critiche o intervalli definiti, con un obbligo di sanare rapidamente archivi incompleti.

Come definire le condizioni di rilascio?

Le condizioni devono essere oggettive, documentabili e coordinate con il contratto principale. Formule generiche come “problemi del fornitore” producono incertezza. Tra gli eventi da valutare, senza automatismi, rientrano: cessazione definitiva dell’attività o del prodotto; interruzione della manutenzione oltre il periodo concordato; inadempimento essenziale non sanato dopo diffida; indisponibilità prolungata di un servizio critico; procedure che incidono sulla capacità di continuare il supporto.

Gli eventi legati a crisi o insolvenza richiedono particolare cautela: efficacia e opponibilità dipendono dalla legge applicabile, dal contenuto della clausola e dalla procedura concreta. Il contratto dovrebbe quindi prevedere notificazione, periodo di contestazione, documenti probatori, decisione dell’agente e misure urgenti. È utile distinguere l’accesso temporaneo per emergenza dal rilascio definitivo.

Il beneficiario deve sapere cosa potrà fare dopo il rilascio. La licenza di emergenza può autorizzare uso interno, manutenzione correttiva, modifica e incarico a un sostituto, ma dovrebbe precisare territorio, durata, società del gruppo, numero di installazioni, limiti alla distribuzione e obblighi di riservatezza. Per rapporti transfrontalieri vanno coordinati legge applicabile, foro o arbitrato e provvedimenti urgenti, come illustrato nell’approfondimento sui contratti IP internazionali.

Come tutelare segreti, componenti di terzi e open source?

Il deposito espone materiale sensibile a un ulteriore soggetto. L’agente deve essere vincolato da riservatezza, misure di sicurezza, controllo degli accessi, cifratura, registrazione delle operazioni, segregazione tra clienti e procedure di restituzione o distruzione. La Direttiva (UE) 2016/943 sui segreti commerciali richiede, tra gli elementi della tutela, misure ragionevoli per mantenere segrete le informazioni: contratto e controlli tecnici devono quindi lavorare insieme.

Il fornitore dovrebbe dichiarare quali parti sono proprie, quali provengono da terzi e quali sono open source. Il rilascio non può superare le licenze applicabili. Le dipendenze possono richiedere attribuzioni, notice, disponibilità del codice o limiti d’uso differenti. L’articolo dello Studio su come proteggere il codice sorgente senza brevetto inquadra diritto d’autore, segreto industriale e strumenti contrattuali; la guida sul brevetto software in Europa chiarisce invece quando una soluzione informatica può presentare un carattere tecnico rilevante.

Clausole essenziali del contratto di escrow

• Oggetto e versioni: elenco preciso dei materiali e collegamento al software in produzione.
• Deposito e aggiornamento: scadenze, modalità, hash, notifiche e responsabilità.
• Verifiche: livello dei test, ambiente, report, costi e rimedio in caso di esito negativo.
• Release events: eventi oggettivi, prova, contestazione e tempi decisionali.
• Licenza post-rilascio: usi, modifiche, manutentori esterni, durata e limiti.
• Sicurezza e riservatezza: cifratura, accessi, audit, incidenti e cancellazione.
• Diritti di terzi: inventario delle dipendenze, garanzie e aggiornamento delle licenze.
• Durata e uscita: effetto della cessazione del contratto principale e destino dei depositi.
• Responsabilità: standard di diligenza, limiti coerenti e coperture dell’agente.
• Legge e controversie: coordinamento tra accordo trilaterale e contratto software.

Checklist prima di firmare

• Il software è davvero critico e non sostituibile in tempi accettabili?
• Il fornitore possiede o può concedere i diritti necessari?
• La distinta comprende codice, dipendenze, build, documentazione e test?
• La versione depositata coincide con quella in uso?
• È prevista almeno una verifica proporzionata al rischio?
• Gli eventi di rilascio sono misurabili e contestabili con una procedura rapida?
• La licenza successiva consente manutenzione e continuità, senza eccessi?
• Sicurezza, segreti e dati personali sono gestiti anche dall’agente?
• Open source e componenti di terzi sono censiti?
• Escrow e piano tecnico di disaster recovery sono coordinati?

Domande frequenti

L’escrow trasferisce la proprietà del codice al cliente?

No. Custodia e proprietà sono piani distinti. Il trasferimento o la licenza dei diritti devono risultare dal contratto. In genere il cliente riceve, al verificarsi dell’evento, una licenza limitata alle attività necessarie per la continuità.

Basta depositare il repository Git?

Non sempre. Il repository può non contenere dipendenze, immagini di ambiente, chiavi, script di build, database, manuali e procedure. Occorre provare che un tecnico indipendente possa ricostruire la versione operativa.

Il source code escrow serve anche per un SaaS?

Può essere utile, ma il codice da solo non replica un servizio cloud. Devono essere considerate infrastruttura, configurazioni, dati, domini, certificati, account dei provider e licenze. In alcuni casi serve un piano di continuità più ampio dell’escrow tradizionale.

Chi paga aggiornamenti e verifiche?

Lo stabilisce l’accordo. L’importante è distinguere custodia, aggiornamenti, verifiche ordinarie, test straordinari e procedure di rilascio, evitando costi o responsabilità non allocati.

Un escrow sostituisce backup e disaster recovery?

No. Il backup ripristina dati e sistemi dopo un incidente; l’escrow abilita l’accesso ai materiali quando il fornitore non può o non vuole più garantire il servizio. Le due misure sono complementari.

Per un inquadramento divulgativo dei diritti patrimoniali e delle licenze applicabili anche ai programmi per elaboratore, è disponibile il video dello Studio Copyright: come funziona.

Richiedere una revisione del contratto e del deposito

Prima di accettare un escrow standard, è opportuno verificare dipendenza operativa, titolarità del software, completezza del deposito, eventi di rilascio, diritti post-release e sicurezza. La due diligence IP consente inoltre di integrare questi controlli in investimenti, acquisizioni e finanziamenti.

Per impostare o negoziare un accordo trilaterale, coordinare la licenza software e definire una verifica tecnica proporzionata, è possibile richiedere una consulenza sui contratti software e sulla continuità degli asset IP.

Le informazioni hanno carattere generale e non sostituiscono l’analisi del contratto, dell’architettura tecnica e della legge applicabile al caso concreto.