Manutenzione del software su misura: errori, evolutive e diritti sulle modifiche
Il contratto di manutenzione di un software su misura dovrebbe distinguere correzione degli errori, adeguamenti e nuove funzionalità, collegando ogni intervento a una versione identificata e ai diritti necessari. Pagare assistenza non chiarisce automaticamente chi può modificare il programma, accedere al sorgente o utilizzare componenti di terzi. Il fascicolo deve rendere verificabili richieste, autorizzazioni, risultati e materiali aggiornati.
Aggiornato al 4 novembre 2026 — Redazione Studio Legale Coviello. Il profilo professionale dello Studio descrive attività nella proprietà intellettuale e nei contratti. Questa guida riguarda la gestione degli interventi successivi alla consegna; il rapporto va esaminato alla luce del contratto e della disciplina applicabile.
Il software consegnato non resta fermo
Dopo l’avvio possono cambiare sistemi operativi, collegamenti esterni e necessità dell’impresa. Il contratto dovrebbe rendere comprensibile quali interventi rientrino nel servizio e quali richiedano una decisione ulteriore. La distinzione non dipende soltanto dal nome attribuito a una richiesta: occorre confrontarla con funzionalità, specifiche e obblighi concordati, senza presumere che ogni modifica sia inclusa oppure sempre aggiuntiva.
Il collaudo del software su misura riguarda la verifica della prestazione consegnata. La manutenzione affronta invece il periodo successivo e deve coordinarsi con riserve, garanzie e obblighi ancora aperti. Un verbale di accettazione non dovrebbe essere letto isolatamente per determinare il trattamento di qualsiasi problema emerso in seguito.
Errore, adeguamento ed evolutiva
Un’anomalia può impedire una funzione prevista; un adeguamento può servire a mantenere il programma compatibile con un ambiente modificato; un’evolutiva può aggiungere una funzione nuova. Sono categorie organizzative utili, ma devono trovare riscontro nel contratto concreto. Il semplice cambio di etichetta nel sistema di assistenza non determina automaticamente il prezzo, i diritti o la responsabilità dell’intervento.
È opportuno definire un processo per i casi dubbi: descrizione del comportamento, versione, ambiente, risultato atteso e confronto con la specifica. Se una richiesta contiene insieme un errore e una funzione aggiuntiva, il fornitore dovrebbe renderlo visibile prima dell’approvazione economica. La documentazione permette di discutere attività identificabili, anziché una formula generica come “sistemare il gestionale”.
Il quadro dei diritti sul programma
La direttiva 2009/24/CE sulla tutela dei programmi per elaboratore disciplina, tra l’altro, atti riservati e specifiche deroghe. Gli articoli 4 e 5 richiedono di distinguere le facoltà del titolare dagli atti necessari all’uso conforme alla destinazione e alla correzione di errori, nel quadro delle condizioni applicabili. Non ne deriva una libertà indiscriminata di modificare e distribuire qualunque programma.
Per un progetto commissionato occorre quindi verificare contratto di sviluppo, licenze e diritti effettivamente attribuiti. Disponibilità di una copia, pagamento e accesso tecnico non risolvono da soli ogni questione. L’impresa dovrebbe sapere chi può intervenire, su quali parti e per quali utilizzi, mantenendo separata l’analisi di eventuali disposizioni inderogabili dalla descrizione commerciale del servizio.
Sorgenti, documentazione e accessi
La manutenzione può richiedere codice sorgente, procedure di compilazione, documentazione e credenziali gestite con modalità appropriate. Il fascicolo dovrebbe identificare quali materiali sono disponibili e quali prestazioni il fornitore deve effettuare. Non è prudente dare per scontato che il diritto d’uso comprenda sempre la consegna di tutto il sorgente o che una cartella ricevuta contenga quanto serve a ricostruire l’applicazione.
Quando vengono utilizzati strumenti di deposito fiduciario, l’articolo sul source code escrow e sulla continuità del software approfondisce una soluzione specifica. L’escrow non sostituisce il contratto di manutenzione né rende automaticamente utilizzabile il materiale depositato: condizioni, aggiornamenti e facoltà devono essere coordinati con il rapporto reale.
Ogni richiesta deve individuare una versione
Un sistema di assistenza utile registra versione del programma, ambiente e data della segnalazione, insieme a quanto occorre per riprodurre il problema. I dati vanno limitati a quelli pertinenti e trasmessi tramite canali appropriati. Allegare un’intera base clienti per dimostrare un’anomalia può essere inutile e creare problemi ulteriori rispetto a quello che si intende risolvere.
La richiesta dovrebbe distinguere fatti osservati da ipotesi sulla causa. “La procedura si interrompe al passaggio indicato” è un’informazione diversa da “il fornitore ha cancellato dati”. Il tecnico può così analizzare un comportamento documentato, mentre il referente contrattuale verifica il perimetro degli obblighi. La descrizione operativa non deve anticipare conclusioni giuridiche non ancora supportate.
Livelli di servizio e tempi da negoziare
Occorre distinguere presa in carico, analisi, soluzione temporanea e rilascio definitivo. Un tempo di risposta non coincide necessariamente con un termine di ripristino. Le priorità devono dipendere da criteri comprensibili, come blocco di una funzione o disponibilità di una soluzione provvisoria, evitando promesse assolute che non considerino dipendenze e attività necessarie del cliente.
Non esiste un livello di servizio adatto a ogni impresa. Orari, reperibilità, modalità di escalation e responsabilità vanno concordati rispetto all’applicazione e alle risorse disponibili. Il contratto dovrebbe indicare anche che cosa il cliente deve fornire per consentire l’intervento e come vengono gestiti ritardi o impedimenti, senza trasformare ogni attesa in una giustificazione indeterminata.
Evolutive: approvazione prima dell’esecuzione
Una richiesta di nuova funzione dovrebbe descrivere risultato, confini, dipendenze e criteri di verifica. È utile separare l’approvazione tecnica da quella economica e contrattuale. Un messaggio del reparto utilizzatore non dovrebbe diventare, senza verifica dei poteri, accettazione di un ampliamento dell’incarico o di nuove condizioni sui diritti.
Il documento di modifica può indicare materiali consegnati, utilizzi consentiti e coordinamento con la licenza esistente. La guida europea sugli accordi di licenza richiama l’esigenza di identificare diritti e condizioni d’uso. Nel software, il fascicolo deve rendere leggibile che cosa viene aggiunto al programma e quale disciplina seguirà il risultato.
Componenti di terzi e aggiornamenti delle licenze
Una modifica può introdurre librerie o servizi esterni. Occorre aggiornare l’inventario dei componenti e verificarne condizioni e versioni, senza presumere che una licenza già esaminata copra automaticamente qualsiasi aggiornamento. L’articolo sui componenti open source nel software commissionato approfondisce il dossier necessario prima della consegna.
La documentazione dovrebbe distinguere codice del progetto, componenti preesistenti del fornitore e materiali di terzi. Anche l’audit delle licenze software ha un obiettivo distinto ma complementare: confrontare usi effettivi e autorizzazioni. La manutenzione dovrebbe mantenere quel quadro aggiornato, evitando che una nuova dipendenza resti sconosciuta al cliente.
Prove prima del rilascio in produzione
Il piano di verifica dovrebbe essere proporzionato all’intervento e registrare esito, versione e riserve. Correggere un errore non significa aver controllato ogni funzione del programma; aggiungere una caratteristica non dimostra che tutte le integrazioni continuino a funzionare. Occorre definire i controlli necessari e i referenti che possono approvare il passaggio all’ambiente operativo.
È utile conservare una nota di rilascio con modifica eseguita, documentazione aggiornata e questioni aperte. Quando è previsto un piano di ritorno alla versione precedente, va verificato rispetto ai sistemi reali. La sua presenza nel contratto non dimostra da sola che sia tecnicamente praticabile o che non comporti conseguenze sui dati e sulle attività del cliente.
Cambiare il manutentore senza perdere il fascicolo
L’impresa dovrebbe poter ricostruire storia delle versioni, interventi, materiali e diritti quando cambia un referente o un fornitore. Il contributo sul cambio del fornitore software affronta quel passaggio specifico. La manutenzione quotidiana prepara la continuità se conserva documenti ordinati e accessi gestiti secondo le condizioni concordate.
Alla chiusura occorre individuare attività residue, credenziali da disattivare o trasferire con modalità consentite e materiali da consegnare. Non bisogna inserire segreti di accesso in un verbale diffuso a tutti. La prova del passaggio deve rendere verificabili le attività senza esporre informazioni di sicurezza o attribuire diritti che non sono stati acquisiti.
Checklist per la revisione del servizio
Controllare contratto originario, licenze, definizione degli interventi, versioni, materiali, livelli di servizio, ruoli, approvazioni delle evolutive, componenti di terzi, prove e documentazione finale. Ogni termine usato nel preventivo dovrebbe essere comprensibile anche a chi gestirà le richieste dopo la firma. Se un punto rimane aperto, identificarlo prima dell’avvio evita di trasformare un’esigenza operativa urgente in una trattativa improvvisata.
Un caso ipotetico è l’aggiunta di un nuovo collegamento a un servizio esterno mentre si corregge un errore. Il fascicolo dovrebbe separare le due attività, indicare le condizioni della nuova dipendenza e documentare l’approvazione. In questo modo diventa possibile verificare che cosa è stato chiesto, realizzato e concesso, senza confondere tutto sotto la parola manutenzione.
Domande frequenti
La manutenzione comprende sempre ogni nuova funzione?
No. Dipende dal contratto e dalle attività concordate. Occorre distinguere correzioni, adeguamenti ed evolutive rispetto alle specifiche e alle condizioni effettive del rapporto.
Pagare un intervento significa acquistare tutti i diritti?
Non automaticamente. Devono essere verificati contratto, risultato, facoltà attribuite e componenti di terzi. Il pagamento non sostituisce l’identificazione del perimetro dei diritti.
Un tempo di risposta garantisce il ripristino entro quel termine?
Non necessariamente. Presa in carico e soluzione possono avere discipline diverse. È essenziale leggere le definizioni e le condizioni del livello di servizio pattuito.
Posso affidare gli interventi a un altro fornitore?
Occorre valutare diritti, materiali disponibili, contratto e norme applicabili. Accesso tecnico e autorizzazione giuridica devono essere verificati separatamente, senza presumere una risposta universale.
Rivedere il contratto sul software effettivo
Raccogli accordo di sviluppo, licenze, proposta di assistenza e un esempio delle richieste previste. Per coordinare obblighi e diritti sulle modifiche, consulta i servizi dello Studio sui contratti di licenza. Indica dipendenze esterne e necessità di continuità, così da esaminare problemi concreti anziché formule generiche.
Per un’introduzione generale alla tutela delle opere creative, guarda il video dello Studio «Copyright: come funziona». Le autorizzazioni per i materiali del progetto devono comunque essere verificate nei rispettivi contratti.
Fonti ufficiali verificate il 2 novembre 2026: direttiva 2009/24/CE, articoli 4 e 5; Commissione europea, Your Europe sugli accordi di licenza. La disciplina va coordinata con il diritto applicabile e il contratto. Immagini illustrative dalla mediateca dello Studio.
Commenti