Di chi è il codice che un'azienda ha pagato?

La proprietà del codice (code ownership) è la titolarità dei diritti su un software commissionato a un fornitore esterno: chi possiede il codice sorgente, chi può modificarlo, e chi decide cosa succede al software quando il rapporto con quel fornitore finisce. La distinzione contrattuale di base è tra cessione della proprietà, dove il codice e i diritti economici passano al committente, e licenza d'uso, dove il fornitore resta proprietario e concede solo il diritto di utilizzo, legato alla durata del contratto di manutenzione. Il rimedio contrattuale classico per il secondo caso è il source code escrow: una copia del codice depositata presso un notaio o un ente terzo, rilasciata al cliente solo se il fornitore fallisce, cessa l'attività o viola gravemente il contratto. Con l'AI generativa il tema si complica ulteriormente: parte del codice può nascere da un assistente e la titolarità dipende dai termini di licenza dello strumento usato, non solo dal contratto col fornitore umano.

Perché l'escrow da solo non basta

Da non confondere con la titolarità dei dati che il software produce o consuma, un tema distinto disciplinato da un accordo diverso: qui si parla del codice, non dei dati che ci transitano dentro. L'errore più comune sul codice è credere che il deposito risolva il problema. Non lo risolve, perché protegge un diritto ma non una capacità operativa. Un codice sorgente ricevuto senza documentazione aggiornata, senza le pipeline di build e deploy, senza le configurazioni dell'ambiente e senza nessuno internamente in grado di leggerlo è di fatto inservibile: l'azienda ha vinto la causa e perso comunque il sistema. Un escrow che funziona davvero prevede il rilascio periodico e verificato di tutto ciò che serve per ricostruire l'ambiente, non solo dei file sorgente, e test di ripristino effettivi, non solo la promessa contrattuale che il deposito esiste. Questo non è un giudizio sui fornitori, la maggior parte lavora in buona fede: è una lacuna nella pratica comune, che la clausola da sola non chiude.

Un caso enterprise concreto

Un'azienda manifatturiera commissiona a una software house un sistema di pianificazione produzione su misura, con contratto di licenza d'uso e clausola di escrow presso notaio. Dopo cinque anni la software house viene acquisita e il nuovo gruppo decide di dismettere quella linea di prodotto. L'azienda attiva l'escrow e riceve il codice, ma senza la documentazione dell'architettura, senza le credenziali dell'ambiente cloud originale e senza nessun consulente in grado di ricostruire la pipeline di deploy in tempi ragionevoli. Il risultato pratico è una riscrittura quasi completa, con costi paragonabili a un nuovo progetto, esattamente ciò che l'escrow avrebbe dovuto evitare. Un problema simile emerge spesso nella modernizzazione di sistemi legacy, dove il codice esiste ma la conoscenza per intervenirci si è persa nel tempo.

Perché conta per chi decide

Chi commissiona software dovrebbe negoziare la proprietà del codice, o quantomeno un escrow con verifica periodica, prima della firma, non quando il fornitore è già in difficoltà. Il tema è collegato a come si struttura il rapporto con il fornitore fin dall'inizio, si veda body rental e time and material vs fixed price, e con quanto debito tecnico quel codice accumula nel tempo senza che nessuno se ne accorga. La domanda utile non è solo "chi possiede il codice", ma "se il fornitore sparisse domani, saremmo in grado di continuare a farlo girare".

Questa voce è informativa e non costituisce consulenza legale: per la stesura di clausole di proprietà intellettuale o di escrow rivolgiti al tuo legale.