Abstract
Un’impresa incarica un consulente esterno di sviluppare un software modellato sui propri processi. Terminato il progetto, scopre che il consulente sta offrendo una soluzione simile anche a un concorrente. Può impedirglielo?
La risposta dipende da che cosa è stato riutilizzato. Il codice sviluppato per l’impresa, le informazioni riservate e la possibilità stessa di lavorare per un concorrente sono oggetto di tutele differenti. Per ottenere un’esclusiva effettiva non basta aver pagato lo sviluppo: occorre coordinare diritti sul software, divieto di riuso, riservatezza ed eventuale patto di non concorrenza.
Pagare lo sviluppo significa diventare proprietari del software?
La fattura può riportare la voce “sviluppo software”, ma non chiarire se l’impresa abbia acquistato il codice, una licenza d’uso o soltanto l’accesso a un servizio funzionante.
Per il software creato da un dipendente, l’art. 12-bis della legge sul diritto d’autore attribuisce normalmente al datore di lavoro i diritti esclusivi di utilizzazione economica. Quando lo sviluppatore è un consulente esterno, questa regola non si applica automaticamente.
Se il consulente è un lavoratore autonomo, l’art. 4 della legge n. 81/2017 stabilisce che i diritti economici sugli apporti originali realizzati durante l’incarico restano al lavoratore, salvo che l’attività creativa sia prevista come oggetto del contratto e remunerata a tale scopo. Se l’incarico è affidato a una software house, occorre comunque ricostruire con precisione l’oggetto del contratto e il risultato commissionato.
La soluzione più sicura è regolare espressamente:
- quali diritti vengono trasferiti o concessi in esclusiva;
- quali componenti devono essere consegnate;
- chi può modificare, integrare e affidare il software a terzi;
- quali parti restano nella disponibilità dello sviluppatore.
Abbiamo già affrontato diffusamente questi profili negli articoli dedicati alla proprietà del software nei rapporti tra committente e sviluppatore e alla domanda “se il contratto non lo dice, a chi appartiene il codice sorgente?”.
Ai fini della concorrenza, però, sapere chi possiede il codice è soltanto il primo passaggio.
Quale parte del progetto può essere riservata all’impresa?
Un software sviluppato su commissione raramente nasce da zero. Può contenere almeno tre categorie di elementi.
La prima comprende quanto è stato creato specificamente per il cliente: codice personalizzato, documentazione, architetture, modelli di dati, interfacce e regole operative ricavate dai processi aziendali. È il cosiddetto foreground, ossia il risultato nuovo prodotto durante l’incarico.
La seconda comprende il patrimonio preesistente del consulente: librerie, framework, moduli, template, routine e strumenti utilizzati anche in altri progetti. È il background tecnologico. Pretendere la cessione indiscriminata di questi elementi potrebbe impedire al consulente di continuare a svolgere la propria attività e rendere il contratto difficilmente negoziabile.
La terza categoria è formata dai componenti di terzi: software open source, API, servizi cloud, librerie commerciali e altri strumenti soggetti a licenze proprie. Il consulente non può trasferire al cliente diritti più ampi di quelli di cui dispone.
Il contratto dovrebbe quindi contenere una mappa delle componenti. Per ciascuna occorre indicare se viene ceduta, concessa in licenza oppure semplicemente incorporata nel prodotto finale.
Questa separazione serve anche a definire il divieto di riuso. L’impresa può pretendere un controllo molto forte sul codice creato per lei e sulle proprie informazioni, ma non può normalmente appropriarsi delle competenze generali, dei linguaggi di programmazione o degli strumenti preesistenti del consulente.
La proprietà del codice impedisce il riuso per un concorrente?
Non necessariamente.
Il diritto d’autore protegge la forma espressiva originale del programma: in particolare, consente al titolare di vietarne la riproduzione, l’adattamento, la trasformazione e la distribuzione non autorizzati. Può quindi essere invocato se il consulente trasferisce a un concorrente il medesimo codice o ne riprende parti originali rilevanti.
La protezione non si estende però automaticamente alle funzionalità del programma, alle idee, ai principi di funzionamento o al linguaggio utilizzato per realizzarlo. La Corte di giustizia dell’Unione europea lo ha chiarito nella sentenza SAS Institute del 2 maggio 2012: riprodurre le funzioni di un programma senza copiarne la forma espressiva non costituisce, per ciò solo, violazione del diritto d’autore.
Questo significa che un consulente può, in linea di principio, utilizzare la propria esperienza per sviluppare autonomamente un prodotto con funzioni analoghe. La valutazione cambia se, per farlo, copia il codice, riutilizza materiali contrattualmente riservati oppure trasferisce processi e informazioni segrete appresi dal cliente.
La stessa distinzione emerge nel caso del riuso di codice e dati da parte di ex dipendenti, già esaminato nell’articolo “È lecito riutilizzare codice e dati aziendali dopo la fine di un rapporto di lavoro?”. Con un consulente esterno manca però il generale obbligo di fedeltà proprio del dipendente: il perimetro contrattuale diventa ancora più importante.
Divieto di riuso, riservatezza ed esclusiva: quali clausole servono?
L’impresa deve prima stabilire quale risultato vuole ottenere. Sono possibili tre livelli di protezione.
Il primo è il divieto di riutilizzare i risultati dell’incarico. La clausola dovrebbe identificare il codice, la documentazione, le specifiche e gli altri materiali sviluppati per il cliente, vietandone la riproduzione, l’incorporazione o il trasferimento in progetti destinati a terzi. È una protezione più precisa di un generico divieto di concorrenza, perché riguarda beni e risultati determinati.
Il secondo livello protegge informazioni e know-how aziendale. Durante lo sviluppo il consulente può conoscere procedure produttive, politiche di prezzo, dati, criticità organizzative e regole decisionali che non risultano visibili nel codice finale.
In questo caso l’accordo non deve vietare soltanto la divulgazione. Deve vietare anche l’utilizzazione delle informazioni per finalità estranee al progetto. Per essere protette come segreti commerciali ai sensi degli artt. 98 e 99 del Codice della proprietà industriale, le informazioni devono essere realmente segrete, possedere valore economico proprio perché segrete ed essere sottoposte a misure ragionevoli di protezione.
Non basta quindi definire contrattualmente “riservato” qualsiasi contenuto. Servono accessi selettivi, repository controllati, account aziendali, tracciamento delle attività e obblighi di restituzione o cancellazione. Sul funzionamento di questi accordi rinviamo all’approfondimento dedicato agli accordi di riservatezza e alla protezione delle informazioni.
Il terzo livello è una vera clausola di esclusiva o di non concorrenza. Serve quando l’impresa vuole impedire al consulente di lavorare per determinati concorrenti anche senza copiare codice o utilizzare informazioni riservate.
Una restrizione così ampia deve essere costruita con cautela. L’art. 2596 c.c. richiede che il patto limitativo della concorrenza sia provato per iscritto, circoscritto a una determinata zona o attività e non superiore a cinque anni. Nel mercato digitale, la delimitazione per attività, prodotto o categoria di clienti è spesso più significativa di quella puramente geografica.
Una clausola che vieti per sempre al consulente di sviluppare qualsiasi software per qualunque impresa concorrente rischia di essere contestata. È preferibile identificare le attività vietate, i concorrenti o il mercato rilevante, la durata e il momento dal quale opera il divieto. Anche una penale non può rendere valida una restrizione formulata in modo eccessivamente generico.
Che cosa dovrebbe controllare il CFO prima del saldo?
Il CFO non deve necessariamente verificare ogni riga di codice. Deve però assicurarsi che il progetto sia giuridicamente e tecnicamente controllabile.
Prima della firma, il contratto dovrebbe definire i risultati attesi, il procedimento di collaudo e il momento in cui maturano il pagamento e il trasferimento dei diritti. Dovrebbe inoltre separare il codice sviluppato per il cliente dalle componenti preesistenti e indicare tutte le librerie e licenze di terzi utilizzate.
Durante il progetto è opportuno che il codice sia conservato in un repository accessibile all’impresa, o almeno aggiornato periodicamente in un ambiente controllato. Devono essere consegnati anche la documentazione tecnica, le credenziali, le istruzioni per l’installazione e quanto occorre per affidare manutenzione ed evoluzione a un altro fornitore.
Il consulente dovrebbe infine garantire di avere acquisito i diritti necessari dai propri dipendenti, collaboratori e subfornitori. Alla cessazione del rapporto occorre disciplinare la restituzione o cancellazione delle copie, il passaggio di consegne e la continuità operativa. Quando la consegna continuativa dei sorgenti non è possibile, può essere valutato un accordo di software escrow.
L’impresa può quindi impedire al consulente di trasferire ai concorrenti il software e il patrimonio informativo sviluppato per lei, ma deve precisare che cosa intende riservare.
Se vuole evitare la copia del codice, deve acquisire i diritti e vietarne il riuso. Se vuole proteggere processi e informazioni, deve affiancare al contratto misure di segretezza effettive. Se vuole impedire al consulente di lavorare per i concorrenti anche in assenza di copia, deve negoziare una clausola di esclusiva o non concorrenza delimitata e proporzionata.
Data di pubblicazione: 4 Agosto 2026
© Canella Camaiora S.t.A. S.r.l. - Tutti i diritti riservati.
È consentita la riproduzione testuale dell’articolo, anche a fini commerciali, nei limiti del 15% della sua totalità a condizione che venga indicata chiaramente la fonte. In caso di riproduzione online, deve essere inserito un link all’articolo originale. La riproduzione o la parafrasi non autorizzata e senza indicazione della fonte sarà perseguita legalmente.
Arlo Canella
Managing & founding partner, avvocato del Foro di Milano e cassazionista, responsabile formazione e ricerca indipendente dello Studio CC®.