# Di chi è il codice sorgente del software che hai pagato

> Avete pagato trentamila euro per un gestionale. Secondo la legge italiana, senza una riga scritta nel contratto, i diritti restano a chi lo ha scritto.

**Enneci Agency** — Tenuta del Barone di Montemurlo di Nicolò Coppi. Via Volturno 11/A, 59100 Prato (PO), Italia.
Contatti: ciao@enneciagency.it · +39 379 2885434 (anche WhatsApp) · https://www.enneciagency.it
Zona servita: Prato e provincia, Firenze e Pistoia, e in tutta la Toscana.

_Aggiornata il 2026-09-27. Argomento: Contratti._

È la domanda che quasi nessuno fa prima di firmare, e che diventa urgente nel momento peggiore: quando si vuole cambiare fornitore, quando quello che c'era non risponde più, o quando l'azienda viene venduta e chi compra chiede cosa esattamente stia comprando. La risposta breve è che pagare lo sviluppo non basta.

## Cosa dice la legge, se il contratto tace

In Italia il software è protetto dal diritto d'autore (legge 633/1941, articolo 12-bis e seguenti). La conseguenza pratica: i diritti nascono in capo a chi il programma lo ha scritto. Il committente, senza una cessione scritta, ottiene il diritto di usare il risultato per lo scopo concordato — non di modificarlo, rivenderlo, o farlo proseguire da qualcun altro.

C'è un'eccezione che confonde spesso: se il programma lo scrive un vostro dipendente nell'esercizio delle sue mansioni, i diritti economici sono dell'azienda. Ma vale per i dipendenti, non per i fornitori esterni. Con un fornitore serve il contratto.

> **La frase che cambia tutto**
> Nel contratto deve esserci una clausola di **cessione dei diritti di utilizzazione economica** del software sviluppato su commessa, con la consegna del codice sorgente. Senza quelle parole, la fattura pagata non prova nulla sulla proprietà.

## Cosa vi serve davvero avere in mano

Il codice sorgente da solo non basta. Serve tutto ciò che permette a un altro tecnico di rimettere in piedi il sistema senza chiedere niente a nessuno.

- **Il codice sorgente**, con la sua storia — il registro delle modifiche, non una cartella zip. La storia dice perché una cosa è stata fatta in un certo modo.
- **Le istruzioni per farlo partire** su una macchina nuova. Se avviare il progetto richiede conoscenze che stanno solo nella testa di qualcuno, il codice è vostro ma inutilizzabile.
- **Le credenziali di tutto**: dominio, hosting, database, servizi esterni. Intestate alla vostra azienda, non al fornitore.
- **I dati, in un formato leggibile.** Un'esportazione completa che si possa aprire senza il programma che l'ha generata.
- **L'elenco delle componenti di terzi** usate e con quale licenza. Serve a sapere cosa è vostro davvero e cosa è in prestito.

Un progetto che abbiamo ripreso da un altro fornitore era esattamente il caso limite: il codice c'era, ma nessuno riusciva più ad avviarlo — le istruzioni erano nella testa di chi se n'era andato. Metà del lavoro è stata separare i servizi e scrivere come si accendono. Il risultato non è stato una funzione nuova: è stato che un tecnico qualsiasi, oggi, lo mette in piedi in cinque minuti. È quello che dovrebbe essere vero dal primo giorno.

## Le tre situazioni tipiche, e cosa comportano

| Situazione | Cosa potete fare | Cosa succede se il fornitore sparisce |
| --- | --- | --- |
| Codice ceduto, sorgenti in vostro possesso | Tutto: modificare, cambiare fornitore, proseguire da soli. | Niente di grave: un altro tecnico riprende da dove si era arrivati. |
| Licenza d'uso, sorgenti dal fornitore | Usare il programma. Le modifiche passano da lui. | Il software continua a funzionare finché regge, poi si è fermi. |
| Piattaforma del fornitore (canone) | Usare il servizio finché lo paghate. | Il servizio si spegne. Restano i dati, se sono esportabili. |

Nessuna delle tre è sbagliata in assoluto: la terza è del tutto ragionevole per una fatturazione elettronica, dove non avete alcun interesse a possedere il programma. Diventa un problema quando riguarda il processo su cui l'azienda guadagna, e quando nessuno ha spiegato in quale delle tre ci si trovava.

## Cosa chiedere prima di firmare

1. **"Al saldo, i diritti di utilizzazione economica del software sviluppato per noi sono ceduti alla nostra azienda?"** La risposta va nel contratto, non nella mail.
2. **"Il codice sorgente ci viene consegnato, e in che forma?"** Un accesso al registro delle modifiche, non un archivio spedito una volta sola.
3. **"Dominio, hosting e servizi a nome di chi?"** Vostro. Sempre. Anche se li gestisce il fornitore.
4. **"Quali componenti di terzi usate, e con quali licenze?"** Serve sapere se qualcosa vi obbliga a condizioni che non conoscete.
5. **"Se domani cambiamo fornitore, cosa dovete consegnarci?"** Metterlo per iscritto quando i rapporti sono buoni costa zero. Farlo dopo, quando sono finiti, è impossibile.

Un fornitore serio risponde a tutte e cinque senza irrigidirsi: sono domande normali, e chi lavora bene non ha motivo di temerle. L'imbarazzo davanti a queste domande è, di per sé, la risposta.

## Domande frequenti

### Se ho pagato, il software non è automaticamente mio?

No, e questa è la sorpresa più comune. In Italia il diritto d'autore sul software nasce in capo all'autore: pagare la prestazione dà il diritto di usare il risultato per lo scopo pattuito, non i diritti sull'opera. Servono una cessione scritta e la consegna dei sorgenti. È una formalità di due righe, ma senza quelle due righe la situazione giuridica è l'opposta di quella che quasi tutti danno per scontata.

### Cosa cambia se il software usa componenti open source?

Quasi ogni programma moderno ne usa, ed è normale: sono componenti di base che nessuno riscrive da zero. Quello che conta è la licenza. La maggior parte (MIT, Apache, BSD) non pone condizioni pratiche all'uso aziendale. Alcune, come la GPL, possono imporre obblighi se il software viene ridistribuito a terzi — cosa che per un gestionale interno di solito non avviene. L'elenco delle componenti e delle loro licenze va comunque consegnato con il resto.

### Il fornitore può riusare il codice fatto per noi con altri clienti?

Dipende da cosa avete firmato, e va chiarito. È ragionevole che un fornitore riutilizzi le sue librerie e i suoi strumenti generici: è il mestiere, e quel riuso è il motivo per cui il vostro progetto è costato meno. Non è ragionevole che rivenda la logica specifica del vostro processo a un concorrente. La distinzione fra le due cose si scrive nel contratto, e va scritta prima.

### Come faccio a verificare che i sorgenti che ho siano completi?

C'è una prova sola che vale: far provare a un tecnico esterno ad avviare il progetto su una macchina pulita, partendo solo da quello che avete. Se ci riesce seguendo le istruzioni scritte, la consegna è completa. Se deve telefonare a qualcuno, non lo è. Conviene farlo alla consegna, quando il fornitore è ancora disponibile a colmare le lacune.