Vai al contenuto
← Tutti gli articoli

Software su misura / Nota di lavoro

Chi possiede il codice sorgente di un software su misura?

Proprietà del codice sorgente, repository, account, dati e continuità: cosa chiarire prima di commissionare un software su misura.

7 min di letturaAggiornato il 29 ottobre 2026

Se stai commissionando un software su misura, alla domanda «il software è mio?» purtroppo non c'è una risposta sola. Puoi avere il diritto di usare l'applicazione e non ricevere comunque i sorgenti. Oppure puoi ricevere il codice, ma non gli account e le istruzioni che servono per pubblicarlo e mantenerlo.

Prima della firma, quindi, conviene tenere separate tre cose: i diritti sul codice, la possibilità concreta di far mantenere il prodotto e il controllo sui dati. Il preventivo e il contratto dovrebbero dire chi consegna cosa, con quali limiti e in quale momento.

«Avere il software» può voler dire tre cose diverse

Il codice sorgente è l'insieme dei file che uno sviluppatore può leggere e modificare. Il programma compilato o pubblicato, invece, è quello che le persone in azienda usano ogni giorno. Avere accesso all'applicazione, anche completo, non equivale alla consegna dei sorgenti.

Poi ci sono i diritti. La Direttiva 2009/24/CE sulla tutela giuridica dei programmi per elaboratore protegge il programma nella sua espressione e riserva al titolare determinati atti, come la riproduzione, la trasformazione e la distribuzione. La legge italiana sul diritto d'autore include i programmi tra le opere protette e disciplina i diritti di utilizzazione e alcune eccezioni specifiche.

Queste norme, da sole, non assegnano al cliente tutti i diritti sul codice. Bisogna guardare il contratto, il rapporto tra le parti, il lavoro di eventuali dipendenti o collaboratori e i componenti già esistenti. Nel testo contrattuale conviene distinguere:

  • il diritto di usare il software e per quali soggetti, sedi o società;
  • la consegna dei sorgenti e dei materiali necessari per studiarli e modificarli;
  • la cessione o la licenza dei diritti di utilizzazione economica, con il perimetro concordato;
  • il codice che il fornitore aveva già e le librerie o i servizi di terzi.

Una frase come «il cliente possiede il software» non basta per capire cosa succede se cambi fornitore. Le clausole falle controllare da un professionista legale: qui ti preparo le domande tecniche e contrattuali da fare, ma questo articolo non è un parere.

Prima della firma chiarisci che cosa viene ceduto e che cosa viene licenziato

Dentro un progetto ci può essere codice scritto apposta per la tua azienda e codice riutilizzabile che il fornitore usa in più lavori, oltre a librerie open source, componenti acquistati, un servizio per i pagamenti o un'API esterna. Non è detto che ogni pezzo possa essere ceduto allo stesso modo, e non sarebbe corretto prometterlo senza aver visto le licenze e gli accordi che lo regolano.

Per questo conviene chiedere un elenco dei componenti principali. Per il codice sviluppato per il progetto, fai indicare quali diritti ricevi, da quando, per quanto tempo e con quali limiti: puoi modificarlo? Puoi incaricare un altro sviluppatore? Puoi usarlo per più società del gruppo? Puoi creare una versione derivata? Le risposte devono restare leggibili anche dentro il contratto.

Per il codice preesistente chiedi invece quale licenza ricevi e cosa accade se il rapporto finisce. La stessa attenzione vale per font, immagini, template, pacchetti software e servizi che hanno condizioni proprie. Un software può funzionare benissimo ed essere comunque legato a una licenza o a un account che non controlli.

Anche sul repository serve una frase precisa. Dovrebbe essere chiaro se avrai un accesso amministrativo o soltanto una copia alla fine, se riceverai la cronologia e le versioni rilasciate, e chi potrà approvare o pubblicare le modifiche. Se il codice si trova nell'organizzazione del fornitore, stabilisci come trasferirlo e come recuperarlo in caso di interruzione del rapporto.

Cosa ti devono consegnare, oltre ai file

Per mantenere un software bisogna poterlo ricostruire, provare e pubblicare. Uno ZIP con i sorgenti e nessuna istruzione, a chi arriva dopo, può servire a poco, soprattutto quando il progetto dipende da servizi esterni o da una configurazione che conosce soltanto chi lo ha sviluppato.

Nella consegna controlla:

  • repository completo, con sorgenti, configurazioni non riservate, cronologia, versioni rilasciate e istruzioni per avviare il progetto;
  • documentazione essenziale su come è organizzato il progetto, configurazione, dipendenze, procedura per creare e pubblicare una versione e limiti conosciuti;
  • accessi intestati all'azienda per hosting, database, dominio, DNS, storage, email, pagamenti, API e monitoraggio;
  • procedura per backup e ripristino, con una prova che permetta di capire se il backup è davvero utilizzabile;
  • elenco di dipendenze e licenze, versioni supportate, test disponibili e attività manuali necessarie per pubblicare una nuova versione;
  • trasferimento sicuro delle credenziali, senza lasciarle dentro il codice o in documenti condivisi senza protezione.

A chi sono intestati gli account conta quanto a chi appartengono i file. Se dominio, cloud e database sono intestati al fornitore, cambiare sviluppatore può diventare una trattativa anche quando i diritti sul codice sono scritti bene. Se invece gli account sono dell'azienda e il fornitore ha accessi delegati, passare la mano è più semplice da organizzare.

Nello stesso momento va concordata anche la manutenzione, perché correggere un bug, aggiornare una dipendenza e aggiungere una funzione nuova sono lavori diversi, con responsabilità e costi diversi. Nella guida su quanto costa un software su misura trovi anche cosa considerare per la manutenzione dopo il rilascio.

I dati sono un discorso a parte

Il database contiene informazioni dell'azienda, dei clienti e del lavoro quotidiano. Il modello che organizza quelle informazioni fa parte del software; i record, i documenti caricati e lo storico sono un altro oggetto da considerare nel contratto e nel piano di uscita.

Prima di iniziare, stabilisci quali dati puoi esportare, in quale formato e con quali collegamenti. Un CSV può bastare per un elenco semplice, ma non descrive da solo relazioni tra clienti, contratti, allegati, stati e storico delle modifiche. Chiedi anche chi prepara l'esportazione, quanto tempo resta disponibile il vecchio ambiente e cosa succede ai backup dopo la chiusura del rapporto.

Ti torna utile anche se oggi non pensi di cambiare fornitore. In una migrazione dei dati verso un nuovo gestionale, sapere chi decide quali informazioni sono corrette e come si controlla il risultato evita di scoprire i problemi il giorno del passaggio. E tieni presente che i diritti sul codice, da soli, non ti garantiscono un export completo dei dati, mentre un export dei dati non ti dà il codice per far funzionare l'applicazione altrove: sono due cose da chiedere separatamente.

Le domande da mettere nel preventivo

Quando confronti due offerte, aggiungi una sezione su proprietà, accessi e continuità. Io tutto quello che consegno lo scrivo nella proposta prima di iniziare, ma qualunque offerta tu stia guardando, cerca le risposte a queste domande:

  1. Quali sorgenti e materiali verranno consegnati, e in quale fase?
  2. Quali diritti potrò esercitare sul codice sviluppato per il progetto?
  3. Quali parti restano del fornitore o dipendono da licenze di terzi?
  4. Chi controlla repository, dominio, hosting, database e account dei servizi esterni?
  5. Un altro sviluppatore può installare, testare e pubblicare il software usando la documentazione consegnata?
  6. Quali dati, allegati, relazioni e log posso esportare se il rapporto termina?
  7. Come vengono gestiti il passaggio di consegna, i backup, le credenziali e l'assistenza?
  8. Che cosa è compreso nel prezzo e che cosa diventa manutenzione o sviluppo separato?

Altri criteri per confrontare i preventivi li trovi nella guida su quanto costa un software personalizzato: analisi, dati, integrazioni e lavoro dopo la pubblicazione contano anche quando non compaiono nella prima riga dell'offerta.

Prendi il gestionale personalizzato che ho sviluppato per un'azienda con venti negozi: codice, dati, contratti e attività fanno parte dello stesso flusso di lavoro. Se un domani dovesse occuparsene un'altra persona, non le basterebbe ricevere i file, le servirebbero accessi funzionanti e istruzioni che si possono seguire davvero.

Se stai raccogliendo preventivi, porta questa lista al confronto con chi svilupperà il prodotto. Come lavoro io su analisi, prototipo, sviluppo e consegna lo trovi nella pagina sui software, CRM e gestionali su misura. Le clausole sui diritti e sui dati, invece, vanno comunque adattate al tuo caso e verificate con il professionista che ti assiste.