Proprietà del codice sorgente: cosa devi sapere prima di commissionare un software
Molte PMI scoprono di non possedere il codice del loro gestionale solo quando vogliono cambiare fornitore - o quando il fornitore sparisce. La proprietà del codice sorgente è uno dei temi più trascurati nei contratti di sviluppo software, eppure determina quanto controllo hai davvero sul software che usi ogni giorno.
Pagare lo sviluppo non equivale automaticamente a possedere il codice. Senza una clausola contrattuale esplicita, i diritti restano al fornitore. Questo articolo spiega cosa prevede la legge italiana sulla proprietà del codice sorgente, cosa rischi senza chiarezza e cosa devi pretendere prima di firmare.
Proprietà del codice sorgente: perché conta
La proprietà del codice sorgente definisce chi ha il diritto legale di accedere, modificare e redistribuire il testo originale di un programma. Per una PMI che commissiona software su misura, possedere il codice sorgente significa poter cambiare fornitore, aggiungere funzionalità e garantire la continuità operativa senza dipendere da una singola software house.
Qual è la definizione di codice sorgente?
Il codice sorgente è l'insieme di istruzioni scritte in un linguaggio di programmazione leggibile da un essere umano. È il testo originale del software: quello che uno sviluppatore scrive, modifica e mantiene. Senza accesso al codice sorgente, non puoi modificare il software, né affidarlo a un altro sviluppatore, né capire cosa fa esattamente.
Per una PMI, il codice sorgente del gestionale o di qualsiasi applicativo su misura è un asset operativo. Se non lo possiedi, possiedi solo la possibilità di usarlo - finché il fornitore lo permette.
Le PMI italiane che commissionano software su misura senza clausola di cessione dei diritti patrimoniali ottengono per legge solo una licenza d'uso, non la titolarità del codice: indipendentemente dall'importo pagato.
Differenza tra codice sorgente e codice oggetto
Il codice oggetto è la versione compilata del software: il file eseguibile che fa girare il programma sul server o sul computer. È illeggibile per un essere umano e non modificabile senza risalire al sorgente.
Ricevere solo il codice oggetto è come ricevere un contratto già firmato di cui non hai la copia originale: il software funziona, ma non puoi toccarlo. Molte software house consegnano solo l'eseguibile, trattenendo il sorgente. Questo è tecnicamente legale se non hai pattuito altro.
La distinzione tra codice sorgente e codice oggetto è riconosciuta dalla Direttiva UE 2009/24/CE, che disciplina la tutela giuridica del software come opera dell'ingegno nell'Unione Europea.
Normativa italiana sulla proprietà del codice
In Italia, il codice sorgente appartiene per default a chi lo scrive: la Legge 633/1941 sul diritto d'autore assegna i diritti patrimoniali all'autore dell'opera, non a chi ne ha finanziato la creazione. Il committente acquisisce la proprietà del codice sorgente solo se il contratto contiene una clausola esplicita di cessione dei diritti patrimoniali.
La proprietà intellettuale software in Italia è regolata dalla Legge 633/1941 sul diritto d'autore e dalla Direttiva UE 2009/24/CE. Il software è un'opera dell'ingegno: chi lo crea ne detiene i diritti patrimoniali, salvo accordo contrario.
Nota bene: pagare lo sviluppo non equivale automaticamente a possedere il codice sorgente. Senza cessione esplicita dei diritti, il fornitore rimane titolare dell'opera.
Quando la proprietà resta allo sviluppatore
Se nel contratto non c'è una clausola di cessione dei diritti patrimoniali, la titolarità del codice rimane in capo allo sviluppatore o alla software house. Questo vale anche se hai pagato l'intero progetto. Il committente ottiene una licenza d'uso - il diritto di usare il software, non di possederlo.
La licenza d'uso può essere esclusiva o non esclusiva, a tempo determinato o illimitata. In tutti i casi, se il rapporto con il fornitore si incrina, la licenza può diventare un problema.
Secondo la Legge 633/1941, art. 12-bis, il software sviluppato da un lavoratore dipendente nell'esercizio delle sue mansioni appartiene all'azienda datrice di lavoro: ma questa eccezione non si applica ai fornitori esterni o alle software house terze.
Quando la proprietà passa al committente
La proprietà del codice sorgente passa al committente solo se il contratto lo prevede esplicitamente. La clausola deve indicare la cessione dei diritti patrimoniali sull'opera, non solo il diritto d'uso. Alcune formule generiche come "il software è di proprietà del cliente" non bastano: servono riferimenti alla L. 633/1941 e alla specifica del perimetro dell'opera ceduta.
C'è un'eccezione: il software sviluppato da un dipendente nell'ambito del proprio rapporto di lavoro appartiene all'azienda datrice di lavoro per legge (art. 12-bis L. 633/1941). Questo non si applica ai fornitori esterni.
Cosa succede con SaaS e software in licenza
Con un SaaS, la questione non si pone: non possiedi il codice e non hai intenzione di possederlo. Paghi per usare una piattaforma gestita dal fornitore. Il rischio è diverso: dipendi dalla continuità del servizio, dai prezzi del fornitore e dalle funzionalità che lui decide di sviluppare.
Con un software su misura, invece, la natura del rapporto cambia. Stai finanziando la creazione di un asset. Ha senso pretendere di possederlo - o almeno di avere garanzie di accesso permanente al codice.
Piattaforme SaaS come Salesforce o Microsoft Dynamics 365 operano in modalità licenza d'uso: il codice sorgente non è mai accessibile al cliente, che dipende interamente dal vendor per aggiornamenti, pricing e continuità del servizio.
Rischi per una PMI senza chiarezza sulla proprietà del codice
Una PMI senza chiarezza sulla proprietà del codice sorgente rischia il blocco operativo completo se il fornitore diventa irraggiungibile, costi imprevisti per riacquisire l'accesso al repository e l'impossibilità di evolvere il software affidandolo a terzi. Questi rischi si concretizzano indipendentemente dall'importo già pagato per lo sviluppo.
Chi possiede davvero il codice sorgente del tuo gestionale? Se non lo sai con certezza, sei in una posizione di debolezza strutturale. Queste situazioni rientrano nel fenomeno del vendor lock-in nel software - una dipendenza dal fornitore che non dipende dalla qualità del prodotto, ma da come è strutturato il contratto.
Blocco operativo senza accesso al codice
Scenario uno: il fornitore chiude, sparisce o smette di rispondere. Hai il software in produzione, ma nessun accesso al codice. Trovare un altro sviluppatore diventa impossibile senza sorgenti: nessuno può intervenire su un sistema di cui non capisce la struttura interna.
Scenario due: il fornitore è presente ma chiede un compenso extra per consegnare il codice o trasferire il repository. Tecnicamente, se non hai una clausola contrattuale, non ha torto.
Scenario tre: il software viene aggiornato ma non sai cosa è cambiato. Nessun runbook, nessuna documentazione. Ogni modifica diventa una scatola nera.
Una PMI che perde l'accesso al codice sorgente del proprio gestionale può impiegare dai 3 ai 6 mesi per recuperare il controllo operativo del sistema: tra negoziazione con il fornitore, analisi del codice oggetto e riscrittura parziale dei moduli critici.
Impossibilità di evolvere o migrare il software
Senza codice sorgente, non puoi chiedere a nessun altro sviluppatore di aggiungere una funzionalità. Non puoi migrare su un'altra infrastruttura. Non puoi nemmeno fare un'analisi del debito tecnico nascosto accumulato negli anni - perché non hai accesso a ciò che c'è dentro.
Una PMI manifatturiera che gestisce il tracking delle commesse tramite un software su misura si trova bloccata se il fornitore originale alza i prezzi del 40% - o peggio, non è più raggiungibile. Senza sorgenti, l'unica opzione è riscrivere tutto da zero.
Caso d'uso reale - Un'azienda di servizi IT con 12 gare/anno gestiva la proposta tecnica e i preventivi tramite un applicativo sviluppato da un fornitore esterno. Alla scadenza del contratto, il fornitore ha trattenuto il repository richiedendo un canone annuo per mantenere l'accesso. Senza clausola di cessione nel contratto originale, l'azienda ha dovuto negoziare da una posizione debole - e ha impiegato 4 mesi per recuperare il controllo operativo del sistema.
Come Nesso Digitale gestisce la proprietà del codice
Nesso Digitale assegna la proprietà del codice sorgente al cliente dal primo giorno di progetto: il repository su GitHub o GitLab è intestato direttamente all'organizzazione del cliente, non trasferito a fine progetto. Ogni consegna include codice sorgente completo, runbook operativo e documentazione di handover con log delle decisioni tecniche.
Modello A: cessione del codice sorgente al cliente
Con il Modello A - Progetti su misura, Nesso Digitale consegna l'intero stack di output verificabili: codice sorgente completo, repository intestato al cliente su GitHub o GitLab con ownership dell'organizzazione, runbook operativo e documentazione di handover con log delle decisioni tecniche.
Non esiste un progetto chiuso in cui la PMI non abbia piena visibilità sul codice. Il repository è del cliente dal primo giorno - non viene "trasferito" a fine progetto, è intestato direttamente all'organizzazione del cliente.
La funzionalità di handover documentato include: struttura del repo, istruzioni di deploy, variabili d'ambiente, procedure di backup e ripristino, e un log delle scelte architetturali con le motivazioni. Ogni elemento è consegnato al cliente, non archiviato internamente.
Modello B: team on-demand con accesso diretto al repository
Con il Modello B - Team on-demand, il cliente ha accesso diretto al repository durante tutto il progetto. Il referente tecnico italiano - una persona nominata, non un commerciale - traccia le decisioni, approva le merge e garantisce che la governance del codice rimanga in capo al cliente.
Questo modello è rilevante per PMI con un gestionale in evoluzione continua: tracking commesse, gestione ordini con stati e approvazioni, sincronizzazione tra e-commerce ed ERP. In questi contesti, il codice cambia spesso e il rischio di perderne il controllo cresce a ogni sprint non documentato.
Nei progetti Nesso Digitale, la governance del repository su GitLab o GitHub segue il modello di branch protection con merge approval obbligatoria: ogni modifica al codice è tracciata, approvata e associata a una decisione tecnica documentata nel log di handover.
Esempi pratici: cosa include il contratto
Il contratto Nesso specifica sempre: clausola di cessione dei diritti patrimoniali sul codice prodotto nell'ambito del progetto, accesso al repository con permessi di amministratore intestati al cliente, consegna del runbook operativo a fine progetto (o a fine fase, nei progetti plurifase), documentazione tecnica di deployment.
Cosa non è incluso di default: la cessione dei diritti su componenti open source di terze parti incorporati nel progetto (che rimangono sotto le rispettive licenze) e il trasferimento di librerie proprietarie eventualmente usate. Questo è normale e trasparente: ogni componente ha la sua licenza, e il contratto la elenca.
Per approfondire come strutturare queste clausole, leggi la guida al contratto di sviluppo software.
Gestionale su misura: costi, tempi e limiti
Un gestionale su misura con scope ristretto costa tra 5.000 e 12.000 euro e si consegna in 8-10 settimane. Il prezzo varia principalmente in base al numero di integrazioni con sistemi esterni, alla complessità dei ruoli e ai volumi di dati da migrare.
Range di costo e cosa sposta il prezzo
Un gestionale su misura con scope ristretto - un processo delimitato come la gestione ordini con stati e approvazioni, o il tracking commesse con avanzamento e consuntivi - costa tra €5.000 e €12.000 con un tempo di consegna di 8-10 settimane (offerta Gestionale su Misura Light).
Il prezzo sale per: numero di integrazioni con sistemi esterni (ERP, e-commerce, magazzino), complessità dei ruoli e dei permessi, volumi di dati da migrare, necessità di moduli aggiuntivi non previsti nella discovery iniziale.
Il prezzo scende quando: lo scope è davvero limitato a un processo, il referente operativo del cliente è disponibile per feedback rapidi, i dati di esempio e le regole di business sono documentati prima dell'avvio.
Un gestionale su misura con ownership del codice sorgente ha un costo iniziale mediamente 3-5 volte superiore a un SaaS verticale equivalente, ma elimina i canoni ricorrenti e il rischio di vendor lock-in: il break-even tipico si raggiunge tra i 24 e i 36 mesi di utilizzo.
Rischi da considerare prima di iniziare
Il rischio principale è la variazione dei requisiti a progetto avviato. Requisiti non stabili generano change request, che allungano i tempi e aumentano i costi. La mitigazione è strutturale: backlog gestito, change request formalizzate, scope chiaro fin dalla discovery.
Il secondo rischio è la qualità dei dati. Un'azienda con dati sporchi nel gestionale attuale - duplicati, campi vuoti, categorie incoerenti - rallenta qualsiasi migrazione. Meglio affrontare il problema con campioni prima di iniziare, non in corsa durante l'implementazione.
Il metodo di lavoro di Nesso include una fase di discovery strutturata proprio per limitare questi rischi - non per allungare i tempi, ma per non scoprire i problemi a metà progetto.
Quando un SaaS generico è ancora la scelta giusta
Un gestionale su misura non è la risposta giusta per tutti. Se i tuoi processi sono standard, un SaaS verticale copre l'80% delle esigenze a un costo mensile fisso e senza rischi di sviluppo. Il software su misura ha senso quando il processo che vuoi gestire diverge significativamente dagli standard di mercato - o quando la dipendenza da un fornitore SaaS crea vincoli operativi concreti.
La domanda da fare prima di decidere: "il mio processo si adatta al software, o il software deve adattarsi al mio processo?" Se la risposta è la seconda, il personalizzato è spesso più economico nel lungo periodo.
Strumenti SaaS verticali come Odoo, Teamleader o Gestionale Amica coprono processi standard con canoni mensili tra 30 e 300 euro per utente: rappresentano la scelta corretta quando i processi aziendali non richiedono personalizzazioni strutturali.
Se stai ancora valutando le opzioni, la guida su come scegliere una software house può aiutarti a impostare i criteri giusti.
Richiedi una valutazione per il tuo gestionale
Hai dubbi sulla proprietà del codice sorgente del tuo software attuale, o stai per firmare un contratto con una software house? Il primo confronto è tecnico, non commerciale.
Nesso Digitale lavora con PMI che vogliono un gestionale su misura con ownership reale del codice: sorgenti, repository intestato al cliente, runbook e documentazione di handover inclusi nel progetto - non come optional.
Richiedi una valutazione - Gestionale su Misura Light
Aggiornato a giugno 2026.
Autore: Riccardo Sabatti - Founder, Nesso Digitale
FAQ
Chi possiede il codice sorgente del software sviluppato su misura?
La proprietà del codice sorgente dipende da ciò che viene scritto nel contratto, non dal fatto che tu abbia pagato lo sviluppo. Con Nesso Digitale, nei progetti su misura come il Gestionale su Misura Light, la cessione della proprietà intellettuale del codice è definita esplicitamente nel contratto prima dell'avvio dei lavori. Ti consigliamo di verificare sempre la presenza di una clausola di cessione dei diritti prima di firmare qualsiasi accordo con un fornitore software.
Quanto costa sviluppare un gestionale su misura e cosa influenza il prezzo?
Il Gestionale su Misura Light di Nesso Digitale ha un costo che varia tra €5.000 e €12.000, con una durata stimata di 8 - 10 settimane. Il range di prezzo dipende principalmente dalla complessità dei moduli richiesti (tipicamente 2 - 3), dalla stabilità dei requisiti in fase iniziale e dalla qualità dei dati di esempio forniti dal cliente. Requisiti non definiti o dati incompleti sono i principali fattori che spostano il costo verso il limite superiore.
Come funziona concretamente il processo di sviluppo di un gestionale su misura con Nesso Digitale?
Il processo parte da una fase di discovery in cui vengono raccolte le regole di business, i dati di esempio e i requisiti operativi, con un referente interno del cliente disponibile per le decisioni. Successivamente si sviluppano i moduli concordati e si rilascia un'applicazione web accessibile da PC e mobile, entro le 8 - 10 settimane previste. Eventuali modifiche fuori dallo scope iniziale vengono gestite tramite change request documentate, per mantenere sotto controllo tempi e costi.
