Proprietà del codice sorgente di un software commissionato: di chi è e cosa scrivere nel contratto
Per un software fatto da un fornitore esterno, la legge italiana non dice in modo univoco che i diritti passano a chi paga: lo deve dire il contratto. Servono due cose distinte, la cessione dei diritti di sfruttamento economico e la consegna effettiva del codice sorgente.
Cosa dice la legge
Il software in Italia è protetto dal diritto d’autore: la legge 633/1941 lo elenca fra le opere tutelate (art. 2, n. 8) e gli articoli 64-bis e seguenti fissano i diritti esclusivi su riproduzione, modifica e distribuzione. Il diritto nasce in capo a chi scrive il programma.
Per il dipendente la regola è chiara: l’art. 12-bis attribuisce al datore di lavoro i diritti di sfruttamento economico del programma creato nelle sue mansioni, salvo patto contrario. Per il software commissionato a una società esterna o a un freelance non esiste una norma altrettanto netta. Una parte della dottrina applica la stessa logica per analogia, altri sostengono che senza un patto scritto i diritti restino a chi ha sviluppato. Pagare la fattura non basta a chiudere la questione.
Il punto pratico è uno: un contratto che non ne parla lascia spazio a una lite, e la lite arriva di solito nel momento peggiore, quando volete cambiare fornitore. Questa pagina spiega cosa guardare; non sostituisce il parere di un avvocato sul vostro contratto.
Diritti e file sono due cose diverse
Potete essere titolari dei diritti e non avere il codice, o avere il codice e non poterlo usare. Il primo caso si scopre tardi: il contratto dice che il software è vostro, ma i sorgenti stanno sul computer o sul repository privato del fornitore. Quando il rapporto finisce, avete un diritto da far valere e nessun file da dare al nuovo fornitore.
Il secondo caso capita con i prodotti del fornitore: ricevete i sorgenti di un modulo, ma il modulo gira sopra un framework proprietario che resta suo e che vi è dato in licenza. Senza quella licenza il codice che avete non si compila.
Un software commissionato contiene di solito tre strati: il codice scritto apposta per voi, componenti che il fornitore aveva già e riusa in tutti i progetti, librerie open source con le loro licenze. Il contratto dovrebbe trattarli uno per uno.
Le sei clausole da controllare nel contratto
Cessione dei diritti sul codice scritto per voi
Che cosa passa (modifica, riproduzione, distribuzione, rivendita), da quando (alla firma, al pagamento di ogni rata, al saldo) e senza limiti di territorio o di durata.
Licenza sui componenti preesistenti
Per le parti che il fornitore già possedeva: una licenza perpetua, non revocabile, che vi permetta di far modificare il software a terzi. Senza la parola «terzi», la licenza vale solo finché lavorate con lui.
Consegna del sorgente
Dove sta il codice durante il progetto (meglio un repository intestato a voi, a cui il fornitore accede), con quale frequenza viene consegnato e in che forma: storico delle modifiche, istruzioni di compilazione, script di installazione.
Elenco delle licenze open source
Un elenco delle librerie usate e delle loro licenze, aggiornato a ogni rilascio. Conta di più se vendete il software o lo installate sulle macchine che consegnate ai clienti: alcune licenze, come GPL e AGPL, impongono di pubblicare il codice derivato.
Account, domini e servizi cloud
A nome di chi sono il dominio, l’account del cloud, le chiavi delle API a pagamento, l’account sugli store delle app. Se sono intestati al fornitore, il software è vostro ma gira a casa sua.
Documentazione e passaggio di consegne
Cosa vi consegna a fine progetto e cosa fa se decidete di cambiare fornitore: un affiancamento di qualche giorno al nuovo team, a una tariffa già scritta.
Tre contratti, tre situazioni alla fine del rapporto
Lo stesso gestionale di commesse, con tre contratti diversi, il giorno in cui decidete di affidarlo a un altro fornitore.
| Cosa dice il contratto | Il nuovo fornitore può lavorarci? | Potete rivenderlo o darlo a una consociata? | Cosa rischiate |
|---|---|---|---|
| Cessione dei diritti, repository a vostro nome, licenza perpetua sui componenti preesistenti | Sì, dal giorno dopo | Sì, nei limiti delle licenze open source | Poco: al massimo qualche settimana perché il nuovo team impari il codice |
| Licenza d’uso del software, sorgenti al fornitore | No, potete solo usarlo così com’è | No | Ogni modifica passa dal fornitore originale, al prezzo che decide lui |
| Nulla sui diritti, sorgenti mai consegnati | Solo dopo un accordo o una causa | Incerto | Mesi di stallo, e intanto il software va avanti senza manutenzione |
Esempio costruito per mostrare le differenze; il risultato di una lite reale dipende dal contratto e dal giudice.
Errori comuni
- Ricevere a fine progetto un file .zip una volta sola, invece di avere accesso al repository durante il lavoro. Lo zip è già vecchio al primo intervento successivo.
- Credere che il pagamento integrale trasferisca i diritti. Con un freelance o con una società esterna serve un patto scritto.
- Intestare il dominio o l’account cloud al fornitore «per comodità». Il giorno del cambio diventa la leva più forte della trattativa.
- Non chiedere quali parti sono preesistenti. Se un fornitore costruisce tutti i gestionali sullo stesso motore, il motore resterà suo, ed è giusto: va solo scritto come potete usarlo.
- Integrare senza saperlo una libreria GPL nel software di una macchina che vendete. Alla prima richiesta di un cliente dovete consegnare il codice derivato, oppure riscrivere quella parte.
- Dimenticare i dati. Oltre al codice, il contratto deve dire in che formato vi vengono restituiti i dati del database se il servizio si interrompe.
Domande frequenti
Parliamone in 30 minuti
Raccontateci il processo e cosa non funziona: vi diciamo se e come lo risolveremmo, con tempi e costi indicativi.
Matteo Budriesi
CEO e co-founder di Webion, la software house di Modena che sviluppa software su misura e agenti AI per le aziende.
Aggiornato il 30/10/2026