Se il contratto non lo dice, a chi appartiene il codice sorgente?

Se ho pagato lo sviluppo del software, il codice è mio?

Il pagamento dello sviluppo non basta, da solo, a risolvere la proprietà del codice sorgente. È però un elemento importante, soprattutto quando il software è stato realizzato su misura per il committente e non concesso come prodotto standard già esistente.

Se l’impresa commissiona un programma costruito sulle proprie esigenze, il rapporto può essere ricondotto allo schema dell’appalto o, comunque, a un incarico di sviluppo personalizzato. In questa prospettiva, il committente non paga solo l’accesso a uno strumento. Paga la realizzazione di un’opera digitale destinata alla propria organizzazione.

È su questo terreno che alcune decisioni hanno valorizzato il diritto del cliente a ottenere il codice sorgente, quando i sorgenti sono necessari per usare, mantenere o far evolvere il software commissionato. Il rifiuto della software house può diventare grave se priva il committente del controllo effettivo sul programma (Su questo punto, si veda anche il nostro commento ad Appello Venezia, 13 marzo 2025, dedicato alla vicenda in cui il Tribunale di Padova aveva ricondotto il rapporto allo schema dell’appalto e ritenuto dovuta la consegna del codice sorgente, salvo patto contrario).

La conclusione, però, non va forzata. Dire che il software è stato pagato dal cliente non significa dire che ogni riga di codice gli appartenga. Bisogna capire che cosa è stato sviluppato per il committente e che cosa, invece, apparteneva già alla software house.

La software house può trattenere librerie, moduli e framework?

Sì, se si tratta di componenti preesistenti e non cedute al committente. Il software consegnato al cliente può essere sviluppato su misura, ma contenere parti che la software house aveva già realizzato prima dell’incarico: librerie, moduli, framework, template, strumenti interni o componenti riutilizzabili.

Questa distinzione è decisiva. Il committente può avere interesse a disporre del software necessario alla propria attività. La software house, però, può avere un interesse legittimo a conservare il proprio patrimonio tecnico, cioè quelle soluzioni che utilizza in più progetti e che costituiscono parte del suo know-how.

In un caso recente, il Tribunale di Milano ha valorizzato proprio questo dato: la libreria controversa era solo “una delle librerie” utilizzate dal programma per specifiche funzioni ed era impiegata “anche per altri programmi software” (Trib. Milano, Sez. XIV civile, Sezione specializzata in materia di impresa “A”, 22 settembre 2025, n. 7036, R.G. n. 27310/2019).

Per questo la proprietà del codice sorgente non va trattata come un blocco unico. Occorre distinguere il codice sviluppato specificamente per il cliente dal codice preesistente dello sviluppatore. Sul primo, il committente può rivendicare diritti più forti. Sul secondo, di regola, potrà avere solo una licenza d’uso, nei limiti necessari al funzionamento del software commissionato.

Il rischio nasce quando il contratto non separa questi piani. Se non si chiarisce che cosa viene ceduto, che cosa viene concesso in licenza e che cosa resta della software house, la consegna del codice sorgente può trasformarsi in una contestazione più ampia: non più solo sull’uso del software, ma sulla titolarità del know-how tecnico incorporato nel progetto.

Il diritto d’autore protegge il codice o le funzionalità del software?

Il diritto d’autore protegge la forma espressiva del software, non l’idea o la funzione in sé. Questo punto è rilevante nei rapporti tra committente e software house: il cliente può avere interesse a ottenere un programma che svolga determinate funzioni, ma tale interesse non coincide automaticamente con l’acquisto di ogni diritto sul codice che le realizza.

La Corte di giustizia dell’Unione europea lo ha chiarito nella sentenza SAS Institute, osservando che “ammettere infatti che una funzionalità di un programma per elaboratore possa essere tutelata in quanto tale equivarrebbe a offrire la possibilità di monopolizzare le idee, a detrimento del progresso tecnico e dello sviluppo industriale” (CGUE, 2 maggio 2012, causa C-406/10, SAS Institute Inc. c. World Programming Ltd).

Il principio evita un effetto distorsivo: trasformare la tutela del software in un monopolio sulle idee tecniche o sulle funzionalità. Due programmi possono quindi svolgere attività simili senza che vi sia, solo per questo, una violazione del diritto d’autore. Diverso è il caso in cui venga riprodotta la forma espressiva del programma, cioè il codice o una parte originale della sua struttura.

Per questo, nei contratti di sviluppo software, la domanda non è soltanto se il committente abbia pagato per una certa funzione. La domanda più precisa è se abbia acquisito diritti sul codice sorgente che realizza quella funzione, e con quali limiti. Anche qui, il contratto resta decisivo.

Come si dovrebbe disciplinare il codice sorgente nel contratto?

La clausola sul codice sorgente non dovrebbe limitarsi a dire se il codice viene consegnato. Dovrebbe chiarire quali diritti il committente acquista sul software, quali componenti restano nella disponibilità della software house e quali facoltà operative saranno possibili dopo la consegna.

La distinzione principale riguarda il codice sviluppato per il cliente. Le parti devono stabilire se i diritti patrimoniali vengono ceduti, concessi in licenza esclusiva o concessi in licenza non esclusiva. La differenza incide sulla possibilità di modificare il software, affidarne la manutenzione a terzi, riutilizzarlo in altri contesti o impedirne il riuso da parte dello sviluppatore.

La stessa attenzione serve per il codice non sviluppato ad hoc. Librerie, framework, moduli preesistenti, componenti open source e software di terzi possono essere necessari al funzionamento del programma, ma non per questo sono automaticamente trasferiti al committente. Nei progetti Agile, questa distinzione diventa ancora più delicata, perché il software nasce per iterazioni successive, con modifiche, sprint e rilasci intermedi (v. il nostro precedente articolo “Contratti software e sviluppo Agile: criticità legali e proprietà del codice”).

In alcuni casi, l’equilibrio non passa dalla consegna immediata di tutti i sorgenti. Può passare da una licenza d’uso ampia, da obblighi documentali, dall’accesso regolato ai repository, da clausole sulla manutenzione evolutiva o da un escrow del codice sorgente. La soluzione dipende dal tipo di software, dal grado di dipendenza dal fornitore e dal valore strategico del sistema per l’impresa.

Il contratto, quindi, non serve solo a stabilire chi “possiede” il codice. Serve a decidere chi potrà governare il software quando il rapporto tra committente e software house cambierà.