Computer Programming n.ro 47 del 01-10-96
di Andrea Monti
L’analisi delle licenze d’uso compiuta nei numeri precedenti dimostra chiaramente quanto sia complesso formalizzare un rapporto giuridico avente ad oggetto lo sviluppo di un programma o la vendita di hardware.
Le ragioni sono molteplici e vanno (a puro titolo esemplificativo) dalla discutibile nozione di software adottata dalla legislazione internazionale ed italiana, alla difficoltà di individuare esattamente l’oggetto dell’obbligazione assunta dallo sviluppatore o dal rivenditore delle macchine.
Detti problemi si pongono in modo differente a seconda della natura dell’utente finale, ma traggono origine da una caratteristica che è propria del settore informatico: il rapporto fornitore-cliente non si limita ad una mera consegna di beni dietro il pagamento di un certo prezzo ma va ben oltre, trasformandosi – anzi essendo prima di tutto – un rapporto di consulenza.
In altri termini quasi mai la vendita di un sistema si esaurisce nella semplice prospettazione delle differenti alternative tecniche, ma implica un’attività di orientamento verso una scelta piuttosto che verso l’altra.
Questa attività di orientamento assume una minore rilevanza – anche se non esclude la responsabilità del fornitore – nei confronti dell’utente privato che non ha delle esigenze particolari ma diventa elemento essenziale di valutazione con l’interlocutore che opera in campo professionale.
Questa è appunto l’ipotesi che ci interessa, cioè quella di un’azienda che offre soluzioni hardware e software ad un target professionale che però molto spesso – pur essendo convinto del contrario – non ha una specifica cultura informatica e che quindi si trova in una situazione di oggettiva inferiorità nella stipulazione di un contratto.
Questa disparità assume un rilievo fondamentale nel caso specifico perché il principio della buona fede contrattuale – che è uno dei cardini della materia – impone di salvaguardare la parte meno avvertita.
Tornando al punto, il primo passo da compiere (a prescindere dall’oggetto del contratto) è l’esatta identificazione della prestazione.
Tanto per fare qualche esempio (tratto da vicende che sono finite in tribunale) si discute se il contratto di sviluppo di un programma implichi necessariamente l’addestramento del personale che dovrà usarlo; oppure quali siano le differenze fra la vendita di un sistema informatico dotato o meno del software, specie se detto sistema deve essere destinato ad un’attività specifica come per esempio un CED di uno studio commerciale.
Allo scopo di prevenire controversie (la cui natura è descritta più avanti nello spazio leading-case) è bene quindi adoperarsi per risolvere a monte la maggior parte degli inconvenienti ipotizzabili.
E’ necessario dunque separare nettamente le varie offerte articolandole in una struttura modulare che consenta più alternative, e predisporre delle condizioni generali di contratto che contengano gli elementi comuni a tutte le singole offerte (definizioni, termini, prescrizioni e decadenze, durata, modalità di pagamento, foro competente ecc.).
In questo modo vengono snellite le procedure e viene facilitata al cliente la comprensione di ciò che sta accadendo. Attenzione però a non cadere nell’estremo opposto, cioè quello di una eccessiva frammentazione di offerte, che invece di semplificare creerebbero più problemi di quanti ne intendono risolvere.
A fronte di questa contrattualistica “trasparente” dovrebbe esserci la chiara identificazione delle necessità del cliente, il che implica una preventiva ricognizione sui suoi problemi informatici. Bisogna cercare, in una parola, la collaborazione dell’utente finale, ponendosi nell’ottica che la soluzione tecnicamente migliore non è sempre quella che incontra il gradimento del potenziale cliente.
Certamente tutto questo si presenta molto laborioso e può apparire antieconomico, vista la più che probabile perdita di tempo; sull’altro piatto però bisogna mettere l’indubbio vantaggio di evitare contestazioni nel corso dell’esecuzione del contratto che potrebbe causare problemi – se non danni – molto più gravosi di quelli che si volevano evitare.
Possibly Related Posts:
- Webscraping e Dataset AI: se il fine è di interesse pubblico non c’è violazione di copyright
- Le sanzioni UE ad Apple e Google aprono un altro fronte nella guerra contro Big Tech (e incrinano quello interno)
- Il caso Crowdstrike rivela le cyber-debolezze Ue
- GDPR e OpenAI: quanto sono fondate le accuse del Garante?
- L’ AI open source non è un crimine e non aiuta i criminali