Contratti di manutenzione software: cosa deve contenere per proteggere la PMI
A febbraio 2025 mi ha contattato il direttore operativo di un'azienda del settore commercio all'ingrosso di articoli per l'edilizia - 40 dipendenti, fatturato annuo intorno ai 12 milioni di euro, gestionale custom sviluppato tre anni prima da un fornitore di Torino specializzato nel settore. Il rapporto fornitore-cliente si era deteriorato negli ultimi mesi per questioni operative (tempi di risposta lunghi, modifiche richieste non implementate, conti non allineati), e il cliente stava valutando di cambiare fornitore per la manutenzione del gestionale. Il problema è emerso il giorno in cui ha chiesto formalmente al fornitore di consegnare il codice sorgente per permettere il subentro al nuovo team. Il fornitore ha risposto con una PEC di poche righe: "Il codice sorgente è proprietà intellettuale del nostro studio. Il contratto firmato non prevede trasferimento della proprietà al cliente, e l'accesso al codice non è previsto come deliverable. Siamo disponibili a continuare la manutenzione alle condizioni esistenti". In pratica: il cliente aveva pagato per tre anni un software di cui non aveva i diritti di modifica, senza possibilità di migrare a un fornitore alternativo senza riscrivere tutto da zero.
La successiva gestione del caso ha richiesto tre mesi di lavoro legale e tecnico coordinato. Il consulente legale dell'azienda ha contestato la posizione del fornitore su basi di ambiguità contrattuale e di prassi del settore (in Italia la giurisprudenza su software custom è complessa ma non univoca contro il cliente), e nel frattempo io ho lavorato con il cliente per ricostruire la documentazione del funzionamento del gestionale attraverso reverse engineering dei flussi di business, preparando il piano di riscrittura parziale in caso di rottura completa del rapporto. Alla fine il fornitore ha acconsentito alla consegna del codice dopo negoziazione, ma il danno operativo e reputazionale è stato significativo. Questo articolo descrive cosa una PMI italiana deve pretendere per iscritto in qualunque contratto di sviluppo o manutenzione software custom, ordinato per priorità e con formulazioni concrete che ho raffinato su 15+ contratti gestiti negli ultimi anni insieme a consulenti legali specializzati.
Il principio di fondo: chi paga deve controllare il proprio destino operativo
Il principio che articolo a ogni cliente prima di entrare nei dettagli è semplice: chi paga il software deve poter esercitare controllo operativo sul proprio destino. Questo significa poter, in qualunque momento, cambiare fornitore senza perdere anni di investimento, accedere ai propri dati senza dipendenze, modificare il software in risposta a esigenze di business che il fornitore non vuole o non può soddisfare. La verità amara è che molti contratti di sviluppo software in Italia - specie quelli firmati con piccoli studi senza consulenza legale specializzata - violano sistematicamente questo principio in modo sottile ma sostanziale.
I pattern di violazione ricorrenti sono tre. Primo: ambiguità sulla proprietà intellettuale del codice sviluppato. Il contratto dice "il fornitore sviluppa un software per il cliente" ma non specifica se la proprietà del codice risultante è del cliente o del fornitore. Il default della giurisprudenza italiana in assenza di clausola esplicita è problematico e soggetto a interpretazioni - il fornitore può sostenere che il contratto era "di prestazione d'opera intellettuale" con licenza d'uso al cliente, non cessione di proprietà. Secondo: dipendenza operativa dal fornitore per aspetti strutturali. Il server è intestato al fornitore, il dominio è registrato dal fornitore, l'account del database cloud è del fornitore, i certificati SSL sono gestiti dal fornitore. Cambiare fornitore richiede una transizione complessa che il cliente da solo non sa gestire. Terzo: mancanza di deliverable di documentazione. Il fornitore consegna il software funzionante ma senza documentazione tecnica - database schema, API reference, guide operative. Un subentro richiede mesi di reverse engineering invece delle settimane che dovrebbe richiedere.
Tutti e tre questi pattern vengono evitati da clausole contrattuali specifiche. Il resto dell'articolo elenca esattamente quali, con formulazioni concrete.
Clausola 1: cessione piena della proprietà intellettuale del codice
La prima clausola da inserire, non negoziabile, è la cessione esplicita della proprietà intellettuale del codice sviluppato al cliente. La formulazione legale che uso, dopo review dei consulenti legali di diversi miei clienti, è:
Articolo [N] - Proprietà intellettuale
1. Il codice sorgente sviluppato dal Fornitore nell'ambito del presente
contratto, inclusi tutti i file di codice, script, schema database,
configurazioni, documentazione tecnica, test automatici, e qualunque
altro artefatto digitale prodotto, è di proprietà esclusiva del Cliente
dal momento della sua creazione.
2. Il Fornitore cede al Cliente, a titolo definitivo ed esclusivo, tutti i
diritti patrimoniali di utilizzazione economica del software sviluppato,
ai sensi degli artt. 12 e seguenti della Legge 22 aprile 1941, n. 633
(Legge sul Diritto d'Autore) e successive modifiche.
3. La cessione include il diritto di modificare, riprodurre, distribuire,
concedere in licenza, cedere a terzi, e trasformare il codice, senza
limitazioni temporali o territoriali.
4. Il Fornitore garantisce che il codice prodotto è originale o che i
componenti di terze parti utilizzati (librerie open source, dipendenze,
pacchetti) sono compatibili con un uso commerciale da parte del Cliente,
e fornisce elenco dettagliato di tali componenti con relative licenze
(file composer.lock, package-lock.json, o equivalenti).
5. Il Fornitore si impegna a consegnare il codice sorgente completo e
aggiornato, in qualunque momento, su semplice richiesta del Cliente,
entro 15 giorni lavorativi dalla richiesta, senza oneri aggiuntivi
oltre quelli previsti dal presente contratto.Il punto 5 è il più importante operativamente - rende concreta ed esigibile la cessione di proprietà prevista al punto 1. Senza questa clausola, il fornitore potrebbe tecnicamente riconoscere la proprietà al cliente ma non consegnare mai il codice attivo, rendendo la cessione un atto formale senza sostanza pratica.
Clausola 2: escrow del codice sorgente
Nonostante la clausola 1, esiste uno scenario dove la cessione di proprietà non è sufficiente: il fornitore diventa irraggiungibile (fallimento, cessazione attività, scomparsa del titolare). In questi scenari, il cliente non ha modo di esigere la consegna del codice perché non c'è nessuno a cui rivolgersi. La soluzione è l'escrow: deposito del codice sorgente presso un terzo soggetto (studio notarile, deposito software dedicato come SourceProtect, banca dati professionale) che è autorizzato a consegnarlo al cliente in scenari predefiniti.
La clausola tipo:
Articolo [N] - Deposito del codice sorgente (escrow)
1. Il Fornitore si impegna a depositare, con cadenza trimestrale, il codice
sorgente aggiornato del software oggetto del presente contratto presso
[Nome ente di escrow], o altro soggetto equivalente concordato dalle
Parti.
2. Il deposito comprende: codice sorgente completo, schema database
aggiornato, documentazione tecnica, lista dipendenze di terze parti,
credenziali e istruzioni operative necessarie per compilare e deployare
il software.
3. L'ente di escrow è autorizzato a consegnare al Cliente il materiale
depositato in caso di:
a) inadempimento grave da parte del Fornitore (mancata risposta a
richieste di manutenzione per oltre 30 giorni consecutivi, reiterate
violazioni dello SLA di cui all'articolo [M]);
b) cessazione dell'attività del Fornitore (fallimento, liquidazione,
chiusura);
c) irreperibilità del Fornitore per oltre 45 giorni consecutivi;
d) richiesta concorde di entrambe le parti.
4. I costi dell'escrow sono a carico del Fornitore, salvo diverso accordo.L'escrow è poco conosciuto nelle PMI italiane ma è una pratica standard nell'industria software internazionale. Il costo tipico è di 300-800 euro/anno per deposito - trascurabile rispetto al valore del codice protetto. Esistono provider specializzati italiani che gestiscono l'escrow con tecnologia automatica (il codice viene committato automaticamente da Git al deposito, le release sono tracciate, il cliente può verificare in qualunque momento che il deposito sia aggiornato).
Clausola 3: documentazione tecnica come deliverable contrattuale
Il terzo pattern da prevenire è la mancanza di documentazione. Molti contratti sviluppo software prevedono consegna del "software funzionante" senza specificare cosa questo significhi rispetto alla documentazione tecnica. Il risultato pratico è che il cliente riceve codice che gira ma di cui non capisce struttura, dipendenze, rischi di manutenzione.
La clausola che uso elenca specificamente la documentazione minima obbligatoria:
Articolo [N] - Documentazione tecnica
1. Il Fornitore consegnerà, contestualmente al rilascio finale del software,
la seguente documentazione tecnica aggiornata:
a) Architettura del software: diagramma dei componenti principali,
descrizione delle dipendenze esterne, schema del database con
definizione di tabelle, indici, foreign key;
b) API Reference: documentazione OpenAPI/Swagger di ogni endpoint
esposto, con parametri, tipi di response, codici di errore;
c) Guida operativa: procedure di deploy, backup, restore, monitoring;
configurazione dell'ambiente di esecuzione; variabili d'ambiente
richieste; gestione di log e alerting;
d) Inventario delle dipendenze: elenco completo delle librerie di
terze parti utilizzate, con versioni specifiche e licenze;
e) Test: suite di test automatici con copertura minima del 60% del
codice, eseguibili dal Cliente tramite procedure documentate;
f) Credenziali e chiavi: accessi amministrativi ai sistemi (server,
database, servizi cloud), con procedura di rotazione delle chiavi
al momento della cessione o su richiesta del Cliente.
2. La documentazione è aggiornata dal Fornitore a ogni release significativa
del software, con mantenimento della coerenza fra codice e
documentazione durante tutta la durata del contratto di manutenzione.
3. La qualità della documentazione è soggetta a validazione tecnica da
parte del Cliente. In caso di documentazione manifestamente insufficiente
o inaccurata, il Cliente può richiedere integrazioni che il Fornitore
è tenuto a fornire entro 30 giorni, senza oneri aggiuntivi.Il punto 3 è il più controverso con molti fornitori ma è essenziale: senza verificabilità, la documentazione può essere consegnata come file di 3 pagine vuoti per rispettare formalmente la clausola. La soglia di "manifestamente insufficiente" va discussa in fase di trattativa ma deve rimanere nel contratto.
Stai cercando un Consulente Informatico esperto per rivedere o costruire i contratti di manutenzione software della tua PMI italiana, eliminando i rischi operativi e le dipendenze insidiose che i contratti standard tendono a nascondere? Nel mio profilo professionale trovi l'esperienza concreta su gestione vendor, subentri post-fornitore, recupero di infrastrutture abbandonate e pattern contrattuali per tutela della PMI.
Clausola 4: SLA con metriche misurabili e sanzioni
Il quarto pattern da gestire contrattualmente è lo SLA (Service Level Agreement) per la manutenzione. Molti contratti dicono genericamente "il fornitore si impegna a mantenere il software" senza definire tempi di risposta, tempi di risoluzione, finestre di disponibilità. Il risultato pratico: il cliente chiede un fix urgente, il fornitore risponde tre settimane dopo "stiamo analizzando", e non c'è leva contrattuale per esigere tempi migliori.
Lo SLA deve articolare almeno quattro dimensioni. Primo: classificazione della severity con criteri oggettivi (es: criticità alta = impossibile utilizzare una funzione principale; criticità media = funzionalità degradata ma workaround esistente; criticità bassa = bug minore, inconveniente estetico). Secondo: tempi di risposta per ogni severity (es: criticità alta = risposta entro 2 ore lavorative; media entro 8; bassa entro 24). Terzo: tempi di risoluzione (es: alta = workaround entro 8 ore, fix definitivo entro 48; media = fix entro 5 giorni lavorativi; bassa = fix entro 30 giorni). Quarto: sanzioni per superamento degli SLA (es: 10% di sconto sul canone mensile per ogni violazione di severity alta; cumulativo fino al 30%).
La clausola completa è tipicamente lunga 1-2 pagine, ma la formulazione chiave è:
Articolo [N] - Service Level Agreement (SLA)
1. Il Fornitore si impegna a rispettare i seguenti tempi di risposta e
risoluzione per le segnalazioni del Cliente, classificate per gravità:
a) Criticità 1 (sistema inutilizzabile): risposta entro 2 ore lavorative;
fix o workaround entro 8 ore lavorative.
b) Criticità 2 (funzionalità degradata): risposta entro 8 ore lavorative;
fix entro 5 giorni lavorativi.
c) Criticità 3 (bug minore): risposta entro 24 ore lavorative;
fix entro 30 giorni lavorativi.
2. Per ogni violazione dello SLA, il Cliente applicherà al canone del mese
successivo le seguenti penali:
a) violazione di Criticità 1: riduzione del canone del 20%;
b) violazione di Criticità 2: riduzione del canone del 10%;
c) violazione di Criticità 3: riduzione del canone del 3%.
Le penali sono cumulabili fino al 50% del canone mensile.
3. Tre violazioni di Criticità 1 in 12 mesi consecutivi costituiscono
inadempimento grave, con diritto del Cliente di risolvere il contratto
per giusta causa e di attivare le procedure di escrow di cui
all'articolo [M].
4. Le violazioni di SLA sono tracciate tramite il sistema di ticket
concordato dalle Parti, che costituisce evidenza probatoria.Il punto 4 è operativamente importante. Senza un sistema di ticket condiviso (GitHub Issues, Jira, o anche semplicemente email a indirizzo dedicato archiviato), le violazioni SLA diventano oggetto di dispute su "chi ha detto cosa e quando". Il sistema di ticket fornisce timestamp oggettivi e contenuto verificabile.
Clausola 5: procedure di exit e trasferimento di consegne
La quinta clausola è quella che garantisce al cliente di potersi liberare dal fornitore quando necessario. In contrasto con il default italiano dove la fine di un contratto spesso lascia il cliente in difficoltà operative, la clausola di exit definisce procedura, tempi, responsabilità del trasferimento.
Articolo [N] - Procedura di recesso e trasferimento di consegne
1. Alla conclusione del contratto per qualsiasi causa (naturale scadenza,
recesso di una delle Parti, risoluzione per inadempimento), il
Fornitore si impegna a collaborare con il Cliente e con un eventuale
nuovo fornitore designato, per garantire la continuità operativa.
2. Entro 10 giorni lavorativi dalla notifica di recesso, il Fornitore
consegnerà al Cliente:
a) Il codice sorgente completo e aggiornato al momento del recesso;
b) Un accesso amministrativo a tutti i sistemi di produzione;
c) Le credenziali di amministrazione di servizi cloud (VPS, database,
CDN, storage), con trasferimento di intestazione al Cliente se i
servizi sono attualmente intestati al Fornitore;
d) Un documento di handover tecnico che descriva lo stato attuale del
sistema, modifiche recenti, task in corso non completati, rischi
noti, e raccomandazioni operative;
e) Una procedura di escalation per le 4 settimane successive alla
fine del contratto, durante le quali il Fornitore si impegna a
rispondere a richieste di chiarimento tecnico del Cliente o del
nuovo fornitore, a tariffa oraria pre-concordata.
3. La non esecuzione della procedura di consegna nei tempi previsti
costituisce inadempimento grave.
4. Al completamento della procedura, il Fornitore cesserà qualunque
accesso amministrativo ai sistemi del Cliente, e distruggerà qualunque
copia di credenziali, chiavi di accesso, dati del Cliente in suo
possesso, producendo attestazione scritta di tale distruzione.Il punto 2e è quello che spesso fa la differenza pratica in un subentro. Le prime settimane dopo un cambio di fornitore sono quelle in cui emergono domande tecniche sul sistema che solo chi lo ha costruito può rispondere rapidamente. Avere contrattualmente vincolato l'ex-fornitore a rispondere, anche a tariffa oraria, elimina la dinamica tossica di "abbiamo chiuso il contratto, non ti rispondo più". Questo pattern è alla base del mio approccio operativo quando gestisco un subentro senza lo sviluppatore originario su codice PHP legacy con le prime azioni critiche - la clausola contrattuale di transizione riduce enormemente il rischio operativo.
Clausola 6: proprietà legale dell'infrastruttura
La sesta clausola, spesso dimenticata ma critica, riguarda la proprietà legale dell'infrastruttura su cui il software gira. Molti fornitori IT intestano i server cloud, i domini, gli account SaaS alla propria azienda per "semplicità operativa" - ma questa semplicità diventa un problema quando il rapporto cessa.
Articolo [N] - Intestazione delle infrastrutture
1. Tutti gli account di servizi infrastrutturali utilizzati per il software
oggetto del presente contratto (provider cloud, registrar domini, servizi
di email transazionale, CDN, certificate authority) saranno intestati al
Cliente, non al Fornitore.
2. Il Fornitore, laddove necessario per la gestione operativa, opererà sui
sistemi del Cliente tramite accesso delegato (sub-account, utenze tecniche
dedicate, chiavi API restritte), senza mai detenere la proprietà degli
account principali.
3. Qualora ragioni tecniche specifiche giustifichino un'intestazione
temporanea al Fornitore (es. attivazione rapida di un servizio che
richiede identità verificata), il Fornitore si impegna a trasferire
l'intestazione al Cliente entro 30 giorni.
4. Il Cliente ha diritto di ricevere, in qualunque momento, copia completa
delle credenziali di ogni servizio infrastrutturale utilizzato, in
formato cifrato concordato dalle Parti (es. Bitwarden export, 1Password
vault), senza oneri aggiuntivi.Questa clausola previene lo scenario che ho descritto nel mio approfondimento sulla gestione delle emergenze server dedicato Hetzner post-sviluppatore sparito - uno dei casi più frustranti che gestisco, dove la soluzione tecnica è comunque complessa anche quando il cliente ha ragione legale.
La clausola che NON deve essere nel contratto: non concorrenza eccessiva
Oltre alle clausole da pretendere, c'è una categoria di clausole che il fornitore potrebbe voler inserire ma che il cliente dovrebbe resistere: le clausole di non concorrenza/divieto di migrazione che limitano la libertà futura del cliente. Esempi: "il cliente non può affidare la manutenzione del software a terzi per 3 anni dalla fine del contratto", "il cliente non può sviluppare internamente funzioni simili a quelle fornite dal software", "il cliente non può usare il codice sorgente per progetti diversi da quello oggetto del contratto".
Queste clausole hanno validità legale incerta in Italia (la giurisprudenza tende a considerarle limitazioni sproporzionate alla libertà economica del cliente se applicate in modo restrittivo) ma creano incertezza e costo di gestione anche quando sono contestabili. La negoziazione corretta è di rifiutarle completamente in fase di contratto, non di accettarle contando sulla contestabilità successiva.
Il processo di negoziazione: come far accettare queste clausole
La domanda pragmatica che ogni CEO/direttore operativo pone è: "queste clausole belle sulla carta, ma poi il fornitore le accetta o va via?". La mia esperienza sui contratti che ho gestito come consulente terzo è che la maggior parte dei fornitori italiani serie accetta queste clausole quando sono presentate in modo professionale. I fornitori che le rifiutano in modo aggressivo sono quasi sempre fornitori che hanno un business model basato sulla dipendenza del cliente - e sono proprio quelli da evitare.
Il pattern di negoziazione che applico in tre step. Primo: presentare le clausole come standard di settore, non come richieste esotiche. "Queste sono le clausole di tutela che i nostri consulenti legali ci raccomandano per qualunque contratto software - le troverai in contratti analoghi con fornitori medio-grandi". Questo inquadramento elimina il tono di sfiducia personale. Secondo: concedere flessibilità sui dettagli, mai sulle sostanze. Il cliente può accettare tempi di preavviso più lunghi, penali SLA leggermente più basse, cadenza escrow trimestrale invece che mensile - senza perdere il punto centrale della tutela. Terzo: se il fornitore rifiuta categoricamente le clausole essenziali (1, 2, 5, 6), prendere nota e cercare alternativi. Il rifiuto stesso è segnale di come sarà il rapporto in futuro.
Su 15+ contratti che ho aiutato a negoziare negli ultimi tre anni, due hanno portato a cambio di fornitore perché il fornitore originario si è rifiutato di cedere la proprietà del codice (entrambi i casi finiti con recupero difficile di codice da parte del cliente). Gli altri 13 sono stati firmati con le clausole che ho descritto, con negoziazione durata tipicamente 2-4 settimane di scambio fra consulenti legali.
Se hai già firmato un contratto rotto: cosa fare adesso
Un articolo realista deve includere anche la risposta alla domanda "e se ho già firmato un contratto che non mi tutela?". La situazione è recuperabile, ma richiede lavoro legale e tecnico coordinato.
Il pattern che applico. Primo: ottenere valutazione legale indipendente del contratto esistente da consulente legale specializzato in IT. Spesso emergono margini di interpretazione che favoriscono il cliente anche in contratti scritti male. Secondo: documentare tecnicamente lo stato attuale del sistema in modo indipendente dal fornitore - reverse engineering dello schema database, documentazione dei flussi di business, inventario dei file sorgente accessibili. Questa documentazione serve sia come backup se il fornitore diventa ostile, sia come leva negoziazione. Terzo: costruire il pacchetto operativo di disaster recovery - backup completo in infrastruttura controllata dal cliente, procedura di deploy su infrastruttura alternativa, test di restore. Questo trasforma la dipendenza operativa in un fatto mitigato. Quarto: aprire la negoziazione per rinnovo contrattuale con le nuove clausole, usando come leva il lavoro di documentazione autonoma - "possiamo rinnovare con queste clausole oppure siamo pronti a operare in autonomia".
Nel caso del cliente commercio edilizia dell'incipit, dopo tre mesi di lavoro legale+tecnico il rapporto con il fornitore originario è stato riorganizzato su base contrattuale nuova, con clausole simili a quelle descritte in questo articolo. Il costo del lavoro (~25.000 euro di consulenze legali + tecniche) è stato ripagato dal mantenimento dell'operatività senza migrazione forzata, che sarebbe costata 120.000+ euro di riscrittura.
Se la tua PMI sta negoziando un nuovo contratto di sviluppo software, o ha in atto contratti di manutenzione che non sei sicuro ti tutelino adeguatamente, o sta vivendo un deterioramento di rapporto con un fornitore IT e vuole capire i propri margini di libertà, contattami per una valutazione: in una settimana di lavoro analizzo i contratti esistenti, identifico le aree di rischio prioritarie, costruisco la documentazione tecnica autonoma che riduce la dipendenza operativa, e ti supporto nelle negoziazioni con consulente legale specializzato. L'obiettivo è trasformare la tua posizione da "prigioniero del fornitore" a "cliente che sceglie liberamente con chi lavorare" - condizione indispensabile per qualunque strategia IT di medio-lungo termine.