I contratti di sviluppo software rappresentano forse uno degli strumenti più delicati nell’ambito del diritto dei contratti. Tecnologie come smart contracts e intelligenza artificiale mettono sempre più a dura prova sia gli schemi che la prassi contrattuale degli ultimi decenni. Essi infatti non solo disciplinano la creazione di programmi informatici, ma intrecciano una molteplicità di aspetti normativi, dalla qualificazione giuridica alla proprietà intellettuale, fino alla gestione dei rischi operativi. E in un contesto in cui la tecnologia evolve a ritmo serrato, le parti contraenti devono muoversi con precisione per evitare ambiguità e contenziosi.
Uno dei nodi centrali di questi contratti riguarda la loro qualificazione. Laddove lo sviluppatore sia un’impresa di medie o grandi dimensioni, il contratto tende ad essere inquadrato come appalto o appalto d’opera manuale. In questo caso, la prestazione è contraddistinta da un’obbligazione di risultato: l’appaltatore è considerato adempiente solo nel momento in cui consegna un prodotto conforme alle esigenze del committente.
La situazione cambia radicalmente, invece nel caso di sviluppatori individuali o piccole imprese, dove prevale la qualificazione come prestazione d’opera intellettuale. Qui l’obbligo è di mezzi, ovvero lo sviluppatore deve garantire la diligenza richiesta dal caso concreto, senza però dover assicurare il raggiungimento di un risultato determinato.
Ora, non sfuggirà di certo ai giuristi più attenti come le differenze tra obbligazioni di risultato e obbligazioni di mezzi nei contratti di sviluppo software possono avere (ed anno) implicazioni pratiche particolarmente significative, che influiscono sia sul rapporto tra le parti sia sulla gestione delle eventuali controversie.
Quando il contratto viene inquadrato come appalto, lo sviluppatore, come detto, assume un’obbligazione di risultato. Questo significa che egli è tenuto a realizzare un prodotto conforme alle specifiche pattuite nel contratto. E’ quindi la consegna di un software funzionante e rispondente alle esigenze del committente a costituire il parametro per valutare l’adempimento.
Ad esempio, se una grande azienda di sviluppo software viene incaricata di creare un gestionale per ottimizzare la logistica di un’impresa, il risultato atteso è la consegna di un programma che sia in grado di migliorare i flussi operativi secondo le specifiche concordate. Qualora il software presenti funzionalità incomplete o difetti che impediscano di raggiungere gli obiettivi prefissati, l’appaltatore sarà ritenuto inadempiente, indipendentemente dall’impegno profuso nello sviluppo.
Sul piano pratico, ciò implica che il committente ha una maggiore tutela, poiché il suo interesse si concentra sul risultato concreto. Per contro, lo sviluppatore assume un rischio più elevato: eventuali difficoltà tecniche o imprevedibili non possono essere addotte come giustificazione per l’inadempimento.
Nel caso invece di contratti in cui prevale la qualificazione come prestazione d’opera intellettuale, la situazione cambia sensibilmente. Lo sviluppatore, tipicamente un professionista individuale o una piccola impresa, si impegna a mettere a disposizione le proprie competenze e a operare con la diligenza richiesta dal caso concreto, ma non garantisce un risultato specifico.
Per chiarire, immaginiamo un programmatore freelance incaricato di sviluppare un prototipo di software per l’analisi di dati finanziari. Se il contratto stabilisce un’obbligazione di mezzi, egli adempie al proprio dovere purché dimostri di aver lavorato con diligenza, ad esempio seguendo le indicazioni del committente, utilizzando strumenti aggiornati e rispettando le best practice del settore. Anche se il prototipo non soddisfa pienamente le aspettative iniziali, lo sviluppatore non potrà essere considerato inadempiente, a meno che il committente dimostri che ha agito con negligenza o incompetenza.
Questa impostazione offre una protezione maggiore al prestatore d’opera, ma può creare difficoltà per il committente, il quale si ritrova esposto al rischio di non ottenere un prodotto utile nonostante abbia sostenuto i costi.
Le implicazioni pratiche delle due obbligazioni emergono chiaramente, poi, ove dovessero sorgere eventuali controversie. Nel contratto di appalto, infatti, spetterà all’appaltatore dimostrare di aver consegnato un prodotto conforme alle specifiche concordate. Il focus sarà quindi sull’esito tangibile. Nel contratto di prestazione d’opera intellettuale, invece, il peso probatorio si sposta sul committente, che dovrà dimostrare che lo sviluppatore non ha agito con la diligenza richiesta dal caso concreto.
Per fare un esempio, un’azienda potrebbe contestare a uno sviluppatore autonomo il mancato raggiungimento di un obiettivo di performance del software. Ma se il prestatore riuscisse a dimostrare di aver agito con professionalità, seguendo le indicazioni ricevute e adottando i metodi più adeguati, il Giudice potrebbe non considerarlo come inadempiente.
Ora, ampliando ulteriormente il discorso, l’attenzione va spostata sull’inquadramento del software in se: è un’opera o un servizio?
Sul piano dottrinale e giurisprudenziale il dibattito è veramente interessantissimo, ma per esigenze pratiche qui ci limitiamo a riportare che la tesi prevalente propende per la qualificazione come opera, inserendolo dunque nel campo dell’appalto d’opera, anche se l’orientamento della giurisprudenza, invece, non appare univoco, lasciando aperte diverse questioni interpretative.
Un ulteriore aspetto di grande rilevanza è rappresentato poi dalla titolarità dei diritti di proprietà intellettuale sul software sviluppato. La normativa sul diritto d’autore offre infatti una tutela ampia ai programmi informatici, equiparandoli alle opere letterarie (per approfondire suggeriamo di cliccare qui, si aprirà una pagina contenente numerosi contributi dello Studio in materia). Questo status implica che, anche quando i diritti patrimoniali sono trasferiti, quelli morali restano inalienabili, a meno che non intervenga un accordo specifico che ne contempli alcune deroghe.
Ad esempio, se il software dovesse essere creato da un lavoratore dipendente, il datore di lavoro acquisirebbe automaticamente i diritti patrimoniali, come previsto dall’art. 12-bis della Legge sul Diritto d’Autore, salvo pattuizione contraria. Al contrario, qualora il programma fosse sviluppato da un lavoratore autonomo, il trasferimento dei diritti patrimoniali richiederebbe un’esplicita clausola contrattuale. Tale passaggio risulta fondamentale per evitare futuri conflitti, specialmente in relazione alla possibilità del committente di modificare, adattare o distribuire il software. Ma sul punto è in corso di pubblicazione un contributo a cura del sottoscritto, e pertanto ci si riserva di meglio approfondire in futuro.
Ulteriore criticità è poi creata dal diritto all’integrità dell’opera, caratteristico delle opere tutelate dal diritto d’autore. Com’è noto, questo diritto garantisce che l’opera, compresi i programmi informatici, non venga alterata o modificata in modo tale da ledere la reputazione o la personalità dell’autore. Ma questa tutela entra spesso in conflitto con la natura stessa del software, che, per sua intrinseca funzionalità, necessita di aggiornamenti, personalizzazioni e adattamenti continui per rimanere funzionali e competitivi e per per correggere bug, migliorare le prestazioni, implementare nuove funzionalità o adeguarsi ai cambiamenti normativi e tecnologici. E tale necessità deve essere però ben bilanciata con il rispetto dei diritti morali dell’autore, spesso fonte di contrasti interpretativi.
Ad esempio, se uno sviluppatore freelance realizzasse un software gestionale e il committente, nel tempo, decidesse di affidare ad altri programmatori l’introduzione di nuove funzionalità, lo sviluppatore originario potrebbe opporsi, sostenendo che le modifiche andrebbero ad alterare l’identità del software o a ledere la propria reputazione professionale.
O ancora, immaginiamo che un’azienda acquisti un software per gestire i flussi di magazzino. Se decidesse di personalizzarlo per integrarlo con un nuovo sistema di monitoraggio, il programmatore originario potrebbe opporsi alle modifiche sostenendo che alterano la struttura del codice, compromettendo l’efficienza o l’eleganza della soluzione progettata.
Supponiamo ancora che un committente ritenga non necessarie alcune funzionalità incluse nel software e decida di rimuoverle. Lo sviluppatore potrebbe contestare tale scelta, considerando che l’opera, così modificata, non riflette più la propria visione progettuale, compromettendo l’integrità artistica e tecnica del programma.
Per evitare siffatti conflitti, diventa allora cruciale disciplinare contrattualmente i limiti entro cui il committente può intervenire sul software. Ad esempio, si potrebbero prevedere clausole che attribuiscano al committente il diritto di apportare modifiche solo previa approvazione dell’autore originario, o che prevedano un meccanismo di collaborazione con lo sviluppatore per l’implementazione degli aggiornamenti, o ancora che specificamente autorizzino l’intervento di terzi sul codice, limitando le contestazioni sul diritto all’integrità.
Un altro ambito critico è rappresentato poi dalla gestione dei rischi legati al mancato raggiungimento degli obiettivi contrattuali o a eventuali malfunzionamenti del software. La definizione accurata delle specifiche progettuali, in questo caso, diviene pressocché fondamentale per ridurre i margini di errore e le incomprensioni tra le parti. A tal proposito, l’assistenza del committente nel fornire indicazioni dettagliate e il coinvolgimento attivo durante le fasi di sviluppo possono giocare un ruolo determinante.
Non meno importante è la predisposizione di clausole che regolino i rapporti in caso di difetti o ritardi, come garanzie di buon funzionamento o penali per inadempimento.
Ma è forse la questione della proprietà del codice sorgente, spesso sottovalutata, a costituire il principale terreno di potenziale conflitto. Questo aspetto può generare conflitti significativi, specialmente quando non viene regolamentato in modo chiaro.
Il codice sorgente rappresenta l’insieme delle istruzioni scritte in un linguaggio di programmazione leggibile dagli esseri umani, ed è indispensabile per modificare, aggiornare o personalizzare un software. La sua gestione in termini di proprietà e accessibilità può avere ripercussioni operative, economiche e legali di grande rilievo.
In assenza di una clausola contrattuale che regoli esplicitamente la proprietà del codice sorgente, è presumibile che i diritti patrimoniali sul software rimangano in capo allo sviluppatore. Questo si verifica in virtù delle norme che regolano il diritto d’autore, le quali stabiliscono che l’autore di un’opera, salvo diverso accordo, ne detiene i diritti economici. Per il committente, ciò può tradursi in una forte limitazione operativa: pur avendo acquistato la licenza per utilizzare il software, egli potrebbe non avere il diritto di accedere al codice sorgente per apportare modifiche o aggiornamenti.
Ad esempio, immaginiamo una piccola impresa che commissiona a un freelance un software gestionale per automatizzare i processi interni. Se il contratto non prevede il trasferimento della proprietà del codice sorgente, l’impresa potrebbe scoprire, anni dopo, di non poter aggiornare il programma per adattarlo a nuove esigenze, a meno di ricorrere al medesimo sviluppatore o di avviare una costosa riscrittura completa del software!
Sembra abbastanza evidente che la mancanza di accesso al codice sorgente può tradursi in situazioni oltremodo problematiche, come l’impossibilità di aggiornamenti rapidi (il committente potrebbe essere bloccato dalla necessità di rivolgersi esclusivamente allo sviluppatore originario, che potrebbe non essere più disponibile o potrebbe richiedere compensi eccessivi per intervenire) o la mancata integrazione con altri sistemi (l’evoluzione tecnologica spesso richiede che il software sia integrato con nuove piattaforme o applicazioni. Senza il codice sorgente, queste modifiche potrebbero risultare impossibili) o ancora il rischio di obsolescenza (un software non aggiornabile rischia di diventare rapidamente obsoleto, compromettendo l’efficienza operativa dell’impresa).
Un esempio emblematico potrebbe riguardare un e-commerce che si affida a un software personalizzato per la gestione degli ordini. Senza il codice sorgente, l’azienda non potrebbe integrare il sistema con una nuova piattaforma di pagamento o adattarlo a cambiamenti legislativi, come le normative sulla fatturazione elettronica.
Per evitare questi scenari, il contratto di sviluppo software dovrebbe regolare chiaramente la proprietà e l’accesso al codice sorgente. Naturalmente è possibile adottare diverse soluzioni a seconda delle esigenze delle parti. Il contratto potrebbe prevedere il trasferimento completo dei diritti patrimoniali sul software, incluso il codice sorgente, al committente (questo è spesso consigliabile quando il software costituisce un asset strategico per l’attività), o in alternativa, lo sviluppatore potrebbe mantenere la proprietà del codice, concedendo al committente una licenza che gli consenta di accedervi e modificarlo, eventualmente con alcune limitazioni, oppure ci si potrebbe porre in una posizione intermedia con il deposito del codice sorgente presso un soggetto terzo fiduciario, che lo rende disponibile al committente solo in caso di specifiche condizioni, come l’inadempimento dello sviluppatore o la cessazione dell’attività.
Volendo tradurre quanto appena affermato in casi pratici, si potrebbe pensare ad un’azienda manifatturiera che potrebbe commissionare un software per monitorare in tempo reale la produzione. Ora, considerando la centralità del sistema per la propria attività, l’impresa potrebbe optare per una cessione completa del codice sorgente, garantendosi la possibilità di intervenire in ogni momento per aggiornamenti o integrazioni future.
Al contrario, una startup che acquista un software CRM da una software house potrebbe accettare una licenza con accesso al codice sorgente limitato, concordando che eventuali modifiche saranno effettuate esclusivamente dallo sviluppatore, ma a costi prefissati.
Insomma, come si può facilmente dedurre da tutto quanto sin qui esposto, la redazione di un contratto di sviluppo software richiede una visione integrata delle normative civili e della legislazione sul diritto d’autore. Tra i suggerimenti utili per le parti coinvolte si segnalano il definire con chiarezza la natura delle obbligazioni (risultato o mezzi), lo stabilire esplicitamente la titolarità dei diritti patrimoniali, il prevedere meccanismi di risoluzione delle controversie agili e non onerosi e l’assicurarsi che il contratto contempli clausole sulla manutenzione e sull’aggiornamento del software.
Un contratto ben strutturato, infatti, non solo tutela le parti, ma facilita il successo del progetto, garantendo un rapporto equilibrato e conforme alle normative vigenti.
Per approfondire:
- W. ROYCE, Managing the development of large software systems, in Proceedings of IEEE WESCON, 26.1, 1970. pp. 1-9;
- L. LESSIG, Code and Other laws of Cyberspace, New York, 1999;
- G. SARTOR, Il diritto della rete globale, in Ciberspazio e diritto, 4, 2003, pp. 67-94;
- G. SARTOR, L'informatica giuridica e le tecnologie dell'informazione, Torino, 2016;
- F. ROMEO, Lezioni di logica ed informatica giuridica, Torino, 2012;
- W.S. MCCULLOCH, W.H. PITTS, A logical calculus of the ideas immanent in nervous activity, 1943;
- A.M. TURING, Computing machinery and intelligence, in Mind, 59, 1950, p. 236 ss.
Nicola Nappi
Ultimi post di Nicola Nappi (vedi tutti)
- Sulle principali criticità del contratto di sviluppo software - 13 Gennaio 2025
- Parere EDPB sull’intelligenza artificiale: trattamento dei dati personali e implicazioni - 18 Dicembre 2024
- Analisi giuridica e peculiarità del reato di frode informatica - 16 Dicembre 2024
- Ruolo e responsabilità del “responsabile del trattamento” nell’ecosistema del GDPR - 9 Dicembre 2024
- La qualificazione giuridica del contratto di licenza d’uso - 2 Dicembre 2024
