Un contratto di sviluppo software deve stabilire nero su bianco tre cose: chi possiede il codice sorgente, come si misura la consegna e cosa succede quando qualcosa va storto. Le otto clausole da controllare prima di firmare riguardano proprietà del codice, licenze di terze parti, tempi e SLA, collaudo e accettazione, penali e recesso, manutenzione post go-live, riservatezza dei dati e subappalto. Se anche una sola manca o resta ambigua, in caso di disaccordo il rischio ricade quasi sempre sul cliente.
In questa guida esaminiamo le otto clausole una per una, con le domande esatte da fare al fornitore prima di mettere la firma. Le scriviamo dal lato di chi i contratti di sviluppo li prepara ogni mese: sappiamo quali formulazioni proteggono entrambe le parti e quali spostano tutto il rischio da una parte sola. L'obiettivo non è renderti diffidente, ma metterti in condizione di negoziare da pari a pari.
Nota onesta: questo articolo non è consulenza legale. È l'esperienza pratica di una software house che i contratti li firma e li onora. Prima di firmare il tuo, fallo rivedere da un avvocato, meglio se esperto di diritto informatico.
Contratto di sviluppo software: perché le clausole contano più del prezzo
La maggior parte delle trattative si concentra sul prezzo, ma quasi nessun contenzioso nasce dal prezzo. Nasce dalle domande rimaste senza risposta scritta: di chi è il codice, cosa significa "finito", chi paga se il progetto slitta di tre mesi. Un preventivo basso con un contratto vago finisce per costare più di un preventivo onesto con un contratto chiaro: su come valutare i numeri abbiamo scritto una guida ai costi del software su misura.
- Proprietà del codice e dei sorgenti
- Licenze di terze parti e componenti open source
- Tempi di consegna e SLA
- Criteri di collaudo e accettazione
- Penali e recesso
- Manutenzione e tariffe post go-live
- Riservatezza e trattamento dei dati
- Subappalto
Nessuna di queste clausole richiede un contratto di cinquanta pagine. Un buon contratto di sviluppo per una PMI sta in dieci-quindici pagine leggibili. Se ne ricevi cinquanta di legalese fitto, o tre piene di formule generiche, sono due segnali opposti dello stesso problema: qualcuno preferisce che tu non capisca esattamente cosa stai firmando.
Proprietà del codice sorgente: la clausola più importante
Pagare lo sviluppo non significa automaticamente possedere il software. Nel diritto d'autore, in assenza di una cessione esplicita, i diritti sul codice restano di regola in capo a chi lo ha scritto: potresti ritrovarti con una semplice licenza d'uso, magari limitata o legata al rapporto con quel fornitore. È la differenza tra comprare casa e pagarne l'affitto per sempre, con il proprietario che decide le condizioni.
La clausola corretta prevede la cessione dei diritti patrimoniali sul codice sviluppato per te, la consegna dei sorgenti e della documentazione tecnica, e l'accesso al repository già durante il progetto. Se il fornitore costruisce sopra una propria piattaforma proprietaria e non può cedere tutto, deve dichiararlo prima della firma: in quel caso valuta una licenza perpetua e irrevocabile sulle parti non cedibili e un accordo di escrow, cioè il deposito dei sorgenti presso un terzo indipendente.
- Cessione esplicita dei diritti patrimoniali sul codice sviluppato ad hoc
- Consegna di sorgenti, documentazione e credenziali di deploy a ogni rilascio
- Accesso in lettura al repository per tutta la durata del progetto
- Licenza perpetua o escrow per le componenti proprietarie del fornitore
Licenze di terze parti: il codice che non è di nessuno dei due
Nessun software moderno viene scritto da zero: dentro ci sono librerie open source, framework, a volte componenti commerciali a canone. Il contratto deve dichiarare quali componenti di terze parti verranno usati e con quali licenze, perché alcune impongono obblighi che ricadono su di te come titolare del software. Una clausola seria include anche una garanzia del fornitore sul fatto che l'uso di quei componenti non viola diritti di terzi.
| Tipo di licenza | Esempi tipici | Cosa implica per te |
|---|---|---|
| Permissiva | MIT, Apache 2.0, BSD | Uso commerciale libero, obblighi minimi di attribuzione |
| Copyleft | GPL, AGPL | In certi casi obbliga a rilasciare il codice derivato con la stessa licenza |
| Commerciale | Componenti e SDK a canone | Costi ricorrenti che sopravvivono alla fine del contratto di sviluppo |
La domanda da fare è una sola: quali componenti copyleft o a pagamento entreranno nel progetto? Se la risposta è vaga, chiedi un elenco scritto da allegare al contratto e fallo aggiornare a ogni rilascio importante.
SLA, tempi e collaudo: come si misura la consegna
Le date di consegna contano, ma da sole non bastano: servono milestone intermedie verificabili. Un contratto che prevede un'unica consegna finale a sei mesi ti lascia al buio per sei mesi, senza strumenti per accorgerti in tempo che qualcosa non va. Meglio rilasci parziali funzionanti ogni poche settimane, ciascuno con un criterio di verifica: è il modo in cui è costruito il nostro processo di sviluppo, e riduce drasticamente le sorprese di fine progetto.
Cosa devono precisare tempi e SLA
- Milestone con date o durate misurabili, non generici "tempi tecnici"
- Cosa succede se il ritardo dipende dal cliente (feedback, contenuti, accessi mancanti)
- SLA post rilascio: tempi di presa in carico e di risoluzione per gravità del problema
- Canali e orari del supporto, festivi inclusi se il software è critico
Collaudo e accettazione: chi decide che il lavoro è finito
Il collaudo è la verifica del software contro requisiti scritti, ed è la clausola che decide chi ha ragione nei disaccordi. Deve definire tre elementi: criteri di accettazione oggettivi (casi di test concordati, non impressioni), la durata del periodo di collaudo e cosa accade in caso di esito negativo, con tempi di correzione e un nuovo collaudo. Attenzione all'accettazione tacita: molti contratti prevedono che, senza contestazioni entro pochi giorni, il software si intenda accettato. È una prassi legittima, ma i giorni previsti devono bastarti davvero per provarlo con le persone che lo useranno.
Penali e recesso nel contratto di sviluppo software
Le penali quantificano in anticipo il costo di un inadempimento: tipicamente una percentuale del corrispettivo per ogni settimana di ritardo, con un tetto massimo. Il punto da controllare è la simmetria. Se il contratto prevede conseguenze severe per i tuoi ritardi nei pagamenti ma nulla per i ritardi di consegna del fornitore, non è un contratto equilibrato. Penali ragionevoli e bilaterali sono il segnale di un fornitore che si fida delle proprie stime.
Il recesso è la porta di uscita, e va letta prima di entrare. Verifica cosa succede se decidi di interrompere il progetto: quanto paghi del lavoro svolto, cosa ti viene consegnato — codice, documentazione, dati — e in quali tempi. Diffida delle formule in cui il recesso comporta la perdita di tutto quanto già pagato: il codice delle milestone saldate deve essere tuo, in forma utilizzabile da un altro fornitore.
Alcune formulazioni su penali e recesso sono veri campanelli d'allarme. Se nella bozza ne trovi anche solo una di queste, fermati e rinegozia prima di firmare:
- Penali solo a carico del cliente e mai del fornitore
- Nessun tetto massimo alle penali, o tetto irrisorio per il fornitore
- Recesso senza obbligo di consegna del lavoro già pagato
- Corrispettivo dovuto per intero anche in caso di interruzione anticipata
Manutenzione, riservatezza e subappalto: le clausole del dopo-firma
Le prime cinque clausole regolano il progetto; queste ultime regolano tutto ciò che viene dopo e attorno. Sono le più trascurate al momento della firma e le più citate quando i rapporti si incrinano.
Manutenzione e tariffe post go-live
Il giorno del rilascio il software inizia a vivere, non smette. Il contratto deve dire già ora quanto costa mantenerlo: cosa copre il canone (correzione bug, aggiornamenti di sicurezza, piccole evolutive), quali tariffe si applicano agli interventi extra e con quale preavviso possono cambiare. Se la manutenzione non è definita nel contratto di sviluppo, la negozierai dopo il go-live, quando cambiare fornitore è molto più difficile: è la forma più comune di lock-in. Qui trovi come impostiamo manutenzione e supporto nei nostri progetti.
Riservatezza e trattamento dei dati
La riservatezza deve essere bilaterale e sopravvivere alla fine del contratto: il fornitore vedrà processi, numeri e dati della tua azienda. Se tratta dati personali per tuo conto, serve anche la nomina a responsabile del trattamento prevista dal GDPR, con l'indicazione di dove risiedono i dati e di quali fornitori cloud vengono utilizzati. Non è burocrazia: verso clienti e autorità, la responsabilità di titolare resta la tua.
Subappalto: chi scrive davvero il codice
Ultima domanda, spesso la più rivelatrice. Alcune società vendono il progetto e lo girano interamente a terzi, a volte senza dirlo. Il contratto dovrebbe vietare il subappalto oppure subordinarlo alla tua approvazione scritta, mantenendo in ogni caso la responsabilità in capo al fornitore che firma. Hai il diritto di sapere chi lavora sul tuo software, da dove e con quali garanzie di riservatezza.
| Clausola | La domanda da fare prima di firmare |
|---|---|
| Manutenzione | Cosa copre il canone e quanto costa un intervento fuori canone? |
| Riservatezza e dati | L'accordo è bilaterale? Dove risiedono i dati e chi li tratta? |
| Subappalto | Chi scrive materialmente il codice e chi ne risponde? |
La checklist prima della firma
Prima di firmare, riprendi in mano la bozza e verificala contro gli otto punti qui sotto. Spunta solo ciò che è scritto nel contratto, non ciò che il commerciale ti ha promesso a voce: in caso di disaccordo conta soltanto il testo firmato.
Un fornitore serio non teme queste domande: le apprezza, perché un contratto chiaro protegge anche lui. È il criterio con cui impostiamo i progetti di sviluppo software su misura: cessione del codice, milestone verificabili e collaudo con criteri scritti sono la base di partenza, non una concessione da strappare. Se stai valutando un progetto e vuoi vedere come formuliamo questi punti, richiedi un preventivo: la bozza di contratto la leggi prima di impegnarti, non dopo.
Se pago lo sviluppo, il codice sorgente è automaticamente mio?
No. Senza una cessione esplicita dei diritti patrimoniali, il codice resta di regola di chi lo ha scritto e tu ottieni solo una licenza d'uso. Pretendi la clausola di cessione e la consegna dei sorgenti.
Cosa sono le penali in un contratto di sviluppo software?
Somme predeterminate dovute in caso di inadempimento, per esempio una percentuale per ogni settimana di ritardo, con un tetto massimo. Vanno previste in modo bilaterale: per i ritardi del fornitore e, specularmente, per quelli del cliente.
Quanto deve durare il periodo di collaudo?
Abbastanza da testare il software in condizioni reali con le persone che lo useranno davvero. L'ordine di grandezza va da qualche giorno per un modulo semplice a qualche settimana per un gestionale completo. Diffida dei collaudi lampo con accettazione tacita.
Serve un avvocato per rivedere un contratto di sviluppo software?
Per progetti di importo rilevante sì, meglio se esperto di diritto informatico. La revisione costa una frazione di un contenzioso, e questa guida non sostituisce una consulenza legale.