Abstract
Il caso riguarda un’applicazione iOS/Android finanziata dal committente, rispetto alla quale lo sviluppatore ha rifiutato la consegna del codice sorgente in assenza di una clausola espressa di cessione. La decisione qualifica il rapporto come contratto di appalto e afferma che, nel software custom, il codice sorgente costituisce parte essenziale della prestazione dovuta, salvo patto contrario. Il mancato rilascio viene qualificato come inadempimento grave, idoneo a giustificare la risoluzione del contratto anche indipendentemente da vizi funzionali della piattaforma, con rilevanti implicazioni in termini di governance tecnologica e autonomia del committente.
Il caso dello sviluppatore che rifiuta di consegnare sorgente
La vicenda nasce da un rapporto contrattuale avviato nel marzo 2020 e integrato nell’aprile 2021, avente ad oggetto lo sviluppo di un’applicazione iOS e Android realizzata su commissione per lo scambio di modellini da collezione. Il progetto era finanziato integralmente dalla società committente ed era pensato come prodotto autonomo.
Secondo la committente, l’applicazione consegnata non rispettava le caratteristiche promesse e, soprattutto, lo sviluppatore si rifiutava di consegnare il codice sorgente, sostenendo che la cessione non fosse prevista dal contratto. Questo rifiuto impediva alla società di intervenire autonomamente sul software, di aggiornarlo o di affidarne la manutenzione a terzi.
La controversia approda così davanti al Tribunale di Padova, che decide con sentenza n. 1149/2024 del 20 giugno 2024, pronunciata ai sensi dell’art. 281-sexies c.p.c. Il Tribunale accoglie integralmente la domanda della committente, qualifica il rapporto come contratto di appalto, dichiara la risoluzione dei contratti del 30 marzo 2020 e del 15 aprile 2021 e condanna la convenuta alla restituzione delle somme versate.
Lo sviluppatore propone appello. Il giudizio di secondo grado viene incardinato davanti alla Corte d’Appello di Venezia, Prima Sezione Civile, iscritto al n. 1424/2024 R.G.A. L’atto di citazione in appello viene notificato il 26 agosto 2024 e l’impugnazione investe, tra l’altro, la titolarità del codice sorgente, la qualificazione dell’inadempimento come “grave” e l’eccezione di decadenza dalla garanzia ex art. 1667 c.c.
Il giudizio di appello, tuttavia, non arriva a una decisione sul merito. Il 13 marzo 2025 l’appellante deposita atto di rinuncia agli atti di causa. Con sentenza della stessa data, la Corte d’Appello di Venezia dichiara l’estinzione del giudizio ai sensi dell’art. 306 c.p.c., senza statuizione sulle spese.
Dal punto di vista processuale, la pronuncia veneziana si limita a prendere atto della rinuncia. Sul piano sostanziale, però, l’effetto è rilevante: la motivazione della sentenza n. 1149/2024 del Tribunale di Padova resta integralmente ferma, non essendo stata né riformata né corretta in sede di gravame.
È questo dato – la stabilizzazione della motivazione di primo grado attraverso l’estinzione dell’appello – che rende la vicenda meritevole di attenzione. Anche in assenza di una pronuncia di merito della Corte d’Appello, l’impostazione seguita dal Tribunale di Padova diventa il riferimento concreto per leggere i rapporti tra software su commissione e codice sorgente, in continuità con altri precedenti di merito (approfondisci: Codice sorgente: la software house è tenuta a consegnarlo al committente? – Canella Camaiora).
Ma il codice sorgente va consegnato, oppure no?
La risposta che emerge dalla sentenza del Tribunale di Padova è sì: il codice sorgente va consegnato, salvo che il contratto disponga espressamente il contrario.
Il punto decisivo della decisione non è l’esistenza di una clausola che promette il codice sorgente, ma il fatto che il contratto non dica nulla. Ed è proprio questo silenzio che il giudice interpreta in senso sfavorevole allo sviluppatore. Nel software realizzato su commissione, infatti, non conta solo ciò che le parti hanno concordato, ma la natura della prestazione promessa e pagata.
La sentenza n. 1149/2024 del 20 giugno 2024 muove da una premessa in diritto, oltre che in fatto: una volta qualificato il rapporto come appalto, il risultato dell’attività dello sviluppatore appartiene al committente.
E il risultato, quando si parla di software o piattaforme Web, non coincide con l’eseguibile che funziona oggi, ma con l’insieme delle istruzioni che ne consentono l’uso, la manutenzione e l’evoluzione nel tempo. In questo senso, il codice sorgente non è un dettaglio, ma l’oggetto, ossia la “forma tecnica” del bene acquistato.
Questo approccio non è isolato. Il Tribunale di Padova richiama espressamente la sentenza n. 96/2020 del Tribunale di Bologna, Sezione Imprese, già commentata dallo Studio Canella Camaiora nell’articolo “Codice sorgente: la software house è tenuta a consegnarlo al committente? – Canella Camaiora”. Anche in quel caso il giudice aveva affermato che il codice sorgente del software sviluppato su commissione appartenesse al committente.
Il filo che unisce Bologna 2020 e Padova 2024 è evidente, ma Padova prende posizione in modo ancora più netto. Chi paga per un software su misura acquista la disponibilità piena del prodotto, non una dipendenza tecnica permanente dal fornitore.
Il silenzio del contratto non crea una riserva implicita a favore dello sviluppatore; al contrario, conferma che nulla è stato sottratto alla regola generale dell’appalto.
La conseguenza pratica è quindi che l’atto del trattenere il codice sorgente – in assenza di una clausola espressa che dica il contrario – è un inadempimento, perché significa trattenere una parte essenziale della prestazione promessa. Non è una questione astratta di diritto d’autore, né di tutela della creatività del programmatore. È una questione di coerenza economica del contratto: il committente ha pagato per un bene che deve poter usare, manutenere e far evolvere senza dover dipendere stabilmente da chi lo ha realizzato.
In sintesi, nel software su commissione il codice sorgente segue il destino del software stesso. Se le parti vogliono spezzare questo legame, devono dirlo chiaramente nel contratto. In mancanza, la risposta alla domanda è affermativa: il codice sorgente va consegnato.
Per un inquadramento più ampio e sistematico del tema, si veda anche l’articolo dello Studio Canella Camaiora “Proprietà del software: il riparto dei diritti tra committenti e sviluppatori”, che ricostruisce in modo organico il rapporto tra diritto d’autore, contratti di sviluppo e software su commissione.
Il rifiuto di consegnare il codice è un inadempimento grave?
Nella sentenza n. 1149/2024 del 20 giugno 2024 il Tribunale di Padova non si limita a rilevare la mancata consegna del codice sorgente, ma spiega perché questa omissione incide in modo diretto sull’equilibrio del contratto e sul valore del software acquistato.
Il giudice muove da un dato concreto: senza il codice sorgente il committente è costretto a rivolgersi esclusivamente allo sviluppatore per qualsiasi modifica, implementazione o aggiornamento del programma. Non si tratta di attività eccezionali, ma di interventi fisiologici, necessari a evitare che un software diventi rapidamente obsoleto. In assenza del codice, però, solo chi lo detiene è in grado di intervenire.
È in questo passaggio che il Tribunale introduce un concetto centrale della motivazione: il “regime sostanziale di monopolio”. Trattenendo il codice sorgente, lo sviluppatore si pone in una posizione di controllo esclusivo che non risulta prevista dal contratto, ma che di fatto limita la libertà del committente. Quest’ultimo, pur avendo pagato il software, non può scegliere liberamente a chi affidarne l’evoluzione, né negoziare in modo paritario le condizioni economiche degli interventi successivi.
Proprio questa compressione della disponibilità del bene porta il Tribunale a qualificare l’inadempimento come di non scarsa importanza ai sensi degli artt. 1453 e 1455 c.c. La prestazione rimasta ineseguita – la consegna del codice sorgente – viene definita di valore primario nell’economia del contratto, perché incide direttamente sul diritto di proprietà acquisito dal committente a titolo originario, introducendo una limitazione non prevista dalle parti.
Un ulteriore passaggio della motivazione chiarisce la portata di questa valutazione. Una volta accertata la gravità dell’inadempimento legato al codice sorgente, il Tribunale ritiene superfluo stabilire se l’applicazione fosse o meno affetta dai vizi funzionali lamentati. In altri termini, anche a prescindere dal funzionamento del software, la sola mancata consegna del codice sorgente è sufficiente a giustificare la risoluzione del contratto.
Questo punto è rilevante anche sul piano pratico. Nei contenziosi IT, la difesa dello sviluppatore si fonda spesso sull’assunto che “il software funziona”. La sentenza di Padova chiarisce invece che, nel software su commissione, la funzionalità immediata non esaurisce la prestazione. Quando il committente non ha il controllo tecnico del bene che ha acquistato, l’inadempimento non è marginale, ma strutturale.
Questa lettura si colloca in un solco già tracciato dalla giurisprudenza. Il Tribunale di Bologna aveva infatti riconosciuto che l’indisponibilità del codice sorgente può determinare un danno organizzativo e disfunzionale per il sistema impresa (Tribunale di Bologna, Sez. Imprese, sentenza n. 96/2020), rendendo necessari interventi manuali o tecnici sostitutivi di funzioni che il software avrebbe potuto svolgere in automatico. In modo analogo, il Tribunale di Brescia – come ricostruito nell’articolo di Margherita Manca – ha valorizzato la disponibilità effettiva del software e del codice come elemento sostanziale del rapporto, guardando agli effetti concreti sull’autonomia e sull’organizzazione del committente, più che alle sole etichette formali del contratto.
Codice, dati e potere: perché il vero tema è la consapevolezza tecnologica
La vicenda decisa dal Tribunale di Padova con sentenza n. 1149/2024 del 20 giugno 2024 – rimasta ferma dopo l’estinzione dell’appello davanti alla Corte d’Appello di Venezia il 13 marzo 2025 – racconta una dinamica che va ben oltre il singolo contratto di sviluppo software. Racconta che, in ambito tecnologico, chi controlla il codice può esercitare un potere decisivo sull’altra parte, fino a mantenerla in una posizione di dipendenza di fatto.
Nel software, il controllo del codice non è mai neutro. Chi lo detiene decide se, quando e a quali condizioni il prodotto potrà essere modificato, aggiornato o reso interoperabile. Finché il rapporto regge, questo potere resta sullo sfondo. Quando il rapporto si incrina, diventa evidente: chi ha il codice può dettare le regole sino all’intervento del giudice. È questo il senso profondo dell’inadempimento individuato dal Tribunale di Padova, che parla apertamente di una dipendenza strutturale del committente dallo sviluppatore.
Codice, dati e potere sono oggi elementi strettamente intrecciati. La stessa logica attraversa il diritto digitale europeo più recente: i dati generati da dispositivi, piattaforme e software non possono più essere considerati una riserva opaca del fornitore quando sono essenziali per l’attività economica di chi li utilizza. Il codice sorgente, nel contenzioso sul software su commissione, svolge una funzione analoga: senza accesso, l’investimento resta incompleto, perché privo di autonomia e di capacità evolutiva.
Questa dinamica emerge con particolare forza quando le imprese integrano sistemi di intelligenza artificiale nei propri processi. L’adozione dell’IA non è giuridicamente neutra: chi utilizza, addestra o integra un sistema deve poter comprenderne il funzionamento, documentarlo e governarlo, anche ai fini della responsabilità, della conformità normativa e della gestione dei rischi. Senza controllo sugli asset tecnici – codice, dati, documentazione – l’impresa resta titolare degli obblighi, ma perde il controllo delle decisioni tecnologiche. È la stessa asimmetria che il giudice padovano individua nel rapporto tra committente e sviluppatore.
È qui che si inserisce un ulteriore livello di attenzione, già emerso nell’analisi sui diritti di decompilazione e sui “segnali di allarme” nei contratti software. Il potere tecnologico non si esercita solo trattenendo il codice sorgente, ma anche attraverso clausole contrattuali che vietano o sterilizzano ogni forma di accesso, analisi, interoperabilità o controllo alternativo. Divieti di decompilazione assoluti, assenza di obblighi di consegna, mancanza di regole sulla portabilità dei dati o sull’uscita dal contratto producono, sul piano sostanziale, lo stesso effetto del rifiuto di consegna del codice: una dipendenza tecnica non dichiarata, ma molto reale.
In questo contesto, il silenzio contrattuale diventa sempre più pericoloso. La sentenza di Padova lo dimostra con chiarezza: se il contratto non disciplina chi governa il codice e gli asset tecnologici, a decidere sarà il giudice, e la decisione terrà conto non delle etichette formali, ma dell’assetto di potere creato in concreto dal rapporto. Il diritto europeo dei dati, nel frattempo, sta uscendo da una fase di incertezza proprio per affrontare questo nodo: riequilibrare accesso, tutela del know-how e rapporti contrattuali in mercati sempre più digitalizzati (approfondisci: Il diritto europeo dei dati sta uscendo dalla sua “fase liminale”. Il Digital Omnibus – Canella Camaiora)
Il filo che unisce codice sorgente, dati, intelligenza artificiale e nuove regole europee è quindi uno solo: la tecnologia non vale per ciò che fa oggi, ma per chi ne controlla l’evoluzione. Ed è su questo terreno – molto più che sui bug o sulle prestazioni – che si gioca ormai il contenzioso digitale e la qualità della contrattualistica tecnologica del futuro.
© Canella Camaiora S.t.A. S.r.l. - Tutti i diritti riservati.
Data di pubblicazione: 21 Gennaio 2026
È 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.
Arlo Canella
Managing & founding partner, avvocato del Foro di Milano e cassazionista, responsabile formazione e ricerca indipendente dello Studio CC®.