Premessa

Contratto-tipo di sviluppo del software con clausole standard commentate

Premessa

I contratti relativi al software si caratterizzano per l’elevata complessità della loro redazione, dovuta sia all’assenza di una disciplina legislativa che regoli specificamente i contratti con questo oggetto, al pari di altri contratti, sia alla natura giuridica del tutto particolare del software.

Proprio la considerazione delle difficoltà che gli operatori del settore ICT e i loro clienti incontrano nel regolare contrattualmente i loro rapporti è alla base del lavoro svolto in questo ambito dalla Camera di Commercio di Torino: l’accertamento degli usi della Provincia di Torino nel mercato dell’informatica (v. Tit. VII, capitolo XIII, della raccolta provinciale riferita al 2000-2005), la programmazione di numerosi seminari, svoltisi nel biennio 2008/2009, dedicati all’analisi degli aspetti più problematici della negoziazione e redazione dei contratti a oggetto informatico e, da ultimo, la predisposizione di clausole-tipo di uno dei più diffusi contratti a oggetto informatico, il contratto di sviluppo software.

Con l’espressione “sviluppo di un software” si fa riferimento alle attività di progettazione e realizzazione di un programma informatico: un soggetto – che nelle clausole è indicato con il termine di “Committente” – si rivolge a una impresa informatica – denominata nelle clausole “Fornitore” – perché gli crei un programma atto a soddisfare le sue esigenze aziendali. Il contratto che i due stipulano nella prassi prende il nome di “contratto di sviluppo software”. Dopo una breve introduzione dedicata all’inquadramento giuridico di tale contratto, nel presente lavoro si propongono alcune clausole-tipo per la sua redazione.

Le clausole riguardano solo taluni, sia pure tra i più rilevanti, degli aspetti del rapporto contrattuale e pertanto non costituiscono, nel loro insieme, un contratto completo, ma anzi si prestano a essere inserite anche singolarmente all’interno del testo contrattuale predisposto dai contraenti.

È opportuno però evidenziare che qualora si utilizzi la singola clausola-tipo per regolare un aspetto del proprio rapporto contrattuale, dovrà essere prestata la massima attenzione a come la stessa si inserisce nel contratto globalmente considerato, vale a dire alla sua coerenza con il resto del regolamento contrattuale che le parti si accingono a sottoscrivere. E questo perché una regola fondamentale di interpretazione del contratto, che il giudice applicherà nel caso in cui tra i contraenti sorga una controversia relativa all’esecuzione degli obblighi derivanti dal contratto stesso, è quella per cui «Le clausole del contratto si interpretano le une per mezzo delle altre, attribuendo a ciascuna il senso che risulta dal complesso dell’atto» (art. 1363 del Codice civile).

Ciascuna clausola-tipo è accompagnata da un breve commento che mira a consentirne una migliore comprensione e a dar conto, in sintesi, delle opinioni espresse in sede di discussione da parte degli operatori del settore e degli studiosi che hanno partecipato ai Tavoli di lavoro dai quali le clausole- tipo scaturiscono.

1. Il contratto di sviluppo software

1.1. Come è tutelato il software?

La specifica tutela normativa del software risale al 1993, anno in cui è entrato in vigore il d. lgs. 29 dicembre 1992, n. 518, che ha dato attuazione in Italia alla direttiva comunitaria 90/250/CEE.

Il software (o meglio, il programma per elaboratore elettronico, come viene definito dal legislatore) ha trovato riconoscimento normativo all’interno della legge sul diritto d’autore (legge 22 aprile 1941, n. 633), che lo qualifica come opera dell’ingegno di carattere creativo, alla stregua

delle opere che appartengono alla letteratura, alla musica, alle arti figurative, all’architettura ed alla cinematografia.

La disciplina legislativa riguarda i diritti esclusivi di sfruttamento economico riservati al titolare del diritto d’autore sul programma e le (limitate) facoltà riconosciute al legittimo utilizzatore (artt. 64 bis, 64 ter e 64 quater, inseriti nell’apposita sezione VI, del Capo IV, Titolo I della legge 633/1941). Ulteriori norme completano la disciplina; fra queste, specifiche sanzioni penali per l’ipotesi di duplicazione abusiva del programma: art. 171 bis.

La legge non contiene disposizioni che definiscono e regolamentano le operazioni contrattuali con cui, nella prassi, il software viene commissionato, venduto, o dato in licenza. Il legislatore ha regolato unicamente l’ipotesi del software creato dal «lavoratore subordinato nell’ambito delle mansioni assegnategli o su istruzioni impartitegli dal datore di lavoro», stabilendo che a quest’ultimo spetta la titolarità del diritto esclusivo di utilizzazione economica del programma realizzato dal proprio dipendente, salvo che le parti si siano accordate diversamente (v. art. 12 bis legge 633/1941).

1.2. Il contratto di sviluppo software

Con l’espressione “contratto di sviluppo software” si fa riferimento all’accordo che ha a oggetto il

custommade software, ossia il programma informatico fatto “su misura”.

Un soggetto si rivolge a un’impresa (o a un lavoratore autonomo) perché questa progetti e realizzi un software con caratteristiche funzionali tali da soddisfare le sue particolari esigenze (come, ad esempio, l’informatizzazione della contabilità di un’impresa o della gestione del magazzino).

Il contratto di sviluppo, dunque, è ben diverso da quello dell’acquisto di un software standard, venduto attraverso i canali della grande distribuzione, perché l’utente non acquista un prodotto già esistente sul mercato, ma dà incarico di “redigere” uno specifico programma adatto alle sue necessità e per mezzo del quale intende procedere all’informatizzazione dell’intera sua attività o di una fase di essa.

L’attività che conduce allo sviluppo di un software può essere scomposta in due fasi. La prima fase è quella di progettazione (usualmente definita «studio di fattibilità»), che partendo dai requisiti posti dal committente, cioè dagli obiettivi che intende conseguire e dai mezzi che intende mettere a disposizione a questo scopo, sfocia in un documento nel quale sono indicate le specifiche funzionali del software da realizzare, le condizioni che esso deve soddisfare, i tempi e il costo della realizzazione e, infine, il piano dei test di accettazione.

La seconda fase è, invece, quella propriamente esecutiva del software progettato. Le due fasi in questione – progettazione e realizzazione – potrebbero essere oggetto di due contratti separati (analogamente a quanto avviene, ad esempio, nel campo delle costruzioni edili, ove sono nettamente distinte la fase progettuale, affidata al progettista, e quella di esecuzione, affidata invece all’impresa appaltatrice dei lavori).

Nella prassi però non è usuale, se non per le operazioni di elevato valore economico, stipulare due distinti contratti.

Al contrario, il committente solitamente si rivolge a un’impresa informatica affidandole, con un unico contratto, sia la progettazione sia la realizzazione del software.

Tenendo conto di questo dato, nel presente lavoro si è preferito procedere alla stesura di due versioni, tra loro alternative, della clausola che individua l’oggetto del contratto: x. xxxxxxxx 0, xxxxxxx x) / x).

1.3. Quali sono i più frequenti motivi di contenzioso?

Le liti che più frequentemente scaturiscono dai contratti di sviluppo software riguardano i seguenti aspetti:

• le modalità e i criteri da applicare per lo svolgimento della verifica, ossia del c.d. collaudo

• il tipo di impegno assunto da parte del fornitore: spesso, in pratica, non è chiaro se questi si è obbligato a raggiungere un “risultato”, cioè a realizzare un programma che effettivamente risponda a quelle che il cliente ha dichiarato essere le sue esigenze, oppure se egli si impegni a elaborare un software nel rispetto delle regole dell’arte, ma senza garantire il conseguimento del risultato che il cliente si proponeva,

• entro quali limiti il fornitore è responsabile per i vizi e/o malfunzionamenti del software sviluppato,

• se il corrispettivo pattuito include o meno eventuali modifiche del software a richiesta del committente,

• a chi spetta la titolarità del diritto d’autore sul programma (e in particolare, dei relativi diritti di sfruttamento commerciale) e, inoltre, se il cliente possa o meno ottenere il godimento del software in esclusiva, limitandone la commercializzazione da parte del fornitore a eventuali concorrenti. Occorre prestare attenzione a un fatto particolare. Tradizionalmente si distingue tra obbligazioni “di risultato”, che ricorrono quando un soggetto si impegna a svolgere un’attività e a realizzare il risultato concordato, e obbligazioni “di mezzi”, nelle quali non vi è l’obbligo di raggiungere un risultato, ma il debitore è tenuto unicamente a svolgere la prestazione con la diligenza dovuta (v. art. 1176 c.c.).

Tipicamente “di risultato” è l’obbligazione dell’appaltatore che non avrà diritto al pagamento del prezzo pattuito se l’opera commissionata non è realizzata, anche se la mancata realizzazione non è dipesa da sua negligenza.

Tipicamente “di mezzi” è invece l’obbligazione dell’avvocato, che è obbligato a impiegare la sua diligenza professionale per curare gli interessi del suo cliente, ma ha diritto al pagamento del suo onorario anche se il cliente perderà la causa.

Queste sono le principali cause di controversia:

a) scarsa informazione reciproca nella fase delle trattative

b) mancanza di uno studio preliminare di fattibilità, ossia di un vero e proprio progetto

c) definizione incerta e imprecisa della prestazione che il fornitore si è impegnato a svolgere e del risultato che è obbligato a realizzare

d) mancanza di un contratto scritto che attesti il contenuto degli accordi delle parti e contenga, in particolare, un piano di lavoro dettagliato, ove siano illustrati le modalità e i tempi di realizzazione del software.

1.4. Quali norme di legge si applicano in caso di contenzioso?

La presenza di un contratto scritto è tanto più importante in quanto, per risolvere le questioni sopra elencate non è possibile fare riferimento a una specifica disciplina legislativa: infatti, non esistono nel nostro ordinamento giuridico norme dettate appositamente per il “contratto di sviluppo software” e perciò le regole di riferimento che il giudice applicherà in caso di controversia saranno innanzitutto quelle che le parti stesse hanno pattuito. In mancanza di accordi specifici tra i contraenti, o nel caso non si riescano a provare gli accordi intercorsi (ad esempio, perché le parti non abbiano un contratto scritto o questo non tratti in modo esauriente tutti gli aspetti del rapporto) il giudice applicherà le disposizioni che la legge stabilisce per il contratto assimilabile a quello in questione, vale a dire le norme del Codice civile relative al contratto d’appalto (artt. 1655 e seguenti), oppure, nel caso il fornitore sia un lavoratore autonomo o piccolo imprenditore, quelle relative al contratto d’opera (art. 2222 ss.).

Si tenga presente che, se le parti non vogliono che trovi applicazione una determinata disposizione normativa, devono esplicitarlo nel contratto, prevedendo espressamente una regola diversa per il loro rapporto.

Infatti, l’art. 1374 del Codice civile stabilisce che: «Il contratto obbliga le parti non solo a quanto è nel medesimo espresso, ma anche a tutte le conseguenze che ne derivano, secondo la legge o, in mancanza, secondo gli usi e l’equità». Ciò significa che se il contratto è incompleto e le parti non riescono ad accordarsi su una soluzione accettabile per entrambe nel momento in cui, durante

l’esecuzione del contratto, si manifesta la carenza di regolamentazione di un determinato aspetto del rapporto, il contratto verrà a essere integrato (generalmente in giudizio) dalle disposizioni del Codice civile (o di leggi speciali, se ve ne sono sulla materia) e in mancanza anche di queste dagli usi, ovvero, se non vi sono neppure usi sul punto controverso, dall’equità.

1.5. Che cos’è la clausola penale e quale ruolo può rivestire all’interno del contratto di sviluppo software?

Il Codice civile definisce clausola penale quella con cui, in un qualsiasi contratto, si stabilisce che, in caso di inadempimento o di ritardo nell’adempimento di uno dei contraenti, questi è tenuto a una determinata prestazione (che, di regola, consiste nel pagamento di una certa somma di denaro a favore dell’altro contraente: art.1382).

La clausola evita, alla parte che subisce l’inadempimento, di dover provare in giudizio il danno subito e le garantisce il diritto al pagamento della somma pattuita come penale anche se il danno effettivamente patito è minore, o addirittura anche se non vi è stato alcun danno.

Nel contempo la penale gioca un ruolo importante a vantaggio del debitore: essa ha, infatti, l’effetto di limitare il risarcimento del danno causato all’altra parte con il suo inadempimento all’importo fissato come penale (sempre che non sia stata pattuita la risarcibilità del danno ulteriore, del quale però il creditore dovrà dare piena prova, cosa questa non sempre facile).

Nel determinare l’ammontare della penale le parti devono considerare una regola molto importante: il Codice civile stabilisce che tale ammontare può essere ridotto dal giudice qualora sia ritenuto

«manifestamente eccessivo avuto riguardo all’interesse che il creditore aveva all’adempimento» (art. 1384).

Il principale problema che si pone nel determinare il contenuto della clausola penale è dato dalla necessità di calcolare la misura del risarcimento efficiente: ciò presuppone che la parte a favore della quale la penale è prevista abbia ben chiara l’entità del danno che le deriverebbe dal ritardo nell’adempimento o dall’inadempimento definitivo.

Le ipotesi per le quali può essere opportuno inserire una penale nel contratto in esame sono le seguenti:

• ritardo nella consegna

• mancato superamento della verifica finale.

Si propone qui di seguito una possibile versione della clausola penale studiata dagli esperti che hanno elaborato le clausole-tipo: si tratta di una clausola complessa, che tiene conto delle considerazioni sopra indicate (al fine di illustrare al meglio il funzionamento della seguente clausola sono stati inseriti dei valori meramente indicativi).

1. Nel caso di mancato rispetto del termine indicato per la consegna come specificato nel Piano di Lavoro è applicata una penale commisurata all’importo contrattuale1: essa è calcolata come una percentuale dell’importo contrattuale pari al rapporto tra i giorni di ritardo e la durata, espressa in giorni, prevista per l’esecuzione della prestazione del Fornitore2. Per il calcolo dei giorni di ritardo il termine iniziale coincide con il giorno in cui il software sarebbe dovuto essere a disposizione del Committente per l’espletamento del collaudo.

2. Nell’ipotesi in cui il software non superi positivamente il collaudo, la consegna si considera come non avvenuta; in questo caso, ai fini del calcolo del ritardo per la penale, non si considera il periodo intercorso tra la messa a disposizione del software per l’espletamento del collaudo e la comunicazione, da parte del Committente, del suo mancato superamento dello stesso.

3. L’esito negativo di ciascun collaudo comporta, comunque, l’applicazione di una penale pari al 5% dell’importo contrattuale3, che potrà essere riassorbita dalla penale complessiva maturata a causa del ritardo (ove la penale complessiva sia maggiore delle penali maturate a causa di mancata accettazione).

4. Il Committente ha facoltà di procedere alla risoluzione del contratto qualora la penale raggiunga un importo pari al 10% dell’importo contrattuale4.

5. L’ammontare della penale, in ogni caso, non può essere superiore al 60% del corrispettivo pattuito per il contratto5.

1. La penale potrà essere applicata sul ritardo rispetto al termine finale o sul ritardo rispetto agli eventuali stati di avanzamento pattuiti: in tale ultimo caso, il calcolo della penale dovrà essere parametrato all’importo contrattuale relativo allo stato di avanzamento oggetto del ritardo. Con l’espressione “importo contrattuale” si intende il corrispettivo complessivamente dovuto dal Committente in caso di corretta esecuzione del contratto.

2. Ad esempio, se l’importo per la fornitura ammonta a 400.000 euro e la durata concordata per l’attività di sviluppo è pari a 120 giorni, nel caso di un ritardo nella consegna di 30 giorni, il ritardo espresso in percentuale risulta del 25% e dunque la penale ammonta a 100.000 euro. È opportuno indicare nel contratto un esempio di applicazione della penale.

3. Questa penale è prevista al fine di scongiurare comportamenti in mala fede da parte del Fornitore, il quale, per evitare la penale dovuta per il ritardo, potrebbe consegnare comunque nel termine pattuito pur sapendo che l’adempimento non è corretto. La penale dovuta – pari al 5% – è da intendersi dunque legata a una consegna inesatta, ma dal momento che nella clausola del collaudo si stabilisce che in caso di mancato superamento (del collaudo) il Fornitore procede all’eliminazione dei difetti senza assegnazione di alcun termine ulteriore, egli maturerà inevitabilmente anche un ritardo nella consegna. La seconda consegna, inevitabilmente tardiva rispetto al termine iniziale, implicherà l’applicazione della penale da ritardo come indicata nel punto 1 della clausola: ma dall’importo della penale per il ritardo andrà sottratto l’importo già corrisposto del 5%. Ad esempio, nel caso di un software da consegnare in 10 giorni, per 1.000 euro, se il fornitore consegna il 10° giorno, ma il software non supera il collaudo (che per semplicità ipotizziamo effettuabile nel giorno stesso della consegna), è dovuta una penale pari a 50 euro; se al 13° giorno viene consegnata la versione corretta il fornitore è tenuto a corrispondere a titolo di penale, per il ritardo, ulteriori 250 euro.

4. Dopo una serie di tentativi di verifica finale falliti, la clausola conferisce al Committente il potere di risolvere il contratto.

5. La penale non può superare un determinato ammontare calcolato in percentuale sull’importo contrattuale complessivo: ciò al fine di evitare che il ritardo possa dare luogo a comportamenti opportunistici del Committente che potrebbe avere interesse a far lievitare la somma dovuta dal Fornitore a titolo di penale per ritardi, o plurimi insuccessi nelle verifiche finali (ad esempio, se è convenuta una penale di 1000 euro per ogni giorno di ritardo nella consegna dell’opera, non è ammissibile che il Committente lucri sul passare del tempo per cumulare una penale astronomica, anche quando è chiaro che l’opera non gli verrà mai consegnata).

1.6. La clausola di mediazione

La conciliazione è uno strumento alternativo per la risoluzione delle controversie, nel quale un soggettoterzo e imparziale, il mediatore, aiuta le parti a raggiungere una soluzione efficace.

Lo scopo della mediazione non è stabilire chi ha ragione o torto, ma risolvere il conflitto, trovando una soluzione che soddisfi gli interessi delle parti.

Si tratta di una procedura volontaria, per la quale è fondamentale la volontà di partecipare al procedimento di tutte le parti coinvolte nella lite; riservata, poiché le parti, il mediatore e chiunque interviene nel procedimento non possono rivelare le informazioni emerse nel corso della procedura; imparziale, in quanto il mediatore, che aiuta le parti a individuare una soluzione condivisa, è terzo e neutrale rispetto alle stesse.

Tutte le controversie nascenti dal presente contratto verranno deferite a un tentativo di conciliazione presso l’Organismo di mediazione delle Camere di Commercio di ………………….e risolte secondo il Regolamento da questa adottato.

Diagramma delle clausole

Clausola-tipo 1

Oggetto del contratto

1. Il Committente si impegna a esplicitare al Fornitore le specifiche esigenze che intende soddisfare con il software da realizzare, ossia gli obiettivi che intende realizzare. A tal fine il Committente redige in collaborazione con il Fornitore un apposito documento, il Documento dei requisiti, dal quale devono risultare tutte le informazioni utili affinché il Fornitore comprenda in dettaglio le sue necessità.

Il Documento dei requisiti deve illustrare:

a) gli intendimenti e obiettivi che il Committente vuole raggiungere con il realizzando software;

b) i requisiti di prestazione che, per il Committente, il realizzando software dovrà soddisfare;

c) il software di ambiente, i sistemi operativi, il database management system e qualunque software

– non oggetto della fornitura – con il quale il realizzando software dovrà interagire;

d) l’ambiente informatico e cioè l’hardware sul quale si dovrà procedere all’installazione e/o alla configurazione del realizzando software;

e) il termine entro il quale il Committente ha necessità di ottenere il software.

Le parti, al momento della consegna del Documento dei requisiti, si scambiano reciprocamente i rispettivi indirizzi di posta elettronica, da utilizzarsi quale mezzo di comunicazione tra le parti in tutti i casi in cui il contratto non preveda mezzi di comunicazione diversi dalla posta elettronica. Con lo stesso mezzo il ricevente è tenuto a dare riscontro al mittente dell’avvenuta ricezione della mail.

2. Il Fornitore si impegna ad assistere e affiancare il Committente nella comprensione delle sue esigenze e nell’individuazione delle soluzioni più opportune per soddisfarle; si obbliga, inoltre, a mettere a disposizione del Committente il proprio know-how e le proprie competenze tecniche per la stesura del Piano di lavoro (di cui al punto 3. che segue), sulla base degli obiettivi individuati nel Documento dei requisiti.

3. A conclusione della fase preliminare il Fornitore consegna e illustra al Committente il Piano di lavoro del realizzando software, nel quale sono precisati:

- i tempi e i costi di sviluppo del software;

- le specifiche tecniche del medesimo;

- la procedura di accettazione da utilizzare nella verifica finale e in quelle intermedie;

- le risorse che il Committente dovrà mettere a disposizione del Fornitore nel corso dell’esecuzione del contratto.

Il Fornitore è tenuto a consegnare il Piano di lavoro (su supporto cartaceo ed elettronico) al Committente entro e non oltre giorni/mesi dalla stipula del presente contratto.

4. Esaminato il Piano di lavoro il Committente ha la facoltà di recedere dal contratto. Il recesso deve essere comunicato al Fornitore in forma scritta (con racc. a/r) e deve pervenire a quest’ultimo entro e non oltre ……….. giorni dal ricevimento del Piano di lavoro. Qualora si avvalga della facoltà di recedere, il Committente è tenuto a corrispondere al Fornitore una somma pari a euro e può trattenere il Piano di Lavoro consegnato e disporne a suo piacimento.

Clausola-tipo 2

Responsabilità del Fornitore

1. Il Fornitore è responsabile della conformità del software realizzato alle specifiche tecniche e funzionali come precisate nel Piano di lavoro.

2. Il Fornitore si impegna a operare con professionalità nell’esecuzione della propria attività di sviluppo e a mettere a disposizione del Committente le proprie risorse umane e tecniche, garantendo la competenza nonché la professionalità propria e dei propri dipendenti e collaboratori.

Clausola-tipo 3

Rilascio versioni intermedie

Nell’ipotesi di rilascio di versione intermedie e/o parziali del software il Committente può procedere alla loro verifica ed è tenuto al pagamento di acconti secondo le modalità previste nel Piano di lavoro.

In ogni caso né le verifiche eseguite, né gli acconti corrisposti valgono quale accettazione del software già rilasciato.

Clausola-tipo 4

Variazioni dei tempi previsti nel Piano di lavoro

1. Nel caso in cui l’attività di sviluppo del software non possa svolgersi e concludersi secondo i termini indicati nel Piano di lavoro a causa di comprovate ed imprevedibili ragioni tecniche di carattere oggettivo, il Fornitore è tenuto a comunicare tempestivamente al Committente i motivi e l’entità del ritardo. L’entità del ritardo deve comunque essere congrua rispetto ai motivi addotti.

2. Il Committente ha diritto di recedere dal contratto nel caso in cui il ritardo annunciato dal Fornitore sia superiore a giorni.

3. Qualora il Committente non si avvalga della facoltà di recesso, le parti procedono alla riformulazione del Piano di lavoro, concordando i nuovi termini di consegna da parte del Fornitore.

Clausola-tipo 5

Verifica finale

1. Il Fornitore è tenuto a eseguire l’installazione e la configurazione del software sulle apparecchiature hardware del Committente affinché questi possa espletare le operazioni di verifica finale.

2. Il Committente ha l’obbligo di utilizzare, a tal fine, la Procedura di accettazione di cui al Piano di lavoro e di segnalare per iscritto con raccomandata a/r (o con PEC) al Fornitore, eventuali fallimenti di uno o più test della Procedura entro ………… giorni lavorativi dal completamento delle operazioni di installazione e configurazione eseguite per consentire la verifica. La segnalazione dei fallimenti riscontrati determina il mancato superamento della verifica e implica la mancata accettazione del software, salvo quanto previsto al punto 5 della presente clausola.

3. Trascorso il termine di cui al comma precedente senza che al Fornitore sia pervenuta alcuna contestazione da parte del Committente, il software si intende accettato ai sensi dell’art. 1665, comma 3, c.c. e il Fornitore matura il diritto al pagamento del corrispettivo.

4. Il Committente che ha accettato comportamenti del software difformi rispetto alla Procedura di accettazione non potrà far valere per tale difformità la garanzia di cui alla clausola 9.

5. Il Committente ha la facoltà di “accettare con riserva” i malfunzionamenti del software che ritiene siano tali da non impedire l’accettazione finale ma che, tuttavia, esige siano corretti dal Fornitore secondo le modalità fissate nella clausola 9, “Garanzia (manutenzione)”.

6. Nel caso di esito negativo della verifica, il Fornitore è tenuto a eliminare i difetti riscontrati entro

………….. giorni lavorativi. Il Committente, ricevuto il software, procede a una nuova verifica secondo le modalità di cui al punto 2. Il contratto si intenderà risolto di diritto qualora il software dovesse nuovamente presentare difetti, malfunzionamenti o errori, a seguito della segnalazione dei nuovi fallimenti, da parte del Committente, con le modalità e nei termini di cui al punto 2.

Clausola-tipo 6

Consegna

1. Il Fornitore si impegna a consegnare al Committente il software sviluppato secondo le modalità indicate nel Piano di Lavoro: in particolare egli è tenuto ad installare e configurare il software nelle apparecchiature hardware che si trovano presso il Committente, in modo che il software sia “pronto all’uso” entro il termine pattuito nel Piano di Lavoro.

2. Il Fornitore non è tenuto a effettuare ulteriori configurazioni e/o installazioni rispetto a quelle iniziali, salvo che esse siano rese necessarie da difetti del software o da errori nelle operazioni iniziali.

3. Il Fornitore si obbliga altresì a consegnare, contestualmente al software, i manuali operativi per l’installazione, la configurazione e l’utilizzo del software, e la documentazione tecnica esplicativa relativa.

Clausola-tipo 7

Titolarità del codice sorgente Ipotesi A

1. Il Fornitore si impegna a consegnare al Committente, oltre al software in forma di codice oggetto, anche il codice sorgente dell’applicazione e la relativa documentazione tecnica.

2. Il Committente consegue il diritto di modificare ed estendere il software secondo le proprie esigenze; inoltre il Committente acquisisce ogni diritto connesso allo sfruttamento commerciale del software sviluppato [oppure: della seguente parte del software ].

3. Il Fornitore si impegna altresì a risarcire e tenere indenne il Committente da qualsivoglia azione che dovesse essere intrapresa da terzi in relazione a presunti diritti vantati sul software; nonché a intervenire nei giudizi civili e/o penali eventualmente promossi da terzi, anticipando spese e oneri che il Committente si trovasse a dover affrontare in relazione a detti giudizi.

Ipotesi B

1. Il Fornitore si impegna a consegnare al Committente, oltre al software in forma di codice oggetto, anche il codice sorgente dell’applicazione e la relativa documentazione tecnica.

2. Il Committente consegue il diritto di modificare ed estendere il software secondo le proprie esigenze, ma si impegna a non cedere a terzi il codice sorgente e la documentazione tecnica a esso relativa, né nella versione ricevuta dal Fornitore, né in quelle successive eventualmente modificate e/o estese, assumendo l’obbligo di destinare il software consegnatogli dal Fornitore e le sue eventuali modifiche ed estensioni successive a un mero uso interno.

3. Il Fornitore conserva in capo a sé ogni diritto connesso allo sfruttamento commerciale del software sviluppato e delle eventuali modifiche ed estensioni che svilupperà in autonomia.

4. Il Fornitore si impegna altresì a risarcire e tenere indenne il Committente da qualsivoglia azione che dovesse essere intrapresa da terzi in relazione a presunti diritti vantati sul software, nonché a intervenire nei giudizi civili e/o penali eventualmente promossi da terzi, anticipando spese e oneri che il Committente si trovasse a dover affrontare in relazione a detti giudizi.

Ipotesi C

1. Il Fornitore trasferisce al Committente il solo diritto di utilizzo del software in versione oggetto.

2. Il codice sorgente del software rimane nella esclusiva disponibilità del Fornitore. Quest’ultimo conserva in capo a sé la titolarità di ogni diritto connesso allo sfruttamento commerciale del software sviluppato.

Ipotesi C 1

1. Il Fornitore trasferisce al Committente il solo diritto di utilizzo del software in versione oggetto.

2. Il codice sorgente del software rimane nella esclusiva disponibilità del Fornitore. Quest’ultimo conserva in capo a sé la titolarità di ogni diritto connesso allo sfruttamento commerciale del software sviluppato; tuttavia il Fornitore si impegna a non cedere a terzi il software, sia sotto forma di sorgente, sia nella versione eseguibile, per mesi dalla sua consegna al Committente.

Ipotesi D

1. Il Fornitore trasferisce al cliente il solo diritto di utilizzo del programma in versione oggetto.

2. Il Fornitore rimane titolare esclusivo del codice sorgente, ma si impegna, a proprie spese, a depositarlo, unitamente alla relativa documentazione tecnica, presso ……….. , affinché quest’ultimo lo custodisca e lo consegni al Committente nelle ipotesi di fallimento o sottoposizione del Fornitore ad altra procedura concorsuale, nonché di cessazione dell’attività del medesimo.

3. Il terzo depositario si impegna a conservare il codice sorgente e la relativa documentazione tecnica per …… anni; al termine di questo periodo, egli provvederà alla distruzione materiale del codice stesso e della documentazione tecnica.

Clausola-tipo 8

Formazione

Il Fornitore, avvenuta l’accettazione del software da parte del Committente, provvede alla formazione del personale addetto all’utilizzo del software presso il Committente, con le seguenti modalità e tempi:……………………………………………….

(eventuale rinvio a un allegato).

Clausola-tipo 9

Garanzia (manutenzione)

1. Il Fornitore si impegna a garantire, per la durata di dall’accettazione del software,

gli interventi di manutenzione e/o di modifica necessari al fine di eliminare le difformità del software sviluppato rispetto alle specifiche tecniche e funzionali concordate nel Piano di lavoro. Egli, inoltre, si obbliga a eliminare i comportamenti del software che dovessero rivelarsi “non accettabili” a seguito della ripetizione della Procedura di accettazione (indicata nel Piano di lavoro), effettuata in occasione di una revisione del software.

2. L’intervento del personale tecnico del Fornitore volto alla constatazione dell’esistenza del problema segnalato dal Committente dovrà essere effettuato entro ore lavorative.

3. Le operazioni di manutenzione di cui al punto 1 devono concludersi in un termine congruo, avuto riguardo alla complessità del software, alla gravità del difetto e alle difficoltà di intervento. Tali operazioni sono svolte a spese del Fornitore ai sensi dell’art. 1668 c.c.

4. La revisione (o il patch) del software si intende accettata se non presenta più i difetti denunciati e se supera con esito positivo tutti i test previsti dalla Procedura di accettazione di cui al Piano di lavoro.

5. Tale revisione (o tale patch) del software, volta all’eliminazione dei difetti di cui al punto 8.1, non deve introdurre nuovi errori e/o difetti, né creare ulteriori malfunzionamenti; inoltre il Fornitore deve assicurare la conversione dei dati caricati con il vecchio formato in quello nuovo.

6. La manutenzione del software verrà effettuata mediante rilascio della nuova revisione, o del patch, in via telematica (da remoto): a tal fine, il Committente si obbliga sin d’ora ad autorizzare l’accesso da remoto da parte del Fornitore. Se la tipologia delle operazioni di manutenzione da effettuare non consentisse tale modalità, il Fornitore eseguirà gli interventi presso il Committente, mediante accesso diretto ai locali del medesimo e previo accordo sui tempi e sulle modalità di tale accesso.

7. La garanzia cui è tenuto il Fornitore ai sensi della presente clausola è esclusa in caso di uso del software non conforme alle istruzioni indicate nel manuale d’uso consegnato al Committente.

Clausola-tipo 10

Revisioni (e patch) del software

1. Il Fornitore si obbliga a comunicare tempestivamente al Committente l’eventuale fornitura di una nuova revisione (o di un patch) del software ad altri utilizzatori nei due anni successivi all’accettazione del software. In tal caso il Committente ha diritto di chiedere e di ottenere gratuitamente dal Fornitore tale nuova revisione (o patch) del software.

2. Il Fornitore si obbliga altresì, nei due anni dall’accettazione del software da parte del Committente, a comunicargli tempestivamente eventuali problemi di funzionamento riscontrati e segnalati da altri utilizzatori del medesimo software. Il Committente ha diritto, anche in questa ipotesi, a chiedere e ottenere gratuitamente dal Fornitore la nuova revisione (o patch) del software, realizzata al fine di porre rimedio a detti problemi di funzionamento.

3. Nel caso in cui il Committente, nonostante le comunicazioni di cui ai punti 1 e 2, continui a utilizzare il software consegnato in esecuzione del presente contratto senza chiedere la nuova revisione (o il patch), il Fornitore non sarà tenuto a rispondere degli eventuali danni che potranno verificarsi in capo al Committente a causa del protrarsi dell’uso della versione originaria.

Commento giuridico

1. Clausola oggetto

Solo una intensa e fattiva collaborazione tra Committente e Fornitore già nel momento preliminare di definizione dei cc.dd. “requisiti utente e di sistema” consente di soddisfare appieno le necessità del cliente e, soprattutto, permette di contenere al massimo la possibilità di contenziosi in fase di esecuzione del contratto. Proprio perché l’apporto del Fornitore già in questa fase è fondamentale, il punto 1 prevede che il Documento dei requisiti sia redatto dal cliente con la collaborazione del Fornitore e individua gli elementi minimi che questo documento deve contenere.

Si richiama l’attenzione del lettore sul punto e) relativo alla fissazione del termine di consegna del software sviluppato.

Il mancato rispetto del termine di consegna rende il Fornitore inadempiente e comporta l’applicazione della penale eventualmente pattuita per il ritardo.

Ma se al Committente interessa avere la disponibilità del software entro una data che, per sue esigenze particolari, non ritiene prorogabile, dovrà precisare nel contratto che il termine di consegna è da intendersi come “essenziale”.

Occorre prestare particolare attenzione all’art.1457 del Codice civile, che prevede infatti una più intensa tutela della parte adempiente per il caso di violazione di termine essenziale: se scade un termine espressamente dichiarato essenziale senza che la prestazione sia stata adempiuta in modo completo, il contratto si risolve di diritto, ossia si scioglie automaticamente senza necessità di rivolgersi al giudice per ottenere una sentenza che pronunci la “risoluzione” del contratto stesso. In conseguenza dell’avvenuta risoluzione, le parti saranno liberate dalle reciproche obbligazioni e quanto già pagato dal Committente dovrà essergli restituito (così come dovranno essere restituite al Fornitore le parti del software eventualmente già consegnate); inoltre il Fornitore sarà tenuto a risarcire il danno che ha causato al Committente con il suo inadempimento.

Approntato il Documento dei requisiti insieme al committente, il Fornitore procede alla progettazione del software e alla stesura del c.d. Piano di lavoro.

È importante notare che, nello schema contrattuale ipotizzato, è solo in questo momento che viene quantificato con precisione l’importo che il Committente dovrà pagare per la prestazione del Fornitore.

Ciò è previsto a tutela del Fornitore che, solo a Piano di lavoro completato, è in possesso di tutti gli elementi necessari per fare la sua richiesta di corrispettivo economico, evitando di fare preventivi “alla cieca” che potrebbero rivelarsi poi insostenibili economicamente.

Invece, la tutela del Committente, rispetto a “sorprese” sul prezzo, è affidata al riconoscimento in suo favore del diritto di recedere dal contratto con le modalità precisate al punto 4.

Gli altri elementi che il Piano di lavoro deve contenere sono:

• le specifiche tecniche del software commissionato, che devono essere individuate nel rispetto delle regole dell’arte.

• la precisazione delle «risorse che il Committente dovrà mettere a disposizione del Fornitore». Può trattarsi di risorse umane (come, ad esempio, la disponibilità delle persone necessarie per verificare un software per apparecchiature di diagnosi medica) o anche materiali (come nel caso delle strumentazioni tecniche attraverso le quali testare un software realizzato per il rilevamento della velocità di marcia degli autoveicoli).

• la procedura di accettazione che descrive sia le modalità con le quali il software consegnato per la verifica (c.d. collaudo) dovrà essere “testato”, sia il comportamento atteso nella procedura di verifica. Possono eventualmente essere previste anche verifiche intermedie, nell’ipotesi in cui sia concordato il rilascio di alcune versioni del software preliminari rispetto alla consegna finale (v. clausola 5): in tal caso, se si intende sottoporre ad accettazione anche le versioni intermedie, dovrà essere specificata la Procedura di accettazione anche per esse.

Con questa previsione si consente al committente di recedere dal contratto, quando, per qualunque motivo, quanto previsto nel Piano di lavoro non lo soddisfi. Si tenga presente che perché il recesso sia efficace, è necessario che siano rispettate le modalità di comunicazione previste dalla clausola; il recesso cioè, per essere valido ed efficace, deve essere comunicato al Fornitore con raccomandata a/r entro un numero di giorni che le parti devono indicare, decorsi i quali il Piano di lavoro si considera tacitamente accettato e quindi pienamente vincolante per entrambe le parti del contratto. La clausola stabilisce, inoltre, che in caso di recesso del Committente, al Fornitore spetterà una somma, che le parti avranno indicato nel contratto, che rappresenta una sorta di remunerazione per il lavoro che il Fornitore ha svolto sino a quel momento, cioè per l’assistenza prestata al cliente nell’individuazione della tipologia di software più idonea a soddisfare le sue esigenze e per l’elaborazione dello studio di fattibilità (in sostanza il c.d. Piano di lavoro).

Si propone di seguito una seconda versione della clausola relativa all’oggetto del contratto, semplificata rispetto alla prima, che potrà essere utilizzata quando il committente già dispone di un progetto del software da realizzare, oppure nel caso in cui sia la Software House a fornire le caratteristiche del software già al momento della firma del contratto.

Clausola-tipo Oggetto del contratto: Versione b)

1. Il presente contratto ha a oggetto lo sviluppo di un software per…………….. in conformità al Documento dei requisiti di cui all’Allegato 1

2. La realizzazione del software avverrà secondo le modalità indicate nel Piano di lavoro di cui all’Allegato 2, ove è altresì specificata la Procedura di accettazione che verrà utilizzata nella verifica finale (e in quelle intermedie).

3. Gli Allegati 1 e 2 costituiscono parti integranti del presente contratto.

La clausola presuppone che le caratteristiche e le funzionalità essenziali del software da sviluppare siano già definite al momento della conclusione del contratto e prevede che i documenti relativi a esse (Documento dei requisiti e quello che illustra le specifiche del programma, la procedura di accettazione, ecc) siano degli allegati del contratto. È importante, infatti, che anche in casi come quello cui si riferisce questa ipotesi di clausola oggetto, le parti possano disporre di riferimenti certi e documentali di quanto pattuito relativamente alle caratteristiche del programma da realizzare. Il motivo è evidente, ed è quello di evitare liti in corso di esecuzione, che così frequentemente si verificano tra Committente e Fornitore a causa della poca chiarezza degli accordi sugli aspetti tecnici del software oggetto di sviluppo.

2. Responsabilità del Fornitore

Questa clausola impegna il Fornitore a realizzare il software commissionato con le caratteristiche e le funzionalità descritte nel Piano di lavoro e, in particolare, in modo tale che ne sia verificabile la conformità alle “specifiche tecniche e funzionali” concordate e indicate nel documento appena menzionato. L’obbligazione principale del Fornitore è quindi descritta in questa clausola come una

c.d. obbligazione di risultato: il Fornitore sarà considerato adempiente e avrà perciò diritto al corrispettivo pattuito, solo in quanto il Committente ottenga il risultato promesso, cioè solo in quanto gli venga consegnato un software che ha esattamente le caratteristiche che sono state pattuite e che sono riportate nel Piano di lavoro.

La clausola impegna però il Fornitore anche a operare con professionalità e diligenza (v. il punto 2) in modo che il software sviluppato abbia anche buone caratteristiche qualitative: il Fornitore si impegna quindi a utilizzare personale di competenza adeguata e a non introdurre volontariamente nel software prodotto carenze qualitative che, anche se non rendono il software inutilizzabile, ne rendano però necessaria una più o meno costosa ulteriore versione.

Se, invece, il software non soddisfa esigenze e obiettivi per i quali il Committente lo aveva commissionato, ma che non siano stati esplicitati nel Documento dei requisiti, la relativa carenza non potrà che rimanere a carico del Committente.

3. Rilascio di versioni intermedie

La clausola fa riferimento all’ipotesi in cui il Piano di lavoro preveda la consegna al Committente di versioni intermedie e/o parziali del software da sviluppare.

Lo scopo per cui è opportuno inserire nel contratto una clausola con questo contenuto è chiarire che né la consegna delle versioni intermedie e/o parziali, né il pagamento di acconti al Fornitore durante l’esecuzione, valgono come “accettazione” della parte di software verificata.

In mancanza di questa precisazione circa la natura di semplice acconto di quanto pagato dal Committente, in caso di lite, il giudice potrebbe applicare l’art.1666, comma 2 c.c., secondo il quale

«il pagamento fa presumere l’accettazione della parte di opera pagata», con la conseguenza che il Committente perderebbe il diritto alla garanzia per le difformità o i vizi della parte di software verificata che al momento della verifica fossero da lui (conosciuti o) riconoscibili. Questo salvo il caso di malafede del Fornitore, la cui prova da parte del Committente potrebbe però non essere agevole.

4. Variazioni dei tempi previsti nel Piano di lavoro

Con questa clausola si vuole regolare il caso in cui il Fornitore venga a trovarsi, durante l’esecuzione del contratto, nell’impossibilità di rispettare i termini previsti nel Piano di lavoro, pur rimanendo però la sua prestazione possibile.

Va subito chiarito che l’impossibilità presa qui in considerazione è unicamente quella causata da problemi tecnici di carattere oggettivo tali da rendere impossibile il rispetto dei termini di svolgimento e conclusione dell’attività di sviluppo software (ma non tali da rendere impossibile portare a termine lo sviluppo!): per fare un esempio, un mutamento legislativo in materia di retribuzione che stravolge il lavoro di elaborazione di un software per la gestione di “paghe e contributi”.

La clausola non si applica invece ai casi in cui l’impossibilità di rispettare le previsioni del Piano di lavoro dipenda da circostanze che riguardano l’organizzazione del Fornitore (c.d. impossibilità soggettiva, ad esempio dimissioni di un collaboratore sul cui apporto si era contato per stare nei tempi di lavoro) che fanno parte del c.d. rischio di impresa e restano a carico del Fornitore stesso, il quale sarà perciò considerato inadempiente e potrà subire l’applicazione delle penali eventualmente previste dal contratto per il caso di ritardo.

Con la clausola in esame si stabilisce che il Fornitore ha l’obbligo di comunicare tempestivamente al Committente le circostanze che gli impediscono di rispettare quanto previsto dal Piano di lavoro; il Committente, dal canto suo, potrà recedere solo se l’impedimento sopravvenuto comporta un

ritardo superiore a quello che, al momento della firma del contratto, le parti hanno valutato come tollerabile in relazione alle esigenze del Committente.

Se il Committente decide di non avvalersi del suo diritto di recesso, e quindi il rapporto contrattuale prosegue, la clausola impone alle parti l’onere di rinegoziare i termini originariamente stabiliti nel Piano di lavoro.

5. Verifica finale (collaudo)

Con questa clausola le parti stabiliscono come procederanno al “collaudo” del software sviluppato. Per quanto riguarda il tipo di test da utilizzare, si stabilisce che il Committente è tenuto a utilizzare i test indicati nel Piano di lavoro (v. clausola 1). La clausola precisa, inoltre, il termine e la forma – scritta (v. clausola 1) – con cui deve avvenire la comunicazione del mancato superamento di uno o più test; ciò al fine di impedire che si realizzi un’ipotesi di accettazione tacita del software (v. oltre) con conseguente diritto del Fornitore al pagamento del saldo.

Se il Committente ingiustificatamente non procede all’espletamento della verifica o, pur testando il software, non comunica eventuali vizi/difetti entro il termine stabilito, né formula alcuna riserva, il software si intenderà accettato, con le conseguenze di cui si è detto (l’obbligo di pagare al Fornitore il corrispettivo pattuito e il venir meno della garanzia dovuta dal Fornitore per vizi/difetti conosciuti o riconoscibili).

Occorre prestare attenzione a un aspetto. L’accettazione – espressa, tacita o presunta – ha un ruolo centrale nel rapporto: in sua mancanza, il Fornitore non avrà diritto al pagamento, né il Committente avrà diritto a utilizzare e disporre del software: questo, infatti, gli è solo stato messo “a disposizione per la verifica” e non “consegnato”.

In altre parole, l’installazione del software di cui al comma 1 viene eseguita esclusivamente al fine di consentire al Committente di effettuare il c.d. collaudo, mentre non incide sulla posizione delle parti per quanto riguarda il trasferimento del diritto sul software oggetto del contratto.

Il comma 4 implica che, se nel piano dei test della Procedura di accettazione è definito un “esito atteso” di un test che è in contrasto con i requisiti del Committente o con le specifiche funzionali, poiché la Procedura di accettazione è stata a sua volta accettata dal Committente, il Committente non potrà eccepire in seguito sul comportamento esibito dal programma e richiederne la correzione all’interno del garanzia. Ovviamente il Committente potrà commissionare una modifica del programma per renderlo conforme ai suoi desideri.

In altre parole, il modo in cui i test di accettazione definiscono i comportamenti del programma prevale rispetto alle specifiche funzionali. Lo stesso vale per un comportamento del programma che è stato dal Committente accettato e non sanzionato durante i test di accettazione (che spesso si svolgono senza una formale e rigorosa definizione del risultato atteso del programma). Se il Committente desidera poter entrare in possesso del programma e poterlo utilizzare anche in presenza di malfunzionamenti (evidentemente ritenuti di lieve entità) ma desidera che questi vengano corretti all’interno della garanzia, dovrà effettuare una accettazione “condizionale”, indicando esplicitamente i comportamenti del programma che dovranno in seguito essere corretti.

Per il caso che la verifica abbia esito negativo, la clausola prevede che essa possa essere ripetuta, ma, a tutela del Committente, ciò è consentito solo per una volta; la seconda verifica avrà luogo a distanza di un numero di giorni che le parti avranno fissato nel contratto, durante i quali il Fornitore dovrà provvedere a eliminare i difetti del software emersi precedentemente.

Per il caso che il software non superi neanche questa seconda verifica la clausola prevede un risoluzione di diritto.

Quindi il Committente avrà diritto, previa comunicazione per scritto della volontà di avvalersi di questa clausola, di sciogliersi unilateralmente dal vincolo contrattuale, senza necessità di ricorrere al giudice.

La verifica finale (ossia, il collaudo) va tenuta distinta dalle verifiche in corso d’opera previste dall’art. 1662 c.c. La norma consente al Committente di controllare lo svolgimento dei lavori del Fornitore al fine di verificarne lo stato e le modalità di avanzamento e dispone che, se nel corso di

tali verifiche si dovesse accertare che l’esecuzione dell’opera non procede secondo le condizioni stabilite dal contratto e a regola d’arte, il Committente potrà fissare un congruo termine entro il quale l’appaltatore dovrà conformarsi a tali condizioni; trascorso inutilmente il termine stabilito, il contratto sarà da intendersi risolto, e il Committente avrà diritto al risarcimento del danno.

Come si è più volte evidenziato, le norme del Codice civile valgono tra le parti se non è stato convenzionalmente pattuito in senso diverso. Dunque, se si vuole escludere l’applicabilità dell’art. 1662 c.c. occorrerà stabilirlo espressamente nel contratto.

Se invece si volesse regolare l’esercizio di questa facoltà da parte del Committente, si suggerisce una clausola tipo del seguente contenuto.

Verifiche in corso d’opera

a) Il Committente ha diritto di effettuare, anche tramite un proprio incaricato di fiducia, la verifica della corretta esecuzione dell’attività di sviluppo da parte del Fornitore presso la sede operativa di quest’ultimo. A tal fine il Committente è tenuto a preannunciare la visita al Fornitore tramite mail, con …………..giorni/ore di anticipo. In ogni caso il diritto di verifica non può esercitarsi più di

…… volte al mese.

b) Se dalla verifica emergono difformità nell’attività di sviluppo del software rispetto a quanto concordato nel Piano di lavoro, o risulta il mancato rispetto delle regole dell’arte, il Committente comunica per iscritto (con raccomandata a/r) al Fornitore tali circostanze e gli intima di provvedere all’adeguamento rispetto a quanto indicato nel Piano di lavoro entro il termine di giorni,

penale risoluzione di diritto del contratto ai sensi dell’art. 1662 c.c.

c) Allo scadere del termine assegnato ai sensi del punto che precede, nel caso in cui il Committente riscontri, a seguito di un ulteriore controllo, il persistere dell’inadempimento, il contratto si intenderà risolto di diritto.

6. Consegna

Con questa clausola Committente e Fornitore si accordano sulle modalità con le quali il Fornitore dovrà provvedere alla consegna del software una volta terminato il lavoro.

La clausola precisa che il Fornitore è tenuto a svolgere per il Committente anche l’operazione di installazione e configurazione del programma sulle macchine del Committente.

Poiché le operazioni di installazione e di configurazione possono essere necessarie più volte nella “vita” di un programma (in particolare, l’installazione deve essere ripetuta tutte le volte che si cambia la macchina su cui è eseguito il software), nella clausola si precisa che nel corrispettivo del contratto di sviluppo è compresa la sola installazione iniziale (salvo, ovviamente, che la necessità di successive installazioni sia dovuta a difetti del software); il compenso per eventuali ulteriori installazioni dovrà invece essere pattuito a parte. Questo obbligo del Fornitore risulta come uso negoziale nella Raccolta Provinciale Usi della provincia di Torino 2000/2005, Titolo VII, Cap. XIII,

n. 11), e dunque la sua espressa previsione è a rigore superflua; la si è tuttavia inserita per maggiore chiarezza.

7. Titolarità del codice sorgente

Le clausole-tipo indicate disciplinano la titolarità e disponibilità materiale del codice sorgente del software.

Il codice sorgente costituisce un valore per il Fornitore: egli potrebbe non essere disposto a cederlo al Committente oppure volerlo cedere solo a fronte di un adeguato corrispettivo, distinto da quello complessivo previsto per la attività di sviluppo.

D’altro canto il Committente, a sua volta, può avere interesse a disporre del programma solo per uso interno, oppure anche per sfruttarlo economicamente cedendolo a terzi, o infine potrebbe voler mantenere l’esclusiva del software commissionato, per evitare che i suoi concorrenti possano acquisirlo.

Le differenti formulazioni della clausola relativa al codice sorgente offrono diverse soluzioni pensate per adattarsi alle diverse situazioni che possono presentarsi: è opportuno esaminarle con attenzione e individuare, tra le diverse formulazioni, quella che in concreto risponde meglio agli interessi propri della controparte.

Ipotesi a)

Il Fornitore cede al committente il “massimo” del valore del programma: gli consegna cioè la versione sorgente insieme alla documentazione tecnica e gli attribuisce il diritto di usare il software senza porre alcuna limitazione nelle modalità di utilizzo.

Ipotesi b)

Nella seconda ipotesi, la clausola contempera opposte esigenze: per un verso lascia la titolarità del codice sorgente e la possibilità di sfruttarlo economicamente in capo allo sviluppatore e, per altro verso, consente al cliente di disporre del codice stesso per eventuali modifiche ed estensioni ma stabilendo un impegno a un utilizzo esclusivamente “interno” del software e delle eventuali modifiche ed estensioni.

Ipotesi c)

Quando il Committente non ha interesse a modificare e/o estendere il software che ha ricevuto si potrà optare per questa formulazione. Ciò comporterà, verosimilmente, un corrispettivo più ridotto rispetto alle ipotesi a) e b).

Ipotesi c1)

Questa formulazione della clausola presuppone una situazione in cui il software prodotto dal Fornitore riveste un particolare valore per l’attività del Committente: questi vuole assicurarsi che non venga ceduto anche ad altri clienti del Fornitore, con i quali compete sul mercato; in altri termini ritiene che il programma commissionato possa costituire un fattore di affermazione concorrenziale. Egli non è interessato a disporre del codice sorgente, ma vuole semplicemente impedire che il Fornitore possa vendere (o comunque cedere in licenza d’uso) lo stesso software ad altri clienti, suoi concorrenti.

Ipotesi d)

Nell’ultima ipotesi, pur rimanendo in capo al Fornitore la titolarità del codice sorgente, si decide di affidarlo a un terzo soggetto affinché il cliente 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. escrow), presumibilmente verso un corrispettivo per il terzo depositario, tra i contraenti del contratto di sviluppo e il terzo che si impegna alla custodia del codice per un periodo che viene stabilito nel contratto stesso, decorso il quale il terzo dovrà distruggere il codice.

Infine, comune a tutte le diverse ipotesi di clausola è la previsione in base alla quale il Fornitore si obbliga a tenere indenne il cliente da eventuali pretese di terzi che si affermino titolari di diritti sul software. In un caso del genere, il Fornitore sarà anche tenuto a intervenire nei processi civili e/o penali eventualmente promossi da terzi contro il Committente, anticipando le spese legali.

8. Formazione

L’impegno dello sviluppatore a provvedere alla formazione dei dipendenti del Committente sull’uso del software è stato rilevato nella prassi commerciale della provincia di Torino (Raccolta Provinciale Usi 2000/2005, Titolo VII, Cap. XIII, n. 11).

Sarà indispensabile però precisare nel contratto o in un suo allegato le modalità con le quali tale prestazione verrà eseguita e l’impegno in termini di ore, ecc., in concreto richiesto al Fornitore.

9. Garanzia (Manutenzione)

La disciplina del Codice civile – come si è detto più volte – è derogabile dalle parti: dunque, anche in tema di garanzia, le parti possono pattuire nel contratto regole diverse da quelle previste dagli artt.1667 e 1668 c.c. escludendo o limitando la garanzia per le difformità del software collaudato rispetto alle specifiche tecniche e funzionali. In particolare, considerato il veloce evolversi della tecnologia, non sempre la garanzia biennale, prevista dal Codice civile, sarà adeguata. Per questo motivo, nella clausola-tipo è stato lasciato in sospeso il termine di durata della garanzia, che dovrà essere concordato tra le parti tenendo conto di quanto detto sopra.

La clausola regola poi (punti 2, 3 e 6) gli aspetti relativi ai tempi di intervento e alle modalità dello stesso (da remoto e/o presso il Committente). Si sottolinea che le modalità degli interventi in garanzia incidono sul profilo qualitativo dell’offerta del Fornitore e vanno dunque attentamente valutati dal Committente in sede di trattative.

Inoltre, uno degli aspetti più importanti per il Committente è che, in caso di revisione del software per eliminarne dei difetti, sia comunque garantita la conversione dei dati nei nuovi formati. Infatti, ove ciò non fosse possibile, il Committente dovrebbe affrontare il problema del travaso dei dati, con ulteriori costi. Per questo il punto 5, seconda parte, specifica che il Fornitore ha obbligo di garantire tale conversione. Infine, va tenuto presente, anche se non indicato nella clausola-tipo, che, nel caso in cui si manifestino difetti tali da rendere il software del tutto inadatto a svolgere le funzioni per cui era stato commissionato, risultanti dal Documento dei requisiti, il Committente ha comunque il diritto di chiedere la risoluzione del contratto, con quello che ne consegue in termini di restituzione del corrispettivo pagato e di danni risarcibili, ai sensi dell’art. 1668 c.c. Tale evenienza, peraltro, dovrebbe essere improbabile se i test di accettazione previsti nel Piano di lavoro sono sufficientemente analitici e completi.

10. Revisioni (e patch) del software.

La clausola-tipo in esame riguarda gli obblighi informativi nella fase successiva alla consegna del software. Si stabilisce l’obbligo, per il Fornitore, di comunicare al suo cliente l’eventuale sviluppo di nuove versioni del programma, al fine di consentirgli di acquisirle gratuitamente.

In particolare, quanto previsto nel comma 1 della clausola ha senso soltanto se in tema di titolarità del codice sorgente le parti scelgono l’ipotesi c), della clausola n. 7.

Note tecniche Documento dei requisiti

Nella definizione dei requisiti è opportuno che il Committente specifichi al meglio le sue esigenze descrivendo lo scenario di uso del realizzando software e i requisiti prestazionali nella maniera più precisa possibile. È consigliabile usare a tale scopo anche linguaggi e/o ambienti di specifica (semi)formali quali UML.

Come documentato nella letteratura relativa all’ingegneria del software, la collaborazione tra Committente e Fornitore per la definizione dei requisiti utente e di sistema consente di caratterizzare in modo più accurato le necessità del Committente.

Specifiche tecniche

Per specifiche tecniche funzionali intendiamo qui un documento che descrive:

a) l’ambiente informatico e cioè l’hardware sul quale si dovrà procedere all’installazione e/o alla configurazione del software;

b) il software di ambiente, i sistemi operativi, il database management system e qualunque software, non oggetto della fornitura, con il quale il software commissionato dovrà interagire;

c) i requisiti di prestazione che il software offrirà.

Per specifiche funzionali intendiamo qui un documento che descrive il comportamento del software da realizzare. Il termine “funzionale” enfatizza il punto di vista secondo il quale il software è la realizzazione concreta di una funzione matematica che calcola ben determinati output in funzione di ogni occorrenza degli input sui quali essa è definita. Dato che i possibili dati di input di un software se non sono infiniti sono certamente (salvo rari casi) in numero talmente grande da non poter essere descritto da una tabella, è necessario descrivere la relazione fra ingresso e uscita in modo astratto piuttosto che concreto mediante una tabella (definizione estensionale). È inevitabile, anzi è positivo, che nella specifica funzionale si ricorra almeno in parte a linguaggi formali (meglio ancora se accompagnati da relativo ambiente di sviluppo) per descrivere con esattezza gli aspetti funzionali del software da realizzare. In contrapposizione alle specifiche funzionali, le specifiche tecniche e/o quelle prestazionali sono spesso indicate con la locuzione “specifiche non funzionali”.

Procedura di accettazione

Con la locuzione “Procedura di accettazione”, indichiamo un documento che descrive nel modo più preciso possibile sia le modalità con cui sottoporre a test il software consegnato sia il comportamento atteso che il software deve esibire. Il test sarà costituito da un certo numero di Casi di test, per ciascuno dei quali deve essere descritto l’ambiente nel quale il test deve essere eseguito (facendo riferimento al Documento dei requisiti), la configurazione del software da testare, le operazioni da compiere sul software (gli input a cui sottometterlo) e il comportamento atteso, cioè gli output e/o gli effetti laterali che deve produrre. Il test verrà considerato “superato positivamente” quando il comportamento esibito dal software sarà identico a quello atteso, che quindi deve essere descritto con molta precisione.

È necessario porre attenzione al fatto che il comportamento atteso descritto nella specifica di ogni singolo Caso di test deve essere conforme alle specifiche funzionali. Per questa ragione occorre valutare con attenzione la “correttezza” dei Casi di test. Il Committente deve poter quindi valutare e accettare (o respingere) i Casi di test proposti dal Fornitore perché essi potrebbero essere inadeguati. Poiché il comportamento descritto nel Caso di test è una esemplificazione delle specifiche funzionali, esso prevale rispetto al documento delle specifiche funzionali in quanto ne costituisce una integrazione, e quindi non potrà poi essere considerato come un comportamento erroneo da correggere all’interno della garanzia/manutenzione del software.

È consigliabile adottare per i test di accettazione strumenti che permettano di sottoporre automaticamente il software agli input desiderati e registrino gli output ottenuti. Anche se la valutazione della corrispondenza fra output attesi e output registrati dovesse essere eseguita manualmente, l’uso di strumenti automatici permette la facile registrazione dell’esecuzione dei test e la loro precisa ripetizione in occasione di riconsegne, per verificare l’assenza di regressioni.

L’esito o valutazione di ogni singolo test può essere “successo”, “fallimento”, “non decisivo” (in caso di specifica non precisa dell’output atteso); un mancato successo può essere non accettabile, o accettabile con riserva se il Committente è disposto ad accettare il software a condizione che il Fornitore si impegni a correggere il malfunzionamento all’interno della garanzia di cui gode il software consegnato. Nella letteratura relativa all’ingegneria del software il collaudo è denominato “verifica” (verification), mentre la Procedura di accettazione corrisponde al processo di verification testing. È opportuno sottolineare che collaudo e Procedura di accettazione effettuati tramite l’esecuzione di un certo numero (finito) di test è un modo di verificare che il software consegnato soddisfi le specifiche funzionali di cui al punto 3 b). Poiché il software è in grado di esibire infiniti comportamenti (al variare dei dati in input) conformi alle specifiche funzionali, la Procedura di accettazione verifica la sua correttezza (corrispondenza con le specifiche funzionali) solo su un numero finito dei possibili comportamenti. Una verifica veramente completa si potrebbe avere solo se si fosse in grado di dimostrare matematicamente che il software prodotto è equivalente alle specifiche funzionali.