OBBLIGO DI MEZZI O RISULTATO?
atipicità delle forniture informatiche
di Graziano Guazzi
Recentemente ho ricevuto alcune e-mail con le quali mi si chiedevano chiarimenti di natura legale su contenziosi sulla fornitura del software. Premesso che questi argomenti vanno approfonditi con gli avvocati, condivido volentieri alcune riflessioni sul tema (senza pretese esaustive), prendendo spunto da alcune esperienze di perito di parte.
L’informatica ha inciso profondamente in tutti gli ambiti sociali e ha determinato il sorgere di complessi problemi anche per il diritto. Prova ne sono una ricca collezione di eterogenee sentenze di primo grado e il loro completo ribaltamento nei gradi successivi. Fortunatamente, negli ultimi anni si registra una convergenza che riconosce l’atipicità di queste forniture e la necessità di nuovi paradigmi negoziali.
Si usa tradizionalmente distinguere tra le obbligazioni di mezzi e le obbligazioni di risultato, in relazione al fatto che oggetto dell’obbligazione sia una prestazione connotata dalla diligenza ovvero un risultato.
Nelle obbligazioni di risultato il debitore-fornitore si impegna a conseguire un risultato come frutto della prestazione: le obbligazioni di risultato saranno adempiute quando sarà raggiunto il risultato promesso: se all’opposto non riuscirà, prescindendo dall’impegno profuso, sarà considerato inadempiente e non potrà pretendere il compenso per l’attività svolta, come potrebbe fare se invece la sua fosse stata una obbligazione di mezzi.
Questa distinzione, secondo l’impostazione tradizionale, ha riflessi sul riparto dell’onere della prova relativa all’esatto adempimento dell’obbligazione in quanto la prova dell’inadempimento, nell’ambito delle obbligazioni di mezzi, graverebbe sul creditore-cliente, che sarebbe tenuto a dimostrare che la prestazione non è stata conforme a diligenza. Viceversa, nelle obbligazioni di risultato, una volta dimostrato il titolo della pretesa contrattuale (l’inadeguatezza della fornitura), sarebbe il debitore-Fornitore a dover dimostrare che il risultato è stato raggiunto ovvero non è stato raggiunto per cause non imputabili a lui.
Con gestionali si intendono Applicazioni che svolgono funzioni di gestione aziendale: contabilità, amministrazione, acquisti, vendite, etc. E’ importante classificare le Applicazioni gestionali in due gruppi: verticali e orizzontali. I primi rispondono alle specifiche esigenze di un singolo mercato o di un mercato strettamente definito, e quindi dedicati specificatamente ad un determinato settore manifatturiero, commercio o dei servizi (quali ad esempio, calzaturifici, farmaceutici, alimentari, metalmeccanici, banche), e determinate dimensioni aziendali, in genere medie o piccole. Si usa verticalizzati in contrasto con gli Applicativi orizzontali che sono di uso generalizzato. Le personalizzazioni sono invece modifiche sviluppate per il singolo cliente.
Chiarire nel contratto di acquisto a quale di queste due categorie appartiene il software proposto è molto importante. La ragione è che una delle questioni più delicate in tema di forniture Software è legata alle obiettive difficoltà di individuare con chiarezza e precisione, da un lato, gli obiettivi del cliente e, dall’altro, le prestazioni alle quali è tenuto il fornitore.
A questa difficoltà, si aggiungono la fisiologica carenza di conoscenze tecniche del cliente e l’impossibilità (soprattutto per le PMI) di valutare in breve tempo se la proposta è effettivamente adeguata agli obiettivi. D’altra parte, anche il fornitore potrebbe avere difficoltà a comprendere le reali necessità del cliente. Quando la proposta è quella di una soluzione verticalizzata, il fornitore di fatto si presenta come un esperto. Per questa ragione, in fase di contenzioso, il “non mi è stato chiesto” e il “non mi è stato detto” possono diventare argomenti deboli, se non addirittura aggravanti. Qualificandosi come esperto, il fornitore è tenuto a specifici e penetranti doveri di informazione, facendosi carico di porre domande precise al fine di verificare la copertura funzionale che il cliente è fisiologicamente portato a dare scontata. Per capirci, si prenda il cauzionamento: il modello proposto corrisponde effettivamente al modus operandi del Cliente?
Affrontare in modo atomistico i difetti di una fornitura informatica è certamente corretto dal punto di vista tecnico. E’ invece opinabile quando si tratta di accertare eventuali inadempienze del fornitore. Le ragioni sono atipiche e complesse, ma per capire la loro natura possono essere prese in considerazione le seguenti singolarità.
Sebbene il Sistema oggetto del contratto sia composto da parti ben identificabili e distinte: HW, Sistema Operativo, Data Base, Programmi Applicativi – a loro volta composti da sottoinsiemi contabilità, fatturazione, magazzino, etc. – essendo parti complementari di un tutto:
1. Il risultato atteso dal Cliente, e per il quale il fornitore si è impegnato, presuppone che tutte le parti risultino funzionanti, anche perché nessuna parte dell’Applicazione può essere sostituita con un’iniziativa autonoma del Cliente.
2. Questo vincolo tecnico (ma anche contrattuale – vedi la tutela delle opere d’ingegno –) può essere rimosso solo con la volontà del produttore.
3. Per chiarire il concetto, ponendo che il cattivo funzionamento si limitasse al modulo “statistiche”, a fronte di una cronicità del problema, per il Cliente l’unica possibilità rimane quella di sostituire tutta l’Applicazione.
I contratti di manutenzione e aggiornamenti di legge e il supporto operativo dell’utente devono essere considerati una parte essenziale e complementare della fornitura di un Gestionale:
1. E’ facile comprendere che l’Applicazione possa diventare inadeguata e quindi inutilizzabile se, ad esempio, non viene tempestivamente aggiornata alle nuove disposizioni di legge.
2. Così come è facile comprendere che nessun Software possa essere esente da difetti. Per afferrare questa caratteristica essenziale, occorre distingue i difetti del Software da quelli che derivano dall’usura o rottura meccanica: sebbene presente fin dall’origine, l’inadeguatezza di un software si può manifestare lontana dal momento dell’acquisto delle licenze. Banalmente, si pensi all’impossibilità di utilizzare, dopo qualche anno, un report predisposto per un totale a 6 cifre, con numeri che nel frattempo sono cresciuti fino a superare le 6 cifre.
3. Proprio per sopperire a questa peculiare fragilità fisiologica, le licenze software (in particolare di Applicazioni Gestionali destinate ad un uso professionale) vengono sempre accompagnate dai contratti (spesso) separati che ne garantiscono la manutenzione correttiva.
4. Di fatto, in mancanza di un adeguato contratto, la probabilità di continuare ad utilizzare senza problemi le licenze acquistate (si badi, una delle aspettative del Cliente), è bassa.
Ne consegue che, indipendentemente dalle terminologie (fisiologicamente confuse e imprecise: vendita, licenza d’uso, contratto di assistenza, canone annuale di manutenzione, etc.), di fatto:
1. Il Cliente non acquisisce la proprietà dei Programmi, tantomeno dei sorgenti. Pertanto la rimozione degli errori e gli adeguamenti di legge li può fare solo il Fornitore.
2. Il fornitore in fase contrattuale ha assunto un obbligo di risultato: la messa a disposizione di programmi atti alle esigenze di gestione del Cliente e il suo corretto funzionamento nel tempo.
Ai fini del giudizio, la stretta interdipendenza fra i diversi elementi della fornitura, incluso il contratto di manutenzione correttiva e adeguamenti di legge, stanno orientando i giudici più attenti a ricondurre la fornitura di un sistema informatico, sebbene composta da diversi e separati contratti (la vendita dell’Hardware e del Software di base, la concessione della licenza d’uso del Software gestionale, la fornitura della manutenzione), ad una obbligazione di risultato. Il che si traduce nel fatto che il Cliente, una volta dimostrata l’inadeguatezza del software, può contestare l’intera fornitura a prescindere dal fatto che in parte sia utilizzabile. Resta a carico del fornitore dimostrare il contrario.
