Modello di contratto di sviluppo software

Modello fac-simile per la redazione di un contratto di sviluppo software, utile per redigere un accordo con il quale un committente - impresa, ente, ecc. - affida ad un fornitore - sviluppatore, programmatore - la progettazione e/o realizzazione di uno o più prodotti informatici, creati “su misura”, in base a sue specifiche esigenze. Compila il nostro modello di contratto di sviluppo software e scarica il tuo contratto personalizzato!
"Servizio interessante. Lo sto sperimentando."
Igor S.
Ultimo
aggiornamento
25/01/2024
Quantità
articoli
fino a 18 artt.
Quantità
pagine
1-2 pagine
Tempo di
compilazione
10 min

QUALE ESIGENZA SODDISFA IL MODELLO DI CONTRATTO DI SVILUPPO SOFTWARE?

Hai necessità di un software personalizzato per la tua azienda e vuoi affidarne la realizzazione ad una società specializzata o ad un professionista del settore?

Il nostro modello di contratto di sviluppo software ti consente di disciplinare ogni aspetto del rapporto contrattuale tra il fornitore (sia programmatore singolo che azienda di sviluppo software) e il committente.

NATURA GIURIDICA DEL CONTRATTO DI SVILUPPO SOFTWARE

Il contratto di sviluppo software è un contratto cd. atipico in quanto non è espressamente disciplinato dalla legge.

Il contenuto del contratto è rimesso sostanzialmente alla volontà delle parti, sempre nel rispetto dei principi generali contenuti nel codice civile in materia di contratti (art. 1323 cod. civ. ss.).

Per tutto ciò che non è espressamente previsto dal contratto si applicheranno le norme che regolano i contratti tipici analoghi o affini, ed in particolare:

  • contratto di appalto (art. 1655 ss. c.c.);
  • contratto di opera intellettuale (art. 2222 ss. c.c.).
 

La differenza tra le due discipline si rinviene principalmente nel tipo di obbligazione che si assume chi sviluppa il programma:

  • obbligazione di risultato nel caso dell’appalto;
  • obbligazione di mezzi nel caso del contratto d’opera intellettuale.

Da ciò deriva un diverso regime delle responsabilità che possono nascere dal contratto:

  • nelle obbligazioni di risultato il conseguimento di un determinato risultato è da ritenersi essenziale per l’interesse e l’aspettativa del creditore;
  • nelle obbligazioni di mezzi il debitore si obbliga a impiegare diligentemente i mezzi a propria disposizione per soddisfare l’interesse del creditore, senza tuttavia impegnarsi a raggiungere un risultato specifico.

Pertanto, la regola di responsabilità fissata nell'art. 1218 c.c. per il caso d'inadempimento varrebbe soltanto per le obbligazioni di risultato, mentre per quelle di mezzi varrebbe il principio della diligenza.

Con riguardo alla realizzazione di un software personalizzato, il mancato raggiungimento del risultato potrebbe derivare non solo dalla difficoltà di impiego pratico del programma, ma anche dalla circostanza che il committente non abbia chiarito quali fossero veramente le sue esigenze.

Per quanto riguarda la presenza di vizi (difetti) del programma è necessario distinguere di nuovo tra contratto di sviluppo assimilabile a contratto di appalto da quello che può essere configurato come prestazione di opera intellettuale.

Nel caso dell’appalto, il fornitore è tenuto alla garanzia per difformità e vizi prevista dagli artt. 1667 e 1668 c.c., in forza dei quali il committente deve denunciare all'appaltatore le difformità e i vizi dell'opera entro 60 giorni dalla scoperta e può esercitare l'azione entro due anni dalla consegna dell'opera. La garanzia non è dovuta se il committente ha accettato l'opera e le difformità o i vizi erano da lui conosciuti o erano riconoscibili, purché in questo caso, non siano stati in malafede taciuti dall'appaltatore.

In presenza di difetti del programma, il committente può:

  • chiedere la risoluzione del contratto, ma solo se i difetti siano tali da renderlo del tutto inadatto alla sua destinazione;
  • pretendere l’eliminazione dei difetti a spese del fornitore;
  • ottenere la riduzione del prezzo;
  • ottenere il risarcimento del danno nel caso di comportamento colposo del fornitore.

Nel caso di contratto d'opera intellettuale, secondo l’art. 2236 c.c., se la prestazione implica la soluzione di problemi tecnici di speciale difficoltà, il prestatore d'opera non risponde dei danni, se non in caso di dolo o di colpa grave.

La responsabilità del professionista sorge se la prestazione oggetto del contratto implichi la soluzione di programmi tecnici di speciale difficoltà e il danno cagionato sia dovuto a dolo o colpa grave.

La limitazione di responsabilità non è applicabile alle ipotesi di negligenza o imprudenza del professionista, salva la diligenza professionale richiesta allo stesso in base all'art. 1176, comma 2, c.c.

Il cliente che intenda agire per ottenere il risarcimento ha l'onere di provare sia il danno subito, sia la colpa del prestatore d'opera intellettuale, sia il nesso di causalità tra colpa e danno, tenuto presente che la diligenza richiesta al professionista è una diligenza qualificata, superiore a quella che viene richiesta ad una persona comune (c.d. diligenza del buon padre di famiglia), ed è collegata alla prestazione che lo stesso deve eseguire.

 

Con il termine software si intende comunemente un programma per computer che permette alla macchina (hardware) di svolgere determinate funzioni.

Giuridicamente parlando il software (o, meglio, il programma per elaboratore) rientra nella categoria dei beni immateriali, tutelabile in astratto sia come opera dell’ingegno che come invenzione brevettabile.

La scelta del legislatore (sia comunitario, sia italiano) è stata quella di inserire il software tra le opere dell’ingegno, protette sia dal Codice Civile (agli artt. 2575 - 2583 c.c.) sia dalla legge sul diritto d’autore (l. 22 aprile 1941, n. 633).

La legge sul diritto d’autore (l. n. 633/1941), modificata dalla Direttiva 91/250/CEE contiene alcune norme specifiche sul software.

In particolare l’art. 2 della legge sul diritto d’autore indica ora tra le opere tutelate dal diritto d’autore “i programmi per elaboratore, in qualsiasi forma espressi purché originali quale risultato di creazione intellettuale dell’autore” e precisa che restano esclusi dalla tutela accordata dalla presente legge le idee e i principi che stanno alla base di qualsiasi elemento di un programma, compresi quelli alla base delle sue interfacce. Secondo la medesima norma, il termine programma comprende anche il materiale preparatorio per la progettazione del programma stesso.

 

Così la giurisprudenza ha affermato che dalla definizione normativa discende che, “relativamente al software, non ne risultano protetti né lo scopo, inteso come il fine che si propone (nel suo complesso e nei suoi moduli), né gli algoritmi matematici che implementano le funzioni che il programma deve compiere, né la flowchart, che descrive ad un livello di dettaglio le modalità con cui le diverse parti interagiscono tra loro; per contro, trovano sicuramente protezione sia il codice sorgente, ovverosia l'insieme dei passaggi e comandi predisposti dall'autore in una forma espressa costituita da un linguaggio comprensibile all'uomo, sia il c.d. codice oggetto, ovvero la traduzione del codice sorgente nel linguaggio macchina (il quale, pur non essendo espressione comprensibile all'uomo, rientra nella tutela di cui al richiamato art. 2 n. 8 della Legge sul diritto d’autore in virtù del riferimento testuale “in qualsiasi forma espressi”).

Il software è tutelato solo se sia originale, in quanto frutto di elaborazione creativa rispetto a programmi precedenti.

 

La legge attribuisce all’autore del software diritti esclusivi, che vengono acquisiti in modo automatico con il semplice fatto della creazione dell’opera.

Si distingue tra:

a) diritto morale d’autore che è personale e quindi non trasmissibile e che dura fino a 70 anni dopo la morte dell’autore;

b) diritto patrimoniale ovvero il diritto allo sfruttamento economico.

In via generale rientrano tra i diritti d’autore il diritto di effettuare o autorizzare:

• la riproduzione del programma, permanente e temporanea;

• la sua modifica;

• qualsiasi forma di distribuzione al pubblico.

 

Nell’ipotesi specifica del software posto che la riproduzione comprende sia la duplicazione che il caricamento, qualsiasi utilizzazione va autorizzata.

Così sono soggette all’autorizzazione del titolare dei diritti sul software anche il caricamento, la visualizzazione, l’esecuzione, la trasmissione o la memorizzazione, se comportano una riproduzione del programma (art. 64 bis, lett. a, Legge sul diritto d’autore).

Sono, inoltre, riservate la traduzione, l’adattamento, la trasformazione e ogni altra modificazione del software, nonché la riproduzione dell’opera che ne risulti.

La modifica a un programma preesistente non è consentita all’utilizzatore del software senza il consenso dell’autore, secondo quanto disposto dall’art. 64 bis, lett. b). Spetta inoltre all’autore qualsiasi forma di distribuzione al pubblico.

Non è invece necessaria l’autorizzazione per quelle attività necessarie per l’uso, oppure se la riproduzione del codice del programma e la traduzione della sua forma siano indispensabili per conseguirne l’interoperabilità con altri programmi, nel rispetto dei termini indicati dall’art. 64 quater Legge sul diritto d’autore.

Nel caso in cui l’autore sia un lavoratore dipendente, i diritti di utilizzazione economica del software spettano al datore di lavoro, a meno che non sia diversamente pattuito.

Per quanto riguarda il software che sia il risultato della riunione di più programmi o parti di essi come nel caso in cui il software realizzato combini programmi e parti di altri programmi preesistenti, adattati e collegati tra loro, il titolare del diritto è chi organizza l’opera compiendo un’attività di scelta, coordinamento e direzione della creazione (art. 7 Legge sul diritto d’autore).

Se il software nasce da un lavoro di gruppo in cui è impossibile individuare il contributo dei singoli programmatori si applica l’art.10 Legge sul diritto d’autore, in base al quale la titolarità del diritto morale e patrimoniale sul programma è in comunione tra i co-autori.

 

Se è vero che i diritti d’autore sul software nascono con la creazione stessa del programma senza che sia necessario procedere al deposito di speciali domande, il deposito del software presso la SIAE agevola l’autore nella prova della paternità e della data di creazione di un determinato programma.

Se il programma è pubblicato è possibile procedere con la registrazione presso il Registro pubblico del software tenuto dalla SIAE, se invece il software non sia stato pubblicato si può procedere con un normale deposito di opera inedita.

Nel Pubblico Registro per il Software possono essere registrati tutti i programmi per computer pubblicati che rispettino requisiti di originalità e creatività tali da poter essere identificati come opere dell’ingegno e tutti gli atti che trasferiscono in tutto o in parte i diritti di utilizzazione economica relativi a programmi per i quali sia già avvenuta la registrazione.

Per quanto riguarda la tutela brevettuale, il software non può essere brevettato “in quanto tale”.

Secondo la giurisprudenza che si è formata sull’art. 52 European Patent Convention, i programmi per computer possono essere brevettati quando abbiano “technical character”.

Il software non può essere considerato provvisto di carattere tecnico per il solo fatto di essere in grado di comandare un hardware.

Per essere brevettabile deve quindi presentare un ulteriore effetto tecnico (“further technical effect”) che può essere riscontrato sia all’esterno del computer su cui è caricato il software, sia all’interno del computer stesso.

Quello che viene brevettato è quindi l’algoritmo, il metodo alla base del programma, non il suo codice sorgente o oggetto, che può anche non essere stato ancora creato ed è del tutto indifferente il linguaggio in cui sarà redatto. Il codice sorgente ed i listati in ogni caso anche se esistenti, non devono essere depositati con la domanda di brevetto perché possono solo costituire oggetto di tutela secondo la legge sul diritto d’autore.

Da tutto quanto sopra esposto, emerge che l’attribuzione dei diritti di proprietà intellettuale sul software costituisce un aspetto critico di questa tipologia di contratto.

Nell’ipotesi del contratto di sviluppo software in linea generale il diritto morale resta sempre in capo allo sviluppatore o alla software house che mantiene il diritto a essere riconosciuto autore del programma.

Se non è disposto diversamente, invece, si ritiene che il diritto di sfruttamento economico del software realizzato vada al committente, che ne acquista la proprietà.

Ad ogni modo, è preferibile che nel contratto sia specificato in modo chiaro a chi spetti la titolarità dei diritti di utilizzazione economica sul programma, con particolare riferimento al codice sorgente dello stesso.

È dunque necessario stabilire in modo chiaro se il software sviluppato sia concesso in licenza o ceduto. Se la licenza sia esclusiva oppure non esclusiva e sia o meno circoscritta a un determinato territorio o ambito di utilizzo.

Nella diversa ipotesi di cessione il committente diventa proprietario del software e di tutti i diritti di sfruttamento economico (mai dei diritti morali).

È consigliabile, se del caso, regolamentare anche lo scambio del know-how tra committente e programmatore. Il committente potrebbe infatti essere interessato a mantenere all’interno della propria azienda alcune informazioni tecniche, organizzative o di processo che ha dovuto scambiare con il programmatore e che costituiscono un know-how aziendale con un valore economico anche rilevante.

Nel testo del modello di contratto di sviluppo software andrà disciplinato l’ambito entro il quale è consentito allo sviluppatore di riutilizzare le competenze acquisite per fornire prodotti o servizi uguali o simili, magari alla concorrenza.

È necessario inoltre stabilire se lo sviluppo dell’applicazione comprenda anche la realizzazione del materiale di supporto tecnico.

Nel contratto è inoltre opportuno specificare se la realizzazione del software comprenda o meno variazioni in corso d’opera e/o il rilascio di versioni di intermedie.

DISCIPLINA GIURIDICA DEL CONTRATTO DI SVILUPPO SOFTWARE

TIPOLOGIE DI CONTRATTO DI SVILUPPO SOFTWARE

Le differenze tra i vari tipi di contratto di sviluppo software si rinvengono principalmente nella gestione dei diritti di proprietà intellettuale. In particolare, è importante individuare chi sarà titolare del codice sorgente.

In un primo tipo di contratto, il Fornitore cederà al Committente il massimo del valore del programma. In questo caso, il Fornitore consegnerà al Committente il codice sorgente insieme alla documentazione tecnica e gli attribuirà il diritto di usare il software senza porre alcuna limitazione nelle modalità di utilizzo.

Una seconda possibilità, invece, permette di contemperare le opposte esigenze: da un lato si lascia allo sviluppatore la titolarità del codice sorgente e la possibilità di sfruttarlo economicamente, dall’altro lato, si consente al Committente di disporre del codice stesso per eventuali modifiche ed estensioni, ma stabilendo un impegno ad un utilizzo esclusivamente interno del software e delle eventuali modifiche ed estensioni.

Nel caso in cui, invece, il Committente non abbia interesse a modificare e/o estendere il software che ha ricevuto, ma voglia assicurarsi che non venga ceduto anche ad altri clienti del Fornitore, con i quali compete sul mercato, si potrebbe prevedere che la titolarità del codice sorgente rimanga in capo al Fornitore, ma lo stesso non possa vendere (o comunque cedere in licenza d’uso) lo stesso software ad altri clienti, suoi concorrenti.

Infine, un’ultima ipotesi, più particolare e specifica, prevede che pur rimanendo in capo al Fornitore la titolarità del codice sorgente, si decida di affidarlo ad un terzo soggetto affinché il Committente che in futuro dovesse avere necessità di eseguire operazioni di manutenzione possa farlo anche se, nel frattempo, si sono verificate circostanze che comprometterebbero tale possibilità, quali, ad esempio, il fallimento o la cessazione dell’impresa dell’appaltatore.

Per far ciò sarà necessario stipulare un apposito contratto di deposito (c.d. contratto di “deposito del codice sorgente”, in lingua anglosassone “ software escrow”), tra i contraenti del contratto di sviluppo e il terzo che si impegna, presumibilmente verso un corrispettivo,alla custodia del codice per un periodo che viene stabilito nel contratto stesso, decorso il quale il terzo dovrà distruggere il codice.

FIGURE AFFINI AL CONTRATTO DI SVILUPPO SOFTWARE

Come visto, il contratto di sviluppo software presenta molte caratteristiche simili al contratto di appalto (art. 1655 ss. c.c.) e al contratto di opera intellettuale (art. 2222 ss. c.c.).

Ai sensi dell’art. 1655 c.c. “l’appalto è il contratto con il quale una parte assume, con organizzazione dei mezzi necessari e con gestione a proprio rischio, il compimento di un’opera o di un servizio verso un corrispettivo in danaro”.

Il contratto di opera intellettuale sia ha, invece, secondo il disposto dell’art. 2222 c.c. quando una persona si obbliga a compiere verso un corrispettivo un'opera o un servizio, con lavoro prevalentemente proprio e senza vincolo di subordinazione nei confronti del committente.

La differenza tra le due discipline si rinviene principalmente nel tipo di obbligazione che si assume chi sviluppa il programma:

  • obbligazione di risultato nel caso dell’appalto;
  • obbligazione di mezzi nel caso del contratto d’opera intellettuale.

Da ciò deriva un diverso regime delle responsabilità che possono nascere dal contratto:

  • nelle obbligazioni di risultato il conseguimento di un determinato risultato è da ritenersi essenziale per l’interesse e l’aspettativa del creditore;
  • nelle obbligazioni di mezzi il debitore si obbliga a impiegare diligentemente i mezzi a propria disposizione per soddisfare l’interesse del creditore, senza tuttavia impegnarsi a raggiungere un risultato specifico.

Pertanto, la regola di responsabilità fissata nell'art. 1218 c.c. per il caso d'inadempimento varrebbe soltanto per le obbligazioni di risultato, mentre per quelle di mezzi varrebbe il principio della diligenza.

FORMALITÀ

È fortemente raccomandabile la forma scritta per il contratto di sviluppo software.

É opportuno far precedere la firma del contratto di sviluppo software da una fase di progettazione che si concluda con uno studio di fattibilità o un documento di analisi dei requisiti che serve a indicare le specifiche condivise e concordate tra le parti e dove saranno:

  • esplicitate le funzionalità richieste dal committente e i mezzi che quest’ultimo intende mettere a disposizione per realizzare i propri scopi;
  • indicate le specifiche funzionali del software da realizzare, i tempi, i costi e il piano dei test di accettazione.

Nello studio di fattibilità/documento di analisi sui requisiti funzionali è quindi opportuno includere:

  • la descrizione delle funzionalità richieste;
  • la descrizione del contesto (vincoli) hardware e software;
  • una stima dei tempi di realizzazione e dei costi;
  • gli obiettivi e modalità di collaudo;
  • la definizione delle attività a carico del cliente.

Il Piano di lavoro che verrà allegato al modello di contratto di sviluppo software incorporerà, nel caso specificandolo, lo studio di fattibilità/documento di analisi.

Nel Piano di lavoro il committente dovrà esplicitare al fornitore le specifiche esigenze che intende soddisfare con il software commissionato, ossia gli obiettivi che intende raggiungere, prima ancora di decidere le specifiche funzionali del software da realizzare.

Il piano di lavoro ha quindi lo scopo di definire in modo preciso:

  • la prestazione oggetto del contratto che il fornitore si impegna a svolgere;
  • il risultato che il fornitore è obbligato a realizzare;
  • i tempi e i costi di sviluppo del software (ed eventualmente le tranche di pagamento);
  • le specifiche tecniche (l’ambiente informatico; l’hardware sul quale si dovrà procedere all’installazione e/o alla configurazione del software; il software di ambiente, i sistemi operativi, il database management system e qualunque software, già presente e non oggetto del contratto di sviluppo, con il quale il software commissionato dovrà interagire);
  • i requisiti di prestazione del software da sviluppare;
  • le specifiche funzionali;
  • la procedura di accettazione e relativi test da utilizzare nella verifica finale e nelle eventuali verifiche intermedie con descrizione sia delle modalità con le quali il software consegnato per la verifica (c.d. collaudo) dovrà essere testato, sia il comportamento atteso nella procedura di verifica;
  • le risorse che il committente dovrà mettere a disposizione nel corso dell’esecuzione del contratto (risorse umane o anche materiali).

Oltre all’allegato che contiene il Piano di lavoro, è da valutare caso per caso l’opportunità di prevedere anche altri allegati che si occupino nel dettaglio del piano di esecuzione, del deposito del codice sorgente, dell’accordo di manutenzione, della tabella costi del materiale e tempo di utilizzo del computer (in caso di pagamento cd. time and material) e di eventuali servizi aggiuntivi.

Riassumendo, prima della conclusione del contratto di sviluppo le parti dovrebbero avere chiarito i seguenti aspetti (da inserire nel Piano di lavoro o in un Documento dei requisiti apposito da allegare al contratto insieme al Piano di Lavoro):

  • quali siano le caratteristiche funzionali delle macchine nelle quali il software dovrà essere impiegato, oltre che le condizioni e modalità di utilizzo dello stesso per cui il software deve essere idoneo (ad esempio, tempi di esercizio continuativo, quantità di dati da gestire);
  • le singole funzioni che il software deve realizzare o contribuire a realizzare;
  • i requisiti richiesti con riferimento a ciascuna funzione del software (ad esempio livelli minimi di prestazione, vincoli sui tempi di risposta, tolleranze);
  • le caratteristiche dell’ambiente informatico (hardware) sul quale si procederà a installare e/o configurare il software (le apparecchiature meccaniche, elettroniche o di qualsiasi altro genere, il sistema operativo, il database management system, le connessioni di rete), con indicazione delle specifiche versioni dei singoli componenti del sistema che il Committente intende utilizzare;
  • qualunque software, che non sia oggetto del contratto di sviluppo, con il quale il software da realizzare dovrà interagire.