Proprietà intellettuale del codice sorgente: di chi è il software che commissioni

Chi paga lo sviluppo di un gestionale dà quasi sempre per scontato che il software sia suo. Poi, il giorno in cui vuole cambiare fornitore o far modificare il programma da un altro, scopre che il contratto non dice niente, o dice il contrario.

Questa guida non è un parere legale: il contratto va scritto o riletto con un avvocato. Serve ad arrivarci con le domande giuste, prima di commissionare un gestionale su misura o per rileggere il contratto di quello che usi già.

Di chi è il codice sorgente di un software commissionato

Dipende dal contratto, e se il contratto tace la risposta non è scontata. La legge sul diritto d'autore protegge i programmi per elaboratore come opere letterarie (art. 1), "in qualsiasi forma espressi" (art. 2, n. 8), e fa nascere il diritto dalla sola creazione dell'opera (art. 6). Non serve registrare nulla.

Il sorgente è il testo scritto dai programmatori, l'unico che un altro programmatore può leggere e modificare. Spesso tu ricevi altro: una versione compilata e illeggibile, oppure un servizio che gira sui server del fornitore.

Per chi commissiona il software a un'altra azienda o a un libero professionista non c'è una norma equivalente all'art. 12-bis. Un orientamento diffuso tra i giudici riconosce al committente i diritti economici sul software fatto apposta per lui.

Richiamandolo, nel 2016 il Tribunale di Bologna ha ordinato a un libero professionista di restituire il sorgente alla società che gli aveva commissionato il programma (il caso raccontato da Brocardi). Nel 2025 il Tribunale di Milano ha invece dato ragione allo sviluppatore su una libreria che usava anche per altri programmi (il commento dello studio Canella Camaiora).

In pratica, senza una clausola né chi paga né chi scrive può dare per scontato di avere i diritti di riprodurre, modificare e distribuire il programma (art. 64-bis). Scrivere la cessione prima costa molto meno che discuterne davanti a un giudice.

Cosa puoi fare anche senza cessione

Chi ha acquistato legittimamente un programma ha comunque alcune facoltà (art. 64-ter):

• usarlo secondo la sua destinazione e correggerne gli errori, salvo patto contrario;
• farne una copia di riserva, se serve per l'uso;
• studiarne il funzionamento.

Le ultime due non si possono togliere per contratto. Nessuna comprende però il diritto di avere il sorgente.

Idee e processi non sono codice

La legge esclude dalla tutela le idee e i principi alla base di un programma. Il modo in cui gestisci le commesse, le regole di calcolo e i controlli che hai spiegato al fornitore: un altro programmatore può riscriverli da zero, senza copiare il codice, e il diritto d'autore non lo impedisce.

Costa, ma si può. I dati che hai inserito sono un'altra questione, trattata più sotto.

Licenza d'uso o cessione dei diritti

Un contratto di sviluppo ti dà una licenza d'uso oppure ti cede i diritti. Con la licenza usi il programma alle condizioni scritte e il fornitore resta titolare.

Con la cessione del codice sorgente, cioè dei diritti su di esso, diventi titolare dei diritti economici che ti vengono ceduti; la paternità dell'opera resta all'autore, perché i diritti morali sono inalienabili (art. 22).

La cessione totale non è sempre la scelta giusta: se il software è un prodotto che il fornitore vende a molti clienti, non ha senso pretenderla. Se il programma è costruito sul tuo processo, conviene almeno una licenza perpetua con il diritto di modifica e la consegna del sorgente.

Anche il prezzo cambia, perché con l'esclusiva il fornitore rinuncia a riusare il lavoro; sui costi c'è la guida su quanto costa un gestionale su misura.

Codice del progetto, componenti del fornitore e librerie

Nello stesso programma convivono tipi di codice con regole diverse:

• Il codice scritto apposta per il tuo progetto, che è quello che si può cedere.
• I componenti che il fornitore riusa in tutti i progetti (accessi, permessi, stampe), che di solito restano suoi e ti vengono dati in licenza.
• Le librerie open source, ciascuna con la sua licenza (MIT, Apache, GPL e altre), che nessuno può cederti.

AAllegato B · componenti del softwareContratto di sviluppo

N.	Componente	Origine	Regime
B.1	Commesse e magazzino	Scritto per il progetto	Ceduto
B.2	Preventivi e listini	Scritto per il progetto	Ceduto
B.3	Accessi, permessi, stampe	Componenti del fornitore	In licenza
B.4	Librerie MIT e Apache	Open source, 38 pacchetti	Di terzi
B.5	Libreria GPL per i PDF	Open source	Di terzi

Elenco aggiornato a ogni rilascioDati di esempio

Una clausola come "tutto il software diventa del cliente" suona bene ma di solito non si può rispettare alla lettera. Meglio un elenco onesto di cosa si cede, cosa resta in licenza e quali librerie di terzi ci sono dentro.

Cosa scrivere nel contratto di sviluppo software su commissione

Il contratto deve dire chi può fare cosa con il codice, cosa ti viene consegnato e come si esce. Le clausole da controllare, con o senza cessione:

• quali diritti ricevi (uso, riproduzione, modifica, distribuzione), se in esclusiva, per quale territorio e per quanto tempo;
• quando ricevi il sorgente (a ogni rilascio, alla fine, al saldo) e in quale forma: un repository con la storia delle modifiche, non un archivio compresso;
• l'elenco dei componenti preesistenti e delle librerie di terzi, con le loro licenze;
• se il fornitore si avvale di collaboratori esterni, la conferma che ha acquisito anche i loro diritti, perché l'art. 12-bis parla solo di dipendenti;
• in quale formato puoi esportare i dati, durante il contratto e alla fine;
• il contratto sul trattamento dei dati personali previsto dall'art. 28 del GDPR, che alla fine del servizio obbliga il fornitore a cancellare o restituirti i dati personali, a tua scelta;
• le condizioni di uscita: preavviso, assistenza al passaggio a un altro fornitore, tempi e costi.

Software escrow: cos'è e quando serve

Il software escrow è il deposito del codice sorgente presso un terzo indipendente, che lo consegna al cliente solo se si verificano eventi scritti nel contratto: il fornitore chiude, finisce in liquidazione giudiziale (il vecchio fallimento) o smette di dare assistenza.

Serve quando il fornitore non consegna il sorgente, di solito perché il software è un suo prodotto, ma tu non puoi permetterti di restarne senza.

Perché funzioni, il deposito va aggiornato a ogni rilascio, deve contenere le istruzioni di installazione e qualcuno deve controllare che si avvii davvero. Un archivio vecchio di due anni e senza istruzioni vale poco. Per un software costruito su misura c'è quasi sempre una strada più semplice: l'accesso al repository fin dall'inizio.

Cosa succede se la software house chiude o fallisce

Dipende da dove gira il software e da cosa hai in mano:

• se il programma è sui tuoi server e hai il sorgente con il diritto di modificarlo, un altro fornitore può prenderlo in carico e seguirne la manutenzione;
• se hai solo il programma installato, continua a funzionare finché non serve una modifica;
• se è un servizio in cloud del fornitore il rischio è immediato: quando il server si spegne, il software non c'è più.

E i diritti che non ti sono stati ceduti restano tra i beni della società: recuperarli dopo è una trattativa, non una formalità. Da avere prima, non dopo: un'esportazione recente dei dati, dominio e account intestati alla tua azienda, il sorgente e la documentazione per rimettere tutto in piedi.

Nel software SaaS, di chi sono codice e dati

Codice e dati seguono regole diverse. Per il codice vale il contratto: nei servizi in cloud venduti a molti clienti resta quasi sempre al fornitore.

Per i dati la legge aiuta: oltre al GDPR c'è il Data Act (Regolamento UE 2023/2854), applicabile dal 12 settembre 2025. Obbliga i fornitori di servizi cloud a scrivere nel contratto come si passa a un altro fornitore, con un periodo di transizione che di norma non supera i 30 giorni (art. 25), e dal 12 gennaio 2027 vieta le tariffe per il passaggio (art. 29).

Due limiti, però. Il Data Act riguarda i dati, non il codice: tra i "dati esportabili" non rientra ciò che è protetto dalla proprietà intellettuale del fornitore (art. 2). E per i servizi costruiti in gran parte per un singolo cliente, e non venduti a catalogo su larga scala, alcune regole non si applicano, tra cui lo stop alle tariffe di passaggio (art. 31).

Se il tuo gestionale in cloud rientri nel regolamento è una domanda per il legale; le condizioni di uscita conviene comunque scriverle nel contratto.

Le condizioni di uscita sono scritte nel contratto dall'inizio. Come si paga il software lo decidiamo insieme: a corpo, a canone o con una formula mista, come spiegato in formule e costi. Qualunque fornitore tu scelga, compresi noi, chiedi di vedere per iscritto cosa succede a dati e codice il giorno in cui smetti di pagare.

Cosa farsi consegnare in concreto, e come verificarlo

Una clausola sulla proprietà senza consegna è un diritto sulla carta. Servono cose precise, da ricevere a ogni rilascio importante e non solo il giorno in cui ci si separa.

La verifica più utile costa poco: chiedere a un programmatore che non ha mai visto il progetto di installarlo da zero su un ambiente di prova, seguendo solo la documentazione consegnata.

Se ci riesce, il passaggio a un altro fornitore è possibile. Se dopo un'ora chiede dove sia una password, hai trovato il problema prima che diventasse urgente.

Come si evita il vendor lock-in

Il vendor lock-in è la situazione in cui cambiare fornitore costa così tanto da non essere più una scelta reale. Non nasce solo dal codice:

• dati in un formato che legge solo il programma del fornitore;
• dominio e server intestati a lui;
• tecnologie poco diffuse;
• un progetto che sta tutto nella testa di una persona;
• un contratto senza clausola di uscita.

Un po' di dipendenza c'è sempre: anche con tutto in mano, chi subentra deve studiare il progetto. L'obiettivo è che il cambio sia possibile e che il suo costo sia prevedibile. Sono domande da fare prima di parlare di prezzo: le trovi nella guida su come scegliere una software house.