Nelle ultime settimane è salito alla ribalta un progetto pubblicato su GitHub, chiamato REA (Reverse Engineer Anything), la cui notorietà si è intrecciata con la circolazione in rete di alternative gratuite ad alcuni software commerciali, spesso molto costosi.
Ne è nata la falsa rappresentazione secondo cui, grazie all’AI, tali programmi sarebbero stati decompilati e ripubblicati gratuitamente sotto altro nome e, in alcuni casi, persino migliorati.
In realtà, dal punto di vista squisitamente giuridico, un conto è lo strumento di analisi del software, altro è lo sviluppo di veri e propri “cloni”, con conseguenze diverse sul piano normativo.
Indice degli argomenti
REA e cloni software nel reverse engineering con AI
REA è un server MCP (Model Context Protocol, lo standard con cui un assistente AI si collega a strumenti esterni) che consente ad agenti come Claude Code, Codex o Cursor di pilotare i principali software di decompilazione (Ghidra, IDA Pro, Hopper) e di analizzare applicativi sia desktop sia web.
In buona sostanza REA non è una “killer app”, ma raccorda e razionalizza strumenti software in uso da anni con lo scopo di decompilare, comprendere e ricreare.
D’altro canto, il disclaimer del progetto precisa che lo strumento non è in grado di recuperare il codice sorgente originale o di clonare automaticamente un’applicazione e limita l’uso a «ricerca, formazione, interoperabilità e conservazione del software».
Il metodo clean room di ArtCraft
I “cloni” sono, invece, opera dello sviluppatore Brandon Thomas, che con il progetto ArtCraft ha pubblicato in open source suite di produttività per l’ufficio, software di fotoritocco e altre applicazioni scritte in linguaggio Rust, con il contributo determinante di un modello linguistico.
Lo stesso sviluppatore ha precisato che il progetto non è stato realizzato con REA, ma seguendo il metodo della c.d. clean room: il programma originale viene usato e osservato dall’esterno, come farebbe un qualsiasi utente, senza leggerne né disassemblarne il codice, e il nuovo software, scritto in gran parte dall’AI, ne riproduce il funzionamento; i formati dei file sono, invece, ricostruiti sulla base delle specifiche tecniche pubbliche (ad esempio, lo standard OOXML per i documenti di Word).
Allo stato, è lo stesso sviluppatore a stimare che i cloni siano pronti per un uso professionale solo in parte (intorno al 50-60% per le alternative a Excel e Word, meno del 30% per quella ad AutoCAD): non è quindi possibile parlare di vera e propria sovrapponibilità fra il software originale e il suo clone.
In buona sostanza, il diritto deve porsi due interrogativi: fino a che punto sia lecito analizzare un software proprietario e, in caso affermativo, quali siano i limiti dello sviluppo “alternativo” e del modo in cui quest’ultimo può essere presentato al pubblico.
Diritto d’autore e cloni software creati con l’AI
Il programma per elaboratore è tutelato come opera letteraria, in qualsiasi forma espresso purché originale (art. 1 della direttiva 2009/24/CE; art. 2, n. 8, della Legge 633/1941), ma la stessa direttiva esclude espressamente dalla protezione le idee e i principi alla base di qualsiasi elemento del programma, compresi quelli alla base delle interfacce.
Inoltre, la Corte di Giustizia ha stabilito che «non costituiscono una forma di espressione di un programma per elaboratore e non sono, a tale titolo, tutelati dal diritto d’autore sui programmi per elaboratore ai sensi della predetta direttiva né la funzionalità di un programma siffatto né il linguaggio di programmazione e il formato di file di dati utilizzati nell’ambito di un tale programma per sfruttare talune delle sue funzioni» (CGUE, sentenza SAS Institute, C-406/10 del 2 maggio 2012).
Diverso è il discorso per l’interfaccia grafica, difatti la sentenza Bezpečnostní softwarová asociace (C-393/09 del 22 dicembre 2010) ha escluso che essa sia tutelata come programma per elaboratore, ammettendone però la protezione come opera dell’ingegno ai sensi della direttiva 2001/29/CE, se e nei limiti in cui sia frutto di una creazione intellettuale dell’autore e non sia dettata dalla funzione tecnica.
Appare chiaro che chi riproduce ciò che un programma fa, senza riprodurne il codice né gli elementi espressivi dell’interfaccia, non viola il diritto d’autore sul programma: è esattamente su questo principio che si fonda la clean room dichiarata dallo sviluppatore dei cloni.
Reverse engineering con AI nella normativa italiana
Il legislatore europeo, e di riflesso quello italiano, tiene separate due attività: l’osservazione del funzionamento di un programma e la sua decompilazione.
L’art. 64-ter, comma 3, L. 633/1941 (vd. art. 5, par. 3, della direttiva) consente al legittimo utente di osservare, studiare e sottoporre a prova il programma per determinarne le idee e i principi, purché nell’ambito delle operazioni che ha diritto di eseguire; secondo la già citata sentenza SAS Institute, ciò è ammesso anche allo scopo di sviluppare un programma concorrente, a condizione di non accedere al codice e di disporre di una licenza legittima.
La decompilazione è, invece, un’eccezione con margini molto ristretti: l’art. 64-quater L. 633/1941 (art. 6 della direttiva) la ammette solo se indispensabile per l’interoperabilità con un programma creato autonomamente, entro le parti necessarie e quando le informazioni non siano già accessibili; le informazioni così ottenute non possono, in ogni caso, servire a sviluppare un programma sostanzialmente simile nella sua forma espressiva.
La Corte di Giustizia ha poi ammesso la decompilazione anche per correggere gli errori che incidono sul funzionamento del programma (cfr. Sentenza CGUE Top System, C-13/20 del 6 ottobre 2021).
Applicando tali principi a REA, è possibile individuare i due confini: decompilare, ad esempio, Photoshop o AutoCAD per replicarne le funzioni in un prodotto concorrente è vietato; restano, invece, lecite la decompilazione necessaria per rendere interoperabile un proprio programma (ad esempio, per leggere un formato proprietario non documentato), quella volta a correggere errori e quella autorizzata dal titolare, come avviene nelle analisi di sicurezza svolte su incarico.
Cloni software tra segreti commerciali, marchi e interfacce
Anche se l’aspetto prevalente riguarda il diritto d’autore, la questione chiama in causa ulteriori discipline, che in questa sede è possibile solo accennare.
Ad esempio, la disciplina dei segreti commerciali (direttiva UE 2016/943, recepita negli artt. 98 e 99 del Codice della proprietà industriale, d.lgs. 30/2005, di seguito c.p.i.) considera lecito scoprire un segreto altrui studiando o smontando un prodotto acquistato regolarmente, a meno che non sia espressamente vietato da una clausola contrattuale; tuttavia, nel caso del software, la clausola di licenza che vieta il reverse engineering è nulla ai sensi della direttiva 2009/24/CE e, pertanto, non può essere invocata neppure per tutelare il segreto commerciale.
Sul piano dei marchi, il primo presidio è l’uso di nomi propri, diversi da quelli dei prodotti imitati; inoltre, chi presenta il proprio programma come «alternativa a» un software noto può citarne il marchio solo in modo corretto e veritiero (art. 21 c.p.i.) e senza presentarlo come una sua imitazione, come vietato in materia di pubblicità comparativa: uno slogan del tipo “Free Photoshop” sarebbe comunque esposto al rischio di un’inibitoria anche se il codice fosse stato scritto lecitamente.
Infine, l’aspetto grafico del programma (icone, disposizione di menu e pannelli) può essere protetto autonomamente rispetto al codice, sia come opera dell’ingegno (sentenza BSA) sia, dopo il Regolamento (UE) 2024/2822, come disegno industriale: copiare l’aspetto dell’originale può essere illecito anche quando le funzioni sono state riprodotte in modo legittimo.
Reverse engineering con AI: profili penali e responsabilità
L’art. 171-bis comma 1 L. 633/1941 punisce con la reclusione da sei mesi a tre anni e con la multa chi abusivamente duplica, per trarne profitto, programmi per elaboratore o ai medesimi fini li distribuisce, vende o detiene a scopo commerciale, nonché chi tratta mezzi intesi unicamente a consentire la rimozione o l’elusione dei dispositivi di protezione.
La reimplementazione clean room non integra la fattispecie, per la semplice ragione che manca la duplicazione del programma altrui; diverso è il caso di chi decompili un programma e ne redistribuisca il codice, anche rielaborato, in forma derivata.
Né la gratuità della distribuzione esclude, di per sé, il fine di profitto, che la giurisprudenza intende in senso ampio e comprensivo di vantaggi indiretti: un progetto open source che alimenti un’attività commerciale, raccolte di fondi o servizi a pagamento potrebbe essere ritenuto dal giudice riconducibile alla fattispecie incriminatrice testé citata.
Quanto a REA, trattandosi di uno strumento che coordina diversi decompilatori, esso si presta a numerosi usi leciti (sicurezza informatica, interoperabilità, ricerca); la responsabilità dello sviluppatore per gli illeciti commessi dagli utenti andrebbe, quindi, ricostruita secondo le regole generali del concorso di persone nel reato, che richiedono un contributo causale a uno specifico illecito e la prova del dolo, assai difficile da raggiungere.
Responsabilità degli enti e codice generato dall’AI
Per i soggetti economici, poiché l’art. 171-bis L. 633/1941 è reato presupposto della responsabilità degli Enti ai sensi dell’art. 25-novies del d.lgs. 231/2001, una società che integri nei propri prodotti codice ottenuto mediante decompilazione illecita -magari eseguita da un agente AI su iniziativa di un singolo sviluppatore- si espone a sanzioni pecuniarie e interdittive.
I modelli organizzativi andrebbero, quindi, aggiornati con regole specifiche sull’uso degli strumenti di analisi agentica e sulla provenienza del codice generato dall’intelligenza artificiale.
Clean room assistita dall’AI e futuro del software
Il caso REA – ArtCraft dimostra che lo strumento di analisi esiste ed è molto sofisticato, mentre i cloni, pur esistendo, sono stati sviluppati -secondo quanto dichiarato- senza decompilare il codice protetto dal diritto d’autore e restano ancora lontani dalla parità con gli originali.
Certamente, però, quando il legislatore eurounitario ha consentito (nei limiti già esposti) il reverse engineering di un software anche complesso, non poteva immaginare che la tecnologia sarebbe arrivata ad abbattere i costi dell’operazione.
Software in abbonamento e tutela dei professionisti
Un approccio meramente repressivo sarebbe, tuttavia, controproducente (anche perché finirebbe per limitare, ad esempio, la ricerca sulla sicurezza informatica); sarebbe piuttosto opportuno disciplinare la pratica della clean room assistita dall’AI, prevedendo obblighi di trasparenza sulla provenienza del codice generato.
È anche per questi motivi che le software house potrebbero, in un futuro neppure così lontano, spostare le proprie soluzioni esclusivamente sul cloud, costringendo di fatto l’utente a pagare “a vita” per un software che prima poteva far funzionare su una macchina, anche obsoleta, e che svolgeva egregiamente il suo lavoro: da questo punto di vista, il legislatore europeo dovrà disciplinare il mercato del software in abbonamento, tutelando, oltre ai consumatori (già in parte protetti dalla direttiva UE 2019/770 sui contenuti e servizi digitali), anche i piccoli professionisti (es. grafici, architetti, studi di registrazione), che difficilmente potrebbero sostenere un costo ricorrente a tempo indeterminato.
Fonti normative e riferimenti
- Direttiva 2009/24/CE; direttiva (UE) 2016/943; Regolamento (UE) 2024/1689 (AI Act); Regolamento (UE) 2024/2822;
- Legge 633/1941;
- CGUE, C-393/09 del 22/12/2010; C-406/10 del 02/05/2012; C-13/20 del 06/10/2021;
- https://github.com/morluto/rea;
- https://www.eigent.ai/blog/rea-reverse-engineer-anything;
- https://decrypt.co/380741/gta-v-iphone-free-photoshop-ai-tool-rea-upending-software;
- https://iamag.it/blog/reverse-engineering-ai-agenti-clonano-software;
- https://btl-blog.com/2026/10/14/ai-cloned-adobe-is-cad-next/.




























Partecipa alla community