Abstract
Il reverse engineering non è sempre illecito. L’articolo chiarisce quando l’analisi tecnica è consentita e quando diventa contraffazione, distinguendo tra brevetti, software e informazioni riservate.
Cos’è il reverse engineering?
Il reverse engineering è l’insieme di tecniche con cui si parte da un prodotto finito – fisico o digitale – per risalire a come è fatto, come funziona e, soprattutto, quali scelte tecniche lo rendono replicabile.
Nel mondo fisico significa acquistare un oggetto, smontarlo, misurarlo, analizzarne materiali e tolleranze, fino a ricostruire disegni e processi produttivi.
Nel mondo digitale significa osservare come un software o un dispositivo reagisce a determinati input, analizzarne file, aggiornamenti, protocolli e comunicazioni, fino ad arrivare, nei casi più spinti, alla decompilazione del codice. L’obiettivo è ricostruire regole e logiche di funzionamento, ottenendo un comportamento equivalente o, talvolta, il codice sorgente stesso.
Accanto a queste due dimensioni, ce n’è una terza, spesso la più sottovalutata: quella delle informazioni “invisibili” che definiscono il valore aggiunto intrinseco dell’impresa (in questo senso, si veda anche La valutazione economica del Know-How: Il valore del “Saper Fare”).
In questo caso il reverse engineering non guarda più al prodotto in sé, ma agli output dell’azienda: risultati, prestazioni, report, configurazioni, prezzi, tempi, qualità.
Attraverso confronti e test ripetuti, si tenta di risalire all’informazione interna che genera quegli output. Non è necessario accedere fisicamente al prodotto, smontare un oggetto o decompilare un programma. È l’ingegneria inversa applicata ai processi decisionali e organizzativi: si copia il modello.
In Italia non esiste una normativa specifica dedicata al reverse engineering. Per stabilire quando questa attività sia lecita e quando invece no, non basta un’etichetta astratta: occorre analizzare il caso concreto e, soprattutto, la natura del bene o dell’informazione oggetto di ingegneria inversa.
Reverse engineering e brevetti: quando l’analisi è lecita e quando diventa contraffazione
Quando il reverse engineering ha ad oggetto un prodotto industriale, il primo discrimine giuridico riguarda l’esistenza o meno di una tutela brevettuale. È da qui che cambia radicalmente il perimetro di liceità dell’analisi tecnica.
In assenza di brevetto, l’ingegneria inversa di un prodotto acquistato lecitamente sul mercato tende, in linea generale, a collocarsi in un’area più ampia di liceità. L’osservazione, lo studio, lo smontaggio e le prove sul bene possono condurre alla comprensione del suo funzionamento e,
in alcuni casi, alla ricostruzione delle scelte tecniche adottate.
La Direttiva (UE) 2016/943, nei considerando 16 e 17, chiarisce infatti che l’ingegneria inversa di un prodotto acquisito lecitamente costituisce, in via generale, una modalità lecita di acquisizione delle informazioni, ferma restando la possibilità di limitare tale attività attraverso vincoli contrattuali.
Il quadro muta sensibilmente quando il prodotto è coperto da brevetto. In questo caso entra in gioco l’esclusiva riconosciuta al titolare, che comprende il diritto di vietare a terzi la produzione, l’uso e la commercializzazione dell’invenzione. Tuttavia, anche in presenza di un brevetto, il reverse engineering non è vietato in modo assoluto.
L’analisi del prodotto brevettato può infatti essere funzionale a un’attività lecita di design around, ossia alla progettazione di una soluzione alternativa che eviti l’ambito di protezione del brevetto. Il punto critico non è l’osservazione o lo studio del prodotto, ma il risultato finale dell’attività.
Per stabilire se vi sia violazione del brevetto non è sufficiente un confronto meramente visivo o funzionale tra i prodotti. Il giudizio di contraffazione richiede di rapportare il prodotto asseritamente contraffatto alle rivendicazioni del brevetto, che definiscono l’estensione giuridica della tutela, e può estendersi anche a soluzioni ritenute tecnicamente equivalenti.
«In tema di contraffazione di brevetti per invenzione industriale, il giudice, nel determinare l’ambito della protezione conferita dal brevetto, non deve limitarsi al tenore letterale delle rivendicazioni, ma deve interpretarle alla luce della descrizione e dei disegni…»
Il criterio degli equivalenti comporta che la tutela brevettuale possa estendersi oltre il dato formale, ma non in modo illimitato. L’esigenza di proteggere l’inventore deve infatti essere bilanciata con quella di garantire ai terzi un margine di libertà progettuale. È in questo spazio che si colloca il design around lecito, e dove il reverse engineering svolge una funzione essenziale di conoscenza tecnica del perimetro di esclusiva.
In sintesi, quando il reverse engineering incontra un brevetto, la liceità dell’attività non dipende dall’analisi in sé, ma da ciò che viene fatto dopo. Studiare un prodotto brevettato per comprenderne il funzionamento è, di per sé, possibile; realizzare e immettere sul mercato una soluzione che ricada, anche per equivalenza, nell’ambito di protezione del brevetto espone invece al rischio di contraffazione.
Reverse engineering e software: tra osservazione lecita e limiti invalicabili
Quando il reverse engineering riguarda un software, il quadro giuridico è diverso. Nella maggior parte dei casi non è in gioco una tutela brevettuale, ma la protezione autorale del programma per elaboratore. Questo comporta un cambio di prospettiva decisivo: ciò che l’ordinamento tutela non è la funzione in quanto tale, ma la forma espressiva del programma, ossia il codice (approfondisci: Gli strumenti di tutela legale del software – Canella Camaiora).
Nel linguaggio tecnico si parla spesso di analisi “black box” e analisi “white box”. Questi termini non hanno un significato giuridico autonomo, ma sono utili per descrivere dove si colloca l’attività di reverse engineering rispetto al software.
Con analisi black box si intende l’osservazione del software dal suo comportamento esterno: input, output, risposte del sistema, funzionalità visibili, logiche operative deducibili dall’uso. L’analisi resta confinata a ciò che il programma fa, senza accesso diretto alla sua struttura interna.
Con analisi white box, invece, si indica l’attività che guarda all’interno del programma: lettura del codice sorgente, decompilazione, traduzione del codice oggetto in forma intelligibile, ricostruzione dell’architettura e delle scelte espressive del software.
La distinzione è descrittiva, non normativa. È la legge a stabilire quali atti siano consentiti e quali no, indipendentemente dalle etichette.
Da un lato, l’ordinamento consente ciò che, in termini tecnici, viene spesso ricondotto alla black box analysis. Chi è legittimamente in possesso di una copia del software può osservare, studiare e sottoporre a prova il funzionamento del programma, allo scopo di determinare le idee e i principi su cui esso è basato, purché tali attività avvengano nel contesto delle normali operazioni di utilizzo (art. 64-ter, comma 3, LDA). In concreto, è lecito analizzare come il software reagisce a determinati input, quali risultati produce, quali funzionalità offre e con quali logiche operative, senza accedere al codice.
Questa possibilità risponde a una precisa scelta di sistema. La Corte di Giustizia dell’Unione europea ha chiarito che estendere la tutela autorale alle funzionalità in quanto tali equivarrebbe a proteggere le idee, con effetti distorsivi sulla concorrenza. In particolare, ha affermato che:
«Ammettere che la funzionalità di un programma per elaboratore possa essere tutelata dal diritto d’autore equivarrebbe a consentire la monopolizzazione delle idee, a discapito del progresso tecnico e dello sviluppo industriale.»
(CGUE, Grande Sezione, 2 maggio 2012, causa C-406/10, SAS Institute Inc. c. World Programming Ltd.)
È su questa base che l’analisi black box del software, intesa come osservazione del comportamento, rientra nella normale dinamica concorrenziale.
Diverso è il caso dell’analisi white box, che implica un accesso alla forma espressiva del programma. La lettura, la traduzione o la ricostruzione del codice sorgente o del codice oggetto rientrano nella sfera della riproduzione dell’opera, riservata al titolare dei diritti. Per questo la legge ammette la decompilazione solo in via eccezionale e a condizioni rigorose (art. 64-quater LDA).
La decompilazione è consentita esclusivamente quando sia indispensabile per ottenere le informazioni necessarie a conseguire l’interoperabilità di un programma creato autonomamente con altri programmi. Deve inoltre essere limitata alle parti strettamente necessarie e le informazioni ottenute non possono essere utilizzate per scopi diversi, né per sviluppare o commercializzare un software sostanzialmente simile nella sua forma espressiva.
Ne deriva un confine netto: l’analisi black box del comportamento del software è, in linea generale, lecita; l’analisi white box della sua struttura interna è, di regola, vietata, salvo le eccezioni previste dalla legge.
In questo contesto, le clausole contrattuali contenute nelle licenze o negli EULA possono incidere sulle modalità di utilizzo del software, ma non alterano il quadro di fondo: l’ordinamento consente l’osservazione del funzionamento del programma e tutela la sua forma espressiva. Il reverse engineering del software non è quindi illecito in quanto tale, ma diventa problematico quando dall’osservazione del comportamento si passa all’accesso al codice.
Reverse engineering e informazioni riservate: quando il problema non è copiare, ma proteggere
Il livello più delicato del reverse engineering riguarda la ricostruzione di informazioni interne e procedure operative che spiegano gli output di un’impresa e ne costituiscono il vantaggio competitivo. È il terreno del know-how, dove il confine tra concorrenza lecita e appropriazione indebita è particolarmente sottile.
A differenza dei brevetti e del software, qui non esiste una privativa formale che delimiti ex ante ciò che è vietato. La tutela delle informazioni riservate è affidata agli artt. 98 e 99 del Codice della Proprietà Industriale, che subordinano la protezione alla presenza congiunta di tre requisiti:
- la segretezza delle informazioni
- il loro valore economico in quanto segrete
- l’adozione di misure ragionevolmente adeguate a mantenerle tali.
Solo se questi presupposti sono soddisfatti il “reverse engineering” può trasformarsi in illecito.
In questo ambito, l’ingegneria inversa presenta una natura duale. Da un lato, può costituire una condotta illecita quando è utilizzata per appropriarsi di informazioni che l’impresa ha effettivamente mantenuto segrete e protetto in modo coerente. Dall’altro, può diventare uno strumento di verifica ex post della tenuta stessa del know-how rivendicato.
Quando un concorrente riesce a ricostruire facilmente, a partire dagli output disponibili sul mercato, le informazioni che un’impresa qualifica come riservate, il problema non è solo l’eventuale abuso, ma la sussistenza dei requisiti di tutela. Se le informazioni risultano agevolmente acquisibili, per un esperto del settore, attraverso l’analisi del prodotto, del servizio o dei risultati ottenuti, viene meno il presupposto della segretezza effettiva o quello delle misure adeguate di protezione.
La giurisprudenza ha chiarito questo punto in modo netto, riconoscendo che il reverse engineering può essere utilizzato dal giudice come criterio negativo per valutare la proteggibilità delle informazioni.
In particolare, è stato affermato che, laddove le informazioni siano ricostruibili senza particolari difficoltà attraverso l’analisi di ciò che è esposto al mercato, non può dirsi soddisfatto il requisito delle misure adeguate di protezione e, di conseguenza, non può configurarsi un illecito per violazione del know-how (approfondisci: Cos’è il know-how e come si tutela? – Canella Camaiora).
Questo passaggio ribalta una convinzione diffusa: non tutto ciò che è interno è automaticamente riservato. La tutela non discende dalla natura dell’informazione, ma dal modo in cui essa viene stata gestita nel tempo.
In assenza di brevetti o di una tutela autorale, il vantaggio competitivo dell’impresa vive nella capacità di rendere non immediatamente decifrabile il proprio modello operativo. Quando tale opacità viene meno – perché le informazioni sono facilmente deducibili dagli output o perché le misure di protezione sono state trascurate – il reverse engineering rientra nella normale dinamica concorrenziale.
Ne deriva una conseguenza operativa spesso sottovalutata: il contenzioso sul know-how non si vince dimostrando che un concorrente ha “capito come si fa”, ma dimostrando che non avrebbe potuto capirlo senza accedere illegittimamente a informazioni riservate.
Per questo la tutela delle informazioni riservate non può limitarsi a dichiarazioni di principio o a clausole generiche. Richiede una gestione coerente della segretezza: controllo degli accessi, compartimentazione delle informazioni, tracciabilità, limitazione della diffusione e coerenza tra ciò che si dichiara segreto e ciò che viene effettivamente esposto al mercato.
In mancanza di queste cautele, il reverse engineering non distrugge il know-how.
Ne rivela semplicemente la fragilità
© Canella Camaiora S.t.A. S.r.l. - Tutti i diritti riservati.
Data di pubblicazione: 5 Febbraio 2026
È 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.
Gabriele Rossi
Laureato in giurisprudenza, con esperienza nella consulenza legale a imprese, enti e pubbliche amministrazioni.