approfondimento
-
Tempo medio di lettura 8'

Inadempimenti nei contratti di sviluppo software: come recuperare il codice sorgente?

Pubblicato in: Proprietà Intellettuale
di Margherita Manca
Home > Inadempimenti nei contratti di sviluppo software: come recuperare il codice sorgente?

Quando una società commissiona lo sviluppo di un software, si aspetta di ricevere un prodotto funzionante e completo. Ma cosa succede se il fornitore non rispetta il contratto e si rifiuta di consegnare il codice sorgente? Oppure, peggio ancora, se sparisce senza lasciare traccia?

Il codice sorgente è il cuore di ogni software: senza di esso, non è possibile apportare modifiche, risolvere problemi o migliorare il programma nel tempo. La sua mancata consegna può causare gravi danni economici e operativi, mettendo una società nella difficile posizione di dover ricominciare da zero.

In questo contributo vedremo come prevenire questi problemi con un contratto ben strutturato, quali strumenti legali possano essere usati per recuperare il codice sorgente e quali alternative esistono nel caso in cui il recupero non sia possibile.

Cos’è il codice sorgente e perché è così importante?

Immagina di acquistare una macchina senza avere accesso al motore. Potresti guidarla, ma non potresti modificarla, ripararla o migliorarla senza dipendere esclusivamente dal produttore. Nel mondo del software, il codice sorgente è proprio il “motore” di un programma: l’insieme di istruzioni scritte dagli sviluppatori per farlo funzionare.

Ogni software, da un semplice sito web a un gestionale aziendale, è costruito partendo da un codice sorgente. Questo codice viene scritto in linguaggi di programmazione come Python, Java o PHP e poi trasformato in un formato eseguibile che l’utente finale può utilizzare. Senza accesso al codice sorgente, un’azienda può usare il software, ma non può modificarlo, aggiornarlo o correggerne eventuali problemi senza rivolgersi allo sviluppatore originale (approfondisci, Proprietà del software: il riparto dei diritti tra committenti e sviluppatori – Canella Camaiora).

Ma perché è così importante avere il controllo sul codice sorgente? Facciamo alcuni esempi concreti.

  • Un’azienda commissiona a uno sviluppatore un software gestionale su misura. Dopo qualche anno, il fornitore smette di offrire assistenza o aumenta i costi di manutenzione. Senza il codice sorgente, l’azienda è bloccata: non può aggiornare il software né affidarlo a un altro sviluppatore;
  • Un e-commerce utilizza un sistema personalizzato per gestire gli ordini. Se il codice sorgente non è disponibile e il software smette di funzionare, le vendite si fermano, con perdite economiche potenzialmente enormi.
  • Una startup investe in un’app innovativa sviluppata da una software house. Se nel contratto non è stata prevista la consegna del codice sorgente, la startup non è realmente proprietaria della sua tecnologia e non può svilupparla liberamente.

Questi scenari mostrano come non avere accesso al codice sorgente possa diventare un serio problema operativo ed economico. Ma come si può prevenire questa situazione? Il segreto sta nella redazione del contratto con il fornitore. Nel prossimo paragrafo vedremo quali clausole inserire per proteggersi.

Come prevenire il problema: la corretta redazione del contratto

Di prassi, il codice sorgente appartiene al committente, in quanto è lui a commissionare e finanziare lo sviluppo del software. Tuttavia, molte software house inseriscono nei contratti clausole che limitano l’accesso o la cessione del codice sorgente per tutelare il proprio know-how e mantenere un certo controllo sul software. Questo può portare a situazioni in cui l’azienda committente, pur avendo pagato per lo sviluppo, si ritrova senza la possibilità di modificarlo o evolverlo autonomamente (approfondisci Codice sorgente: la software house è tenuta a consegnarlo al committente? – Canella Camaiora di A. Canella).

Questa criticità è ancora più rilevante nei contratti di sviluppo agile, dove il codice viene sviluppato in modo incrementale e la sua proprietà potrebbe risultare ambigua se non regolamentata con precisione. Per un’analisi dettagliata sulle criticità legali dello sviluppo agile si veda Contratti software e sviluppo “Agile”: criticità legali e proprietà del codice – Canella Camaiora di A. Canella.

Per evitare problemi futuri, è fondamentale che il contratto stabilisca con precisione:

  • chi detiene i diritti di proprietà intellettuale sul codice sorgente;
  • se e in che misura il fornitore può riutilizzare parti del codice per altri progetti;
  • se il codice include componenti open source o di terze parti, che potrebbero limitarne l’uso esclusivo da parte del committente.

Inoltre, è essenziale definire tempi e modalità di consegna del codice sorgente, evitando il rischio che il fornitore possa posticipare indefinitamente la consegna o fornire un codice incompleto e inutilizzabile. Il contratto dovrebbe prevedere:

  • rilasci periodici del codice sorgente durante le fasi di sviluppo;
  • accesso a un repository Git condiviso, per garantire trasparenza e monitoraggio costante;
  • consegna finale del codice sorgente con relativa documentazione, per assicurare la possibilità di manutenzione e aggiornamento.

Uno strumento molto utile per prevenire il rischio di mancata consegna del codice sorgente è la clausola di software escrow. Si tratta di un accordo in cui il codice viene depositato presso un escrow agent, una terza parte fiduciaria, che lo rilascerà al committente solo in determinate circostanze (approfondisci qui Il rischio di “dipendenza” dal fornitore tecnologico e come tutelarsi con il Software Escrow – Canella Camaiora di M. Manca).

Infine, è fondamentale prevedere penali e meccanismi di risoluzione per proteggere il committente da eventuali inadempimenti del fornitore. Una clausola efficace dovrebbe includere:

  • penali economiche per il ritardo nella consegna del codice;
  • condizioni chiare per la risoluzione del contratto, specificando che la mancata consegna del codice comporta la risoluzione immediata;
  • diritto di ottenere il codice sorgente anche in caso di risoluzione, per evitare che il fornitore ne blocchi l’accesso.

Stabilire queste regole fin dall’inizio consente di evitare dispute e proteggere l’investimento tecnologico dell’azienda. Ma cosa fare se il fornitore si rifiuta di consegnare il codice, nonostante le clausole contrattuali? Nel prossimo capitolo vedremo quali azioni legali è possibile intraprendere.

E se il fornitore non consegna il codice?

Quando un fornitore si rifiuta di consegnare il codice sorgente, è fondamentale agire con tempestività e con il supporto di un legale esperto. Il recupero del codice può avvenire attraverso due principali azioni: una diffida per tentare una soluzione amichevole e, se necessario, un’azione giudiziaria per ottenere l’adempimento forzato.

Il primo strumento a disposizione è l’invio di una diffida formale tramite PEC o raccomandata A/R, con cui si intima al fornitore di consegnare il codice sorgente entro un termine preciso. Questa azione ha tre obiettivi:

  • sollecitare il fornitore a rispettare il contratto, risolvendo il problema in via bonaria;
  • dimostrare, in caso di contenzioso, che il committente ha agito in buona fede, tentando una soluzione extragiudiziale;
  • evitare che il fornitore possa utilizzare il codice per scopi impropri, come lo sviluppo di software concorrenti o la rivendita ad altri clienti.

Se il fornitore non risponde o rifiuta di adempiere, è necessario passare alla fase successiva: l’azione legale davanti al tribunale.

Se la diffida non porta a risultati concreti, infatti, il committente può avviare un procedimento cautelare d’urgenza presso il tribunale. Si tratta di una procedura rapida che ha lo scopo di ottenere immediatamente il codice sorgente o, in alternativa, impedirne l’uso improprio.

Nel ricorso, l’azienda richiederà al giudice:

  • in prima battuta, l’ordine di consegna immediata del codice sorgente. Il giudice, verificato il diritto del committente, può imporre al fornitore di fornire il codice senza ulteriori ritardi;
  • se la consegna non è possibile o il fornitore si oppone, anche il sequestro del codice sorgente è un’opzione valida. Il tribunale può disporre che il codice venga affidato a un soggetto terzo (ad esempio, un perito o un custode giudiziario), impedendo sia al fornitore sia al committente di utilizzarlo fino a una decisione definitiva. Questo serve a evitare che il fornitore possa sfruttarlo per sviluppi non autorizzati o che il committente lo utilizzi senza rispettare eventuali diritti residui del fornitore.

Questa strategia garantisce la massima tutela per l’azienda e permette di riprendere il controllo sul software senza subire danni operativi o economici irreparabili.

Ogni fase di questo processo deve essere gestita con il supporto di un legale competente, in grado di redigere correttamente la diffida e impostare l’azione giudiziaria nel modo più efficace. Agire rapidamente è fondamentale: ritardare l’intervento può significare perdere il controllo sul codice e subire danni irreversibili.

Se il codice sorgente resta irrecuperabile, esistono comunque strategie alternative per riprendere il progetto. Nel prossimo paragrafo vedremo come valutare soluzioni come il reverse engineering o la sostituzione del software.

Cosa fare se il codice sorgente è irrecuperabile?

Se il codice sorgente è definitivamente perso, la situazione non è ideale, ma ci sono soluzioni. La prima, la più ovvia, è sviluppare un nuovo software con un altro fornitore. Questa strada offre un controllo totale sul progetto, la possibilità di aggiornare la tecnologia e correggere eventuali limiti del vecchio sistema. Tuttavia, tempi e costi possono essere significativi, specie per software complessi.

Un’alternativa più tecnica è il reverse engineering, cioè ricostruire il codice partendo dall’eseguibile. Se il software ha database accessibili e API documentate, potrebbe essere possibile ricrearlo senza partire da zero. Attenzione però: questa pratica può violare licenze e diritti d’autore, quindi è essenziale valutare i rischi legali con un esperto.

Infine, se il software non è insostituibile, si può optare per una soluzione già esistente. Acquistare o adottare un software alternativo può essere la via più veloce e meno onerosa, anche se potrebbero esserci limiti in termini di personalizzazione e compatibilità con i sistemi aziendali.

Come evitare il problema in futuro? La chiave è un contratto ben strutturato: il codice sorgente deve essere esplicitamente ceduto o reso accessibile tramite escrow, con scadenze di consegna e penali per eventuali ritardi. Il software non è solo uno strumento operativo, ma un asset strategico: proteggere il codice significa garantire indipendenza, sicurezza e continuità aziendale.

© Canella Camaiora Sta. Tutti i diritti riservati.
Data di pubblicazione: 19 Marzo 2025

È consentita la riproduzione testuale dell’articolo, anche a fini commerciali, nei limiti del 15% della sua totalità a condizione che venga indicata chiaramente la fonte. In caso di riproduzione online, deve essere inserito un link all’articolo originale. La riproduzione o la parafrasi non autorizzata e senza indicazione della fonte sarà perseguita legalmente.

Margherita Manca

Avvocato presso lo Studio Legale Canella Camaiora, iscritta all’Ordine degli Avvocati di Milano, si occupa di diritto industriale
Leggi la bio
error: Content is protected !!