Dietro ogni app, piattaforma SaaS o integrazione su misura c’è un rapporto contrattuale tra chi commissiona e chi sviluppa. Molti di questi rapporti nascono con un preventivo e qualche email, o con un modello generico copiato dalla rete.

Quando arrivano un bug grave, un ritardo o una lite su chi possiede il codice, le parti scoprono che la legge qualche risposta la dà, ma non sempre quella che si aspettavano. Il codice scritto da un freelance non passa automaticamente al cliente che lo paga. Quello scritto da un dipendente, invece, sì. E il codice generato con l’intelligenza artificiale potrebbe non essere protetto affatto.

Un buon contratto di sviluppo software stabilisce chi ha i diritti sul codice, cosa succede con i malfunzionamenti, come si gestiscono le modifiche, chi risponde dei dati e quali licenze si applicano. Le parti sanno in anticipo come andrà a finire, invece di scoprirlo in tribunale.

1. Le parti e il tipo di contratto

1.1 Chi c’è intorno al progetto

Nel progetto intervengono di solito tre figure.

• Committente – una startup, un’impresa tech o un’azienda tradizionale che si digitalizza.
• Fornitore – uno sviluppatore freelance, un’agenzia o una software house.
• Terzi – designer, fornitori cloud, integratori di API, eventuali subappaltatori.

Il team interno è un caso diverso. Il dipendente che sviluppa nell’esecuzione delle sue mansioni non è un fornitore, e i diritti sul codice spettano all’azienda (capitolo 3.1).

1.2 Appalto o contratto d’opera

La qualificazione del contratto cambia le regole che si applicano in silenzio. Con un’agenzia o una software house organizzata come impresa di solito si ha un appalto (art. 1655 del Codice civile). Con un freelance che lavora in prevalenza da solo si ha più spesso un contratto d’opera (art. 2222).

Dalla qualificazione dipendono i termini per contestare i difetti, il recesso e il subappalto. Nell’appalto, per esempio, il fornitore non può subappaltare senza l’autorizzazione del committente (art. 1656).

1.3 Dove nascono i problemi

Le liti derivano quasi sempre da obiettivi e limiti poco chiari.

• Cosa si consegna – il cliente si aspetta una piattaforma completa, lo sviluppatore consegna solo il backend.
• Tempi e milestone – senza date nascono tensioni su scadenze e approvazioni.
• Modifiche in corso d’opera – ogni variazione diventa uno scontro su costi e tempi.
• Cos’è un bug – il cliente chiama “errore” ciò che per il fornitore è una funzionalità.

2. Le clausole essenziali

2.1 Attività e deliverable

Il contratto descrive quali funzionalità si realizzano, su quali tecnologie e con quale risultato finale: codice consegnato, accesso al repository, ambiente di staging, documentazione tecnica. Meglio ancora se si allegano specifiche funzionali firmate dalle parti.

2.2 Diritti sul codice

Il contratto deve dire se i diritti di sfruttamento economico vengono ceduti, se si concede solo una licenza d’uso, e se il fornitore può riusare il codice per altri clienti. Nello sviluppo su misura la prassi è la cessione completa, ma va pattuita espressamente (capitolo 3).

2.3 Codice open source o preesistente

Se il software integra componenti open source o moduli già sviluppati dal fornitore, va chiarito quali parti sono nuove, quali sono soggette a licenze di terzi (MIT, GPL e simili) e cosa il cliente può modificare e distribuire.

2.4 Bug, garanzia e manutenzione

Molti contratti prevedono un periodo di assistenza gratuita dopo la consegna, per esempio 30 o 60 giorni. Quell’assistenza si aggiunge a una garanzia che la legge prevede già.

• Nell’appalto – il committente deve denunciare i difetti entro 60 giorni dalla scoperta, e l’azione si prescrive in due anni dalla consegna (art. 1667 del Codice civile). Può chiedere l’eliminazione dei difetti o la riduzione del prezzo, e nei casi gravi la risoluzione (art. 1668).
• Nel contratto d’opera – la denuncia va fatta entro otto giorni dalla scoperta, e l’azione si prescrive in un anno dalla consegna (art. 2226).

Il contratto dovrebbe poi definire quali errori sono coperti (bloccanti o anche minori), entro quanto si correggono, e se esiste una manutenzione continuativa con uno SLA.

2.5 Tempi, milestone e collaudo

Servono date di consegna, milestone con approvazioni parziali, eventuali penali o margini di tolleranza, e le modalità di verifica di ogni fase.

Il collaudo ha un effetto che molti ignorano. Se il committente, invitato a verificare l’opera, non lo fa senza giusti motivi o non comunica l’esito entro breve, oppure la riceve senza riserve, l’opera si considera accettata. L’accettazione copre i difetti che conosceva o poteva riconoscere (artt. 1665 e 1667 del Codice civile). Per questo il collaudo va fatto con criteri oggettivi e con eventuali riserve scritte.

2.6 Recesso, penali e responsabilità

Il committente può recedere anche a lavori iniziati, tenendo indenne il fornitore delle spese, del lavoro eseguito e del mancato guadagno (art. 1671 del Codice civile, e art. 2227 nel contratto d’opera). È un diritto di legge, e il contratto può regolarne i dettagli, come la sorte delle somme già pagate.

Sulle penali, due regole. Se sono manifestamente eccessive il giudice può ridurle (art. 1384 del Codice civile). E senza un patto sul danno ulteriore, la penale limita il risarcimento all’importo pattuito (art. 1382).

Sulle limitazioni di responsabilità, nessun patto può escludere o limitare in anticipo la responsabilità per dolo o colpa grave (art. 1229 del Codice civile). Per il software immesso sul mercato dopo il 9 dicembre 2026 cambia anche la responsabilità per danno da prodotto difettoso. La Direttiva UE 2024/2853, da recepire in Italia entro quella data, considera il software espressamente un prodotto, e verso le persone danneggiate questa responsabilità non si può escludere per contratto.

3. Proprietà intellettuale e licenze

3.1 Chi ha i diritti sul codice

Il software è protetto dal diritto d’autore come opera letteraria (art. 1, comma 2, della legge sul diritto d’autore, L. 633/1941). Chi lo paga non ne acquista i diritti per il solo fatto di averlo pagato. La risposta dipende da chi lo ha scritto.

• Dipendente – se il programma è creato nell’esecuzione delle mansioni o su istruzioni del datore di lavoro, i diritti di sfruttamento economico spettano all’azienda, salvo patto contrario (art. 12-bis L. 633/1941).
• Freelance – senza un patto scritto il risultato è incerto. La legge sul lavoro autonomo lascia al lavoratore i diritti sui propri apporti originali, salvo che l’attività inventiva sia proprio l’oggetto del contratto e sia pagata per questo (art. 4 della L. 81/2017). Nello sviluppo su commissione il codice è di solito proprio l’oggetto del contratto, ma la questione è controversa.
• Agenzia o software house – quella legge non si applica agli imprenditori, e senza un patto scritto la titolarità resta affidata alle regole generali e all’interpretazione del contratto. Anche qui la clausola scritta è l’unica certezza.

L’incertezza è la ragione migliore per scrivere la clausola. La cessione dei diritti deve risultare per iscritto (art. 110 L. 633/1941). È poi opportuno indicare territorio e durata e includere espressamente il diritto di modificare ed elaborare il codice, che sono clausole di buona redazione e non requisiti di legge.

Si cedono i diritti di sfruttamento economico. La paternità dell’opera resta comunque allo sviluppatore, perché i diritti morali non si possono cedere.

3.2 Licenza o cessione

• Licenza d’uso – il cliente usa il software, ma i diritti restano al fornitore. È adatta ai progetti standardizzati o riutilizzabili.
• Cessione – il cliente acquisisce i diritti di sfruttamento economico e può modificare, integrare, vendere o cedere il software.
• Licenza esclusiva – una via intermedia, in cui il cliente ha l’uso esclusivo e il fornitore conserva la titolarità.

La scelta dipende dal valore strategico del software e dall’interesse del fornitore a riusarlo.

3.3 Librerie open source

Quasi ogni software usa componenti open source, ciascuno con la propria licenza. Il contratto dovrebbe indicare quali componenti si usano, con quali licenze, e se comportano obblighi di apertura del codice. Con licenze copyleft come la GPL l’obbligo scatta di regola quando il software viene distribuito, non con il solo uso interno. Nel SaaS pesano licenze come la AGPL, che lo estendono a chi rende il software disponibile via rete.

Per chi produce software destinato al mercato arriva anche il Cyber Resilience Act, il Regolamento UE 2024/2847. Dall’11 dicembre 2027 il fabbricante dovrà esercitare la dovuta diligenza sui componenti di terzi, open source compreso (art. 13, paragrafo 5), e gestire le vulnerabilità per tutto il periodo di assistenza.

3.4 Il codice generato con l’IA

Dal 10 ottobre 2025 la legge sul diritto d’autore protegge le opere dell’ingegno umano, anche se create con l’aiuto dell’IA, purché siano il risultato del lavoro intellettuale dell’autore. Lo ha stabilito la L. 132/2025, modificando l’art. 1 L. 633/1941.

Per lo sviluppo la conseguenza è concreta. Il codice generato da un assistente senza un apporto creativo umano rischia di non essere un’opera protetta, e allora non c’è un diritto d’autore da cedere. La clausola sull’IA va quindi scritta come garanzia e ripartizione del rischio.

• Dichiarazione – il fornitore indica se e come usa strumenti di IA.
• Condizioni d’uso – verifica che le condizioni della piattaforma consentano l’uso commerciale dell’output.
• Garanzia – il fornitore garantisce che il codice consegnato non viola diritti di terzi e ne risponde.

4. Buone pratiche

4.1 Un brief tecnico allegato

Il contratto dovrebbe allegare un documento con obiettivi, funzionalità, tecnologie e criteri di accettazione. Riduce le ambiguità e diventa il metro del collaudo.

4.2 Milestone e verifiche

Dividere il progetto in fasi con consegne intermedie permette di controllare l’avanzamento, correggere in corsa e collegare i pagamenti ai risultati. È utile soprattutto nei progetti agili o complessi.

4.3 Un sistema di change request

Il contratto dovrebbe dire come si propongono le modifiche, chi le approva e come si calcola l’impatto su costi e tempi. Una modifica chiesta su WhatsApp e mai registrata è l’inizio tipico di una lite.

4.4 NDA e dati personali

Se lo sviluppo coinvolge prototipi, codice interno o documenti riservati, conviene un accordo di riservatezza su misura. Se il fornitore tratta dati personali per conto del cliente, per esempio in un ambiente di test con dati reali, serve il contratto previsto dall’art. 28, paragrafo 3, GDPR. Gli eventuali subfornitori devono essere autorizzati per iscritto dal cliente, in modo specifico o generale (art. 28, paragrafo 2).

5. Errori da evitare

• Accordi a voce o solo via email – il contratto è valido anche senza forma scritta, ma la cessione dei diritti si prova solo per iscritto, e senza clausole chiare ogni lite diventa una questione di prova.
• Modifiche informali – senza change request si finisce a lavorare su versioni diverse.
• Codice riusato non dichiarato – se il fornitore usa codice scritto per altri o componenti open source senza dirlo, il cliente potrebbe non avere i diritti per sfruttarlo.
• Diritti non regolati – il committente rischia di non avere i diritti sul software che ha pagato, e lo sviluppatore di vedere riusato il proprio codice senza consenso.
• Collaudo senza criteri – senza criteri oggettivi è difficile dire se il software è stato realizzato a regola d’arte, e un collaudo senza riserve può valere come accettazione.

Conclusioni

Il contratto di sviluppo software è la rete di sicurezza del progetto. La legge fornisce regole di base su garanzia, recesso e collaudo, ma lascia aperta proprio la domanda che conta di più, cioè chi ha i diritti sul codice scritto da un fornitore esterno.

Per questo la clausola sulla cessione dei diritti è quella da non lasciare mai al caso. Con l’IA generativa si aggiunge una seconda domanda, cioè se il codice sia protetto, e va gestita come un rischio da ripartire tra le parti.

Per lo Studio un contratto su misura, anche breve, vale più di un lungo modello standard.

Punti chiave

Fonti e risorse utili