Download Word gratuito • Modifica online • Salva e condividi con Drive • Esporta in PDF
Un contratto di sviluppo e di licenza del software è un accordo bilaterale tra una società di sviluppo (Impresa) e un cliente che commissiona la realizzazione di software personalizzato. Il documento disciplina come lo sviluppo viene eseguito, quando e come il cliente approva il lavoro completato, e quali diritti di uso il cliente riceve sul software finito. Include sezioni dedicate alle specifiche funzionali (cosa il software deve fare), alle specifiche dettagliate di progettazione (come viene costruito), ai cicli di approvazione cliente con termini precisi, ai criteri di collaudo e accettazione, e alla tabella degli onorari. Disponibile in formato Word scaricabile e completamente modificabile, permette a entrambe le parti di adattare il contratto alle circostanze specifiche del progetto: dimensione, complessità, pagamenti a milestone o forfettari, e diritti di proprietà intellettuale.
Senza un contratto scritto e firmato, il rischio di malintesi e controversie tra fornitore e cliente è altissimo. Il fornitore sviluppa ciò che crede il cliente abbia richiesto, il cliente scopre che mancano funzioni critiche o che il software non si comporta come previsto, e si avvia una disputa su chi sia responsabile e chi debba pagare per correzioni. Inoltre, senza termini chiari sulle approvazioni, il cliente può ritardare indefinitamente la revisione del lavoro, bloccando il progetto e generando costi aggiuntivi per lo sviluppatore. Questo contratto protegge entrambe le parti: fissa scadenze esatte per la consegna delle specifiche, assegna al cliente un numero limitato (ma ragionevole) di giorni per approvare o respingere il lavoro, stabilisce criteri di collaudo oggettivi invece di soggettivi, e chiarisce quali diritti il cliente ha sul software (licenza limitata, non proprietà totale, a meno che non sia diversamente concordato). In caso di controversia, avere un contratto firmato e dettagliato riduce significativamente il ricorso a giudizio e i costi legali, poiché le responsabilità sono già scritte.
| Se la tua situazione è… | Usa questo modello |
|---|---|
| Cliente riceve diritti esclusivi di licenza, fornitore non può cedere ad altri | Licenza software esclusiva |
| Fornitore mantiene diritto di sviluppare e cedere software simile ad altri clienti | Licenza software non esclusiva |
| Pagamenti scaglionati legati al raggiungimento di specifiche fasi di approvazione | Contratto sviluppo con pagamento a milestone |
| Compenso totale determinato in anticipo, indipendente da modifiche minori | Contratto sviluppo con pagamento fisso |
| Cliente acquisisce diritti su codice sorgente e manutenzione futura dopo licenza | Estensione diritti post-sviluppo |
| Include servizi di assistenza tecnica, aggiornamenti e correzione di bug nel tempo | Licenza software con supporto e maintenance |
| Sviluppo da remoto, specifiche condizioni di comunicazione e consegna documentazione | Accordo software per team distribuiti |
Perché conta: Il fornitore poi sostiene che ha consegnato quello che stava scritto, mentre il cliente ritrova funzioni mancanti o comportamenti non attesi.
Fix: Elenca ogni funzione richiesta con numeri, formati di dati e esempi concreti nel programma allegato.
Perché conta: Senza scadenza, il cliente ritarda indefinitamente la revisione, bloccando il progetto e creando costi aggiuntivi per il fornitore.
Fix: Specifica chiaramente quanti giorni lavorativi il cliente ha per approvare o respingere; se non risponde, considerare come approvato.
Perché conta: Se i criteri di accettazione sono soggettivi, il cliente può sempre rifiutare dicendo che il software "non funziona bene" senza una base misurabile.
Fix: Definisci test specifici (es. "1000 transazioni al secondo", "caricamento lista in meno di 2 secondi") nel capitolo collaudi.
Perché conta: Controversie su quanto il cliente deve pagare, se sono incluse spese, se ci sono maggiorazioni per modifiche oltre progetto.
Fix: Crea un Programma con tassa fissa, elenco spese rimborsabili, tasso di rimborso e condizioni di pagamento a milestone.
Perché conta: Al termine il fornitore consegna poco o nessun manuale; il cliente non sa come mantenere o estendere il software.
Fix: Nel contratto richiedi un Sistema di Documentazione completo (manuale utente, manuale tecnico, codice commentato) consegnato prima dell'approvazione finale.
Perché conta: Il contratto è incompleto; le specifiche funzionali, gli onorari e il cronogramma rimangono in sospeso, creando incertezza legale.
Fix: Assicurati che tutti e quattro i programmi (funzionali, dettagliate/collaudi, onorari, attuazione) siano allegati, compilati e firmati prima della sottoscrizione.
In linguaggio semplice: Identifica la società sviluppatrice (Impresa) e la società cliente, con sede legale, giurisdizione costitutiva e riferimenti ufficiali.
TRA: [IL NOME DELLA TUA IMPRESA] (l'"Impresa"), una persona giuridica costituita e regolata in conformità alle leggi di [Stato/Provincia], avente sede legale in: [IL TUO INDIRIZZO COMPLETO] E: [IL NOME DELL'IMPRESA] (il "Cliente"), una persona giuridica costituita e regolata in conformità alle leggi di [Stato/Provincia], avente sede legale in: [INDIRIZZO COMPLETO].
Errore comune: Omettere la giurisdizione costitutiva o non specificare chiaramente se una parte è persona fisica o giuridica.
In linguaggio semplice: Stabilisce quando il contratto ha effetto e quale data certifica il superamento di tutti i collaudi e l'accettazione ufficiale del software.
Per "Data di Inizio" si intende la data di sottoscrizione del presente Contratto da parte delle parti. Per "Data di Approvazione" si intende la data in cui il software ha superato tutti i test di approvazione in conformità alle disposizioni di [SPECIFICARE].
Errore comune: Non allineare la data di inizio con le tempistiche di consegna delle specifiche dettagliate.
In linguaggio semplice: Definisce cosa il software deve fare: capacità, funzioni e risultati attesi descritti in un programma allegato che il fornitore deve realizzare.
Per "Specifiche Funzionali" si intendono le capacità e le funzioni che devono essere soddisfatte dal software e che sono descritte nel Programma [SPECIFICARE].
Errore comune: Lasciare le specifiche funzionali vaghe o incomplete; il cliente deve elencare ogni funzione richiesta nel programma allegato.
In linguaggio semplice: Descrive la documentazione tecnica di progettazione che il fornitore prepara sulla base delle specifiche funzionali, inclusi criteri di test e collaudo.
Alla Data di Inizio, l'Impresa inizierà la preparazione delle Specifiche Dettagliate di progettazione del Software Concesso in Licenza e dei criteri di approvazione delle verifiche ("Specifiche Dettagliate"). Le Specifiche Dettagliate dovranno essere preparate in conformità e dovranno essere coerenti alle Specifiche Funzionali.
Errore comune: Non assegnare chiare responsabilità su chi redige le specifiche dettagliate o non prevedere scadenze di consegna.
In linguaggio semplice: Stabilisce i tempi e le modalità in cui il cliente deve revisionare, approvare o respingere le specifiche dettagliate, con opzioni di richiesta di modifiche.
Al momento della consegna delle Specifiche Dettagliate al Cliente, il Cliente avrà [NUMERO] Giorni Lavorativi per approvare le Specifiche Dettagliate, per respingere la parte delle Specifiche Dettagliate che ha a che fare con i criteri di approvazione della verifica, per respingere le Specifiche Dettagliate nel loro complesso (specificando in modo ragionevole il modo in cui le specifiche dettagliate non sono conformi alle Specifiche Funzionali).
Errore comune: Non fissare termini precisi di risposta, il che può causare ritardi indefiniti nelle approvazioni.
In linguaggio semplice: Se il cliente rifiuta le specifiche dettagliate modificate, il fornitore ha diritto a un ulteriore periodo per correggerle; se il rifiuto persiste, il cliente può rescindere il contratto.
Se il Cliente rifiuta le Specifiche Dettagliate modificate nel loro insieme, o se l'Impresa non riesce a fornire le Specifiche Dettagliate al Cliente entro [NUMERO] Giorni Lavorativi dalla Data di Inizio, allora il Cliente può recedere dagli obblighi previsti dal presente Contratto.
Errore comune: Non specificare conseguenze chiare del rifiuto, il che può generare controversie su diritti di rescissione.
In linguaggio semplice: Definisce la tassa di licenza dovuta dal cliente e il rimborso di spese effettive (trasferte, alloggio, comunicazioni) con applicazione di tasse federali, provinciali e comunali.
Per "Onorari" si intende la Tassa di Licenza da versare da parte del Cliente all'Impresa di cui al Programma "B" insieme al rimborso all'Impresa di tutte le spese effettive (tra cui, ma non solo, le spese per viaggi, alloggio, lunga distanza, corriere e fax) più qualsiasi tassa federale, provinciale e comunale applicabile.
Errore comune: Non separare chiaramente onorari fissi da spese variabili, creando ambiguità sui costi totali.
In linguaggio semplice: Richiede che il fornitore consegni manuale completo, diagrammi, codice sorgente, specifiche tecniche e istruzioni operative per permettere al cliente di comprendere e gestire il software.
Per "Sistema di Documentazione" si intendono tutti i documenti, i diagrammi di flusso, le schede di stampa, le specifiche dei file, i dati delle prove, i layout dello schermo, i dizionari di dati, i formati delle relazioni e tutti i manuali che insieme contengono una descrizione completa e la definizione di tutte le condizioni di funzionamento del Software Concesso in Licenza.
Errore comune: Non specificare il livello di dettaglio, il formato (cartaceo, digitale) e la lingua della documentazione.
In linguaggio semplice: Definisce quali giorni contano ai fini del calcolo dei termini contrattuali, escludendo fine settimana e festività federali e provinciali.
Per "Giorno Lavorativo" si intende ogni Lunedì, Martedì, Mercoledì, Giovedì e Venerdì salvo che in tale giorno si verifichi una festa federale o provinciale secondo la legge osservata in Provincia di [SPECIFICARE].
Errore comune: Non specificare quale giurisdizione determina le festività, causando ambiguità se le parti operano in province diverse.
In linguaggio semplice: Specifica il computer, il processore, il sistema operativo e altri dispositivi fisici su cui il software deve essere sviluppato, testato e installato.
Per "Hardware" si intende l'unità centrale di elaborazione e il sistema operativo di accompagnamento previsti nel Programma [SPECIFICARE] e che sarà utilizzato dal Cliente per il funzionamento del Software.
Errore comune: Non documentare le specifiche hardware minime, il che può causare problemi di compatibilità e installazione successivi.
Inserisci il nome legale, la giurisdizione di costituzione, la provincia e l'indirizzo completo di sia la società sviluppatrice sia il cliente. Verifica che i dati siano identici a quelli nei registri ufficiali (CCIAA, albo professionisti).
💡 Se una delle parti è persona fisica, specifica comunque il domicilio fiscale e il documento di identità.
Inserisci la data di sottoscrizione (data di inizio), il numero di giorni lavorativi per la consegna delle specifiche dettagliate e per ogni ciclo di approvazione cliente. Assicurati che le tempistiche siano realistiche.
💡 Usa periodi di 10–15 giorni lavorativi per approvazioni; periodi più lunghi riducono il rischio di contestazioni.
Nel Programma A (o quello che hai designato), elenca in dettaglio ogni capacità e funzione che il software deve avere. Sii il più specifico possibile: numeri, formati di dati, integrazioni, performance.
💡 Chiedi al cliente di firmare il programma con le specifiche funzionali per evitare contestazioni successive su cosa era incluso.
Nel programma allegato relativo alle specifiche dettagliate, descrivere in modo misurabili i test e i criteri di accettazione che il software deve superare. Specifica chi conduce i test (fornitore, cliente o terzo).
💡 Criteri oggettivi (es. "100 transazioni al secondo senza errori") riducono le controversie rispetto a criteri soggettivi.
Nel Programma B, inserisci la tassa di licenza totale, le modalità di pagamento (anticipato, a milestone, alla consegna), le spese rimborsabili e il tasso di rimborso. Specifica se sono incluse tasse o se il cliente le paga a parte.
💡 Se pagamenti a milestone, collega ogni versamento al superamento di fasi specifiche di sviluppo.
Nel programma allegato, indica marca e modello del server/PC, versione del sistema operativo, RAM, disco rigido e software di supporto necessari. Chiarisci se il cliente fornisce hardware o il fornitore lo configura.
💡 Includi anche dettagli su database, librerie software di terze parti e dipendenze di sistema.
Nel Programma relativo all'Attuazione, crea un cronogramma con le fasi di sviluppo, le date di consegna di componenti intermedi, i collaudi e la data target di approvazione finale.
💡 Allega gantt chart o elenco puntato con milestone; rende il piano visibile e concordato.
Entrambe le parti firmeranno il contratto e tutti i programmi allegati. Ogni parte conserva una copia originale. Se ci sono successive modifiche, usa un allegato di modifica firmato da entrambe.
💡 Usa firma digitale qualificata per conformità legale italiana; stampa e conserva anche una copia cartacea.
Sì, il contratto prevede una clausola di recesso nel caso in cui l'Impresa non consegni le Specifiche Dettagliate entro il numero di Giorni Lavorativi specificati dalla Data di Inizio. Se il Cliente esercita il recesso, può interrompere gli obblighi contrattuali. Tuttavia, consulta un avvocato per verificare se sono dovute penali per annullamento anticipato, poiché il contratto potrebbe prevedere compensazioni parziali al fornitore.
Se il Cliente rifiuta i criteri di approvazione della verifica proposti dal fornitore, il Cliente diventato responsabile, a proprie spese, dello sviluppo di criteri di collaudo conformi alle Specifiche Funzionali. Questo protegge il fornitore da indefiniti cicli di revisione e costringe il Cliente a prendere posizione. In pratica, è meglio negoziare i criteri durante la fase di specifiche dettagliate.
Il contratto non include automaticamente una penale per il fornitore se i test falliscono. Tuttavia, il software non raggiunge la Data di Approvazione e il cliente non è obbligato a pagare la parte della tassa di licenza legata all'accettazione. Il fornitore deve correggere e ripetere i collaudi. Per proteggere il fornitore, conviene inserire nel Programma sui collaudi un numero massimo di cicli di test gratuiti (es. 3) e poi applicare una tariffa per ogni ciclo aggiuntivo dovuto a errori del Cliente.
Il contratto usa il termine \"Software Concesso in Licenza\", il che suggerisce che il fornitore mantiene la proprietà intellettuale e il cliente riceve il diritto di usarlo secondo i termini della licenza. Se desideri acquisire la proprietà completa o il codice sorgente, deve essere negoziato e aggiunto esplicitamente nel Programma. Senza una clausola specifica, il cliente non ha diritti di modifica o redistribuzione.
Il contratto disciplina lo sviluppo e l'approvazione iniziale. Le modifiche successive (manutenzione, aggiornamenti, nuove funzioni) devono essere coperte da un contratto separato di supporto e manutenzione, oppure da richieste di modifica formali e pagate a parte. Aggiungi un programma separato se intendi offrire servizi post-lancio.
Il contratto non specifica esplicitamente una clausola arbitrale o una corte di competenza. La giurisdizione dipenderà dalla legge della Provincia di [SPECIFICARE] indicata nel contratto. Se il fornitore è in Italia e il cliente in Svizzera (Ticino), è essenziale negoziare quale tribunale ha competenza (es. tribunale di Milano o Lugano) e quale legge si applica (diritto italiano o svizzero). Consulta un avvocato per aggiungere una clausola di risoluzione delle controversie appropriata.
Il contratto non prevede un processo formale di change request. Se entrambe le parti concordano su una modifica, dev'essere documentata per iscritto in una lettera di modifica o un allegato firmato entrambi. Ogni modifica deve includere l'impatto su specifiche dettagliate, cronogramma, collaudi e onorari. Senza una modifica documentata, il fornitore non è tenuto a implementare richieste non previste.
Il contratto non include una clausola esplicita di limitazione di responsabilità. In generale, il diritto italiano prevede che un fornitore è responsabile per danni diretti derivanti da inesecuzione, ma è spesso possibile limitare la responsabilità a un massimale (es. l'importo pagato) o escludere danni indiretti (perdite di guadagno, interruzione dell'attività). Aggiungi una clausola di limitazione di responsabilità per proteggere il fornitore, oppure negozia un'assicurazione di responsabilità civile professionale.
Il contratto protegge il fornitore attraverso la Licenza (non la proprietà totale), il che significa che il cliente non può redistribuire o copiare il software. Tuttavia, il contratto non include clausole specifiche di protezione della proprietà intellettuale, di riservatezza, di penali per violazione di licenza o di indennizzo. Aggiungi un capitolo sulla proprietà intellettuale, sulla riservatezza del codice sorgente e su eventuali penali contrattuali per violazioni.
Un contratto di licenza standard copre i termini di uso di software già sviluppato (es. Microsoft Office, SAP). Questo contratto invece comprende sia lo sviluppo custom sia la licenza di ciò che viene creato. Se commissionaste un software completamente nuovo con specifiche personalizzate, questo contratto è più idoneo; se invece usaste software esistente, un contratto di licenza standard è sufficiente.
Questo contratto include sia sviluppo sia licenza, stabilendo anche che il cliente riceve diritti limitati di uso (licenza, non proprietà). Un contratto di sola sviluppo assegnerebbe al cliente la proprietà completa del codice e del know-how, permettendo redistribuzione e modifica. Scegli questo modello se il fornitore vuole mantenere la proprietà intellettuale; usa un contratto di sola sviluppo se il cliente compra il diritto di ownership.
Un contratto di servizi IT generico disciplina manutenzione, supporto tecnico e operazioni ricorrenti (es. help desk, backup, monitoraggio). Questo contratto è specifico per lo sviluppo e la licenza di un nuovo software. Se serve un contratto che copra sia sviluppo che supporto successivo per 3 anni, considera di creare due sezioni (sviluppo + licenza iniziale; supporto post-lancio come add-on).
Una lettera di intenti o SOW è un documento informale che descrive cosa il cliente chiede e a quale prezzo, ma non è un contratto legale vincolante. Questo modello è un vero contratto italiano, con definizioni legali, obblighi reciproci, termini di pagamento e rimedi per inadempimento. Se il progetto ha rischi o valore significativo, usa questo contratto al posto di un semplice SOW.
Fornitore di sviluppo software e agenzie IT usano questo contratto per formalizzare progetti custom, definire specifiche e cicli di approvazione con clienti.
Studi di consulenza IT e system integrator lo utilizzano per concordare sviluppo di soluzioni software tailored e condizioni di licenza.
Istituti bancari e aziende fintech commissionano software personalizzato per trading, rischio, compliance e usano questo contratto per formalizzare l'accordo.
Aziende manifatturiere commissionano software ERP, MES o di gestione produzione; il contratto disciplina sviluppo, collaudi e diritti di licenza.
E-commerce e catene retail commissionano sistemi di gestione ordini, POS o inventory; il contratto regola funzionalità, integrazioni e supporto post-lancio.
Enti pubblici e aziende di servizi (acqua, energia, trasporti) commissionano software di gestione; il contratto garantisce specifiche tecniche e collaudi rigorosi.
Il contratto è redatto secondo la legge italiana ed è adatto a fornitore e cliente entrambi in Italia o residenti nella Comunità Europea. Specifica la provincia italiana applicabile per diritti di proprietà intellettuale e per la competenza dei tribunali (es. Milano, Roma, Torino).
Se fornitore o cliente risiede in Svizzera (Ticino), il contratto rimane usabile ma è consigliabile aggiungere una clausola scelta di legge (diritto italiano o svizzero) e una clausola di competenza territoriale (es. "I tribunali di Lugano hanno competenza"). Considera di far revisionare il contratto da un avvocato ticinese per conformità alle leggi cantonali.
| Percorso | Ideale per | Costo | Tempo |
|---|---|---|---|
| Usa il modello | Progetti software piccoli o medio-piccoli, relazioni di fiducia, timeline stretta, budget limitato per legali. | €0–50 (una tantum per il modello scaricato) | 2–3 ore per compilare campi, allegati e firma digitale |
| Modello + revisione legale | Progetti di media-alta complessità, fornitori o clienti inesperti, giurisdizioni diverse, protezione di proprietà intellettuale critica. | €500–1.500 (modello + revisione legale 2–3 ore) | 3–5 giorni (revisione avvocato + negoziazione clausole) |
| Redatto su misura | Progetti enterprise, software mission-critical, royalties o rinnovi in gioco, clausole molto personalizzate, relazioni multi-anno. | €2.000–5.000+ (redazione da zero, negoziazione, clause legali specializzate) | 1–3 settimane (intake, draft, iterazioni, firma) |
Questo documento è uno dei 3,000+ modelli aziendali e legali inclusi in Business in a Box.
Accedi a oltre 3,000+ modelli aziendali e legali per qualsiasi attività, progetto o iniziativa.
Personalizza il tuo modello di documento aziendale pronto all'uso e salvalo nel cloud.
Condividi i tuoi file e cartelle con il tuo team. Crea uno spazio di collaborazione fluida.
"Idea fantastica! Non so come farei senza. Vale ogni centesimo, e come investimento si è ripagato più volte."
"Ho usato Business in a Box per 4 anni. È stata la fonte di modelli più utile che abbia mai trovato. Lo raccomando a chiunque."
"Mi ha salvato la vita così tante volte che ho perso il conto. Business in a Box mi ha fatto risparmiare tantissimo tempo e, come sapete, il tempo è denaro"
Smetti di scaricare documenti. Inizia a operare con chiarezza. Business in a Box ti offre il sistema operativo aziendale utilizzato da oltre 250.000 aziende in tutto il mondo per strutturare, gestire e far crescere la tua attività.
Inizia gratis · Nessuna carta di credito richiesta
