Fra il 3 e il 12 ottobre sono successe tre cose che, messe in fila, raccontano la stessa storia.

REA, «Reverse Engineer Anything», è passato da meno di 10.000 stelle su GitHub il 6 ottobre a oltre 100.000 il 12, con otto release in nove giorni. Il 9 ottobre GTA V è partito nativo su iPhone, una cosa che nemmeno Rockstar aveva tentato. Il 12 Brandon Thomas ha pubblicato ArtCraft: una suite gratuita e open source, scritta in Rust con Claude Opus 5.5, che imita Photoshop, Illustrator, Premiere e Lightroom.

Metodi diversi. Stesso principio: un agente che ricostruisce il software di qualcun altro. Non è un caso che sia successo tutto nella stessa settimana.

La domanda che è girata ovunque è se il SaaS sia morto. Provo a rispondere in quattro passaggi: cosa sta succedendo davvero, cosa fanno questi strumenti, cosa rischi se cloni un'app, e quanto ti conviene farlo anche quando è lecito.

Il SaaS è morto?

Il termine «SaaSpocalypse» è di febbraio 2026. La scintilla, raccontano, è stata Claude Cowork con un plugin legale, e la tesi dietro si chiama seat compression: se un agente fa il lavoro di più persone, il prezzo a posto di un software crolla, perché i posti diminuiscono.

Satya Nadella l'aveva detto già a dicembre 2024: le applicazioni aziendali sono «data store con regole sopra», e quelle regole si sposteranno in un livello di AI. È una previsione, non un fatto. Ma dice dove guardare.

Il caso che tutti citano è Klarna, che ad agosto 2024 ha annunciato di aver chiuso Salesforce e di dismettere Workday. Raccontato così sembra la prova. In realtà per HR e CRM Klarna ha preso altri SaaS. Non si è rifatta tutto in casa: ha cambiato fornitore.

Chi dice che il SaaS non muore ha un argomento serio: muore il SaaS generico, restano i system of record. Quelli che compri non per le funzioni ma per la fiducia, l'audit, il fatto che se qualcosa va storto la responsabilità è di qualcun altro.

Io la domanda la farei diversa. Non «il SaaS è morto?», ma: quello che fai tu, un'AI lo può rifare?

Se la risposta è sì, il tuo vantaggio competitivo non è più il software. Sono i dati. Il codice si ricostruisce. Quello che i tuoi clienti hanno accumulato dentro il tuo prodotto, no.

C'è un dettaglio che rende la cosa ancora più scomoda per chi vende software: la legge quei dati li vuole già portabili. L'articolo 20 del GDPR dà all'utente il diritto di riprendersi i propri dati in un formato strutturato e leggibile da una macchina, ed è nato proprio contro il lock-in. Se il software si rifà in un weekend e i dati si esportano per legge, cosa ti tiene un cliente?

Non è una dinamica nuova. In economia ha un nome, distruzione creatrice: il profitto di chi innova è una rendita temporanea di monopolio, che dura finché gli imitatori non arrivano. L'AI non ha inventato gli imitatori. Ha accorciato il tempo che ci mettono ad arrivare.

Cosa fa davvero REA, e cosa no

Su REA si è letto di tutto, compreso che avrebbe «duplicato tutte le app a pagamento». Non è così, e lo dice il suo stesso README: il progetto «does not claim to recover original source code or automatically clone an application».

REA è un server MCP, cioè un connettore che dà a un agente di coding (Claude Code, Codex, Cursor, Gemini CLI) l'accesso ai decompilatori: Ghidra, Hopper, IDA. Un decompilatore parte dal programma installato e risale a una rappresentazione leggibile della sua logica. Quello che ottieni è pseudocodice e la mappa di come i moduli si parlano. Non il sorgente originale.

Il punto tecnico che conta è dove sta la logica. Se un'app fa quasi tutto sul tuo dispositivo, come molte app desktop in Electron e molte app mobile, il binario contiene quasi tutto, e un agente con un decompilatore può ricostruirne parecchio. Se il prodotto vive sul server, sul tuo computer arriva solo l'interfaccia. L'autore di REA stima il rischio alto per le prime e basso per le seconde, circa 70 a 30. È una stima sua, ma la logica regge: dal binario non esce quello che il binario non contiene.

E ArtCraft? Non è stato fatto con REA. Thomas lo chiama clean-room rebuild: niente codice Adobe, solo documentazione pubblica, il formato PSD scritto dalla sua specifica, e il comportamento delle app osservato da fuori. È il metodo opposto, con lo stesso risultato: un'alternativa a un prodotto che costa caro. Thomas dice di averlo fatto perché stanco della penale di recesso di Adobe.

Ed è in alpha. Un pixel artist ha definito il clone di Photoshop inutilizzabile, e la roadmap del progetto dichiara una parità sotto il 50%. La morte del SaaS, oggi, è una alpha. Ma esiste, e un anno fa no.

Utile o dilettevole

Qui arriva la domanda che quasi tutti saltano: anche se puoi, ti conviene?

Ricostruirti l'intera suite di Office è utile, magari, per i tuoi usi personali. Creare un intero ecosistema da zero ha senso fino a un certo punto. Oltre quel punto, ogni pezzo che ti rifai è un pezzo che mantieni tu: gli aggiornamenti, i bug, la sicurezza, il formato che cambia.

Io mi sto costruendo un IDE su misura. Il motivo è banale: per tenere aperti i tre tool che uso consumo 6 GB di RAM, e voglio un'app sola che faccia quello che mi serve dei tre.

È esattamente il caso in cui la tentazione è forte. E allora ho fatto l'esercizio fino in fondo.

L'ipotesi: decompilo tre app e me ne faccio una

Mettiamo che usi REA per decompilare i tre tool, prenda le funzioni che uso di ciascuno e le metta in un'app mia. Non la distribuisco, non la vendo, gira solo sul mio computer. A cosa vado incontro?

Premessa: non sono un avvocato. Quello che segue l'ho letto sul testo delle norme, ed è il quadro europeo e italiano.

Le idee sono libere, il codice no. La direttiva europea sui programmi per elaboratore (2009/24/CE) protegge l'espressione di un programma, non le idee e i principi su cui si basa. La Corte di giustizia l'ha messo nero su bianco nel 2012, nel caso SAS Institute contro World Programming: le funzionalità di un programma, il suo linguaggio e il formato dei suoi file non sono protetti. Rifare quello che un'app fa, senza toccarne il codice, è lecito.

Decompilare spetta a chi ha i diritti. L'articolo 4 della direttiva riserva al titolare la riproduzione del programma, anche parziale e temporanea, e ogni sua traduzione o modifica. Decompilare è entrambe le cose.

«Lo faccio per studio» non basta. L'articolo 5, paragrafo 3, permette a chi ha diritto di usare il programma di osservarlo, studiarlo e sperimentarne il funzionamento, per capirne idee e principi. Ma mentre fa le operazioni che ha il diritto di fare: caricarlo, eseguirlo, visualizzarlo. Studiare un'app usandola sì. Aprirla no.

L'unica eccezione vieta proprio il mio caso. L'articolo 6 consente la decompilazione senza autorizzazione per un motivo solo: l'interoperabilità, cioè far parlare un tuo programma con quello altrui. E a condizioni strette: lo fa chi ha la licenza, le informazioni non sono già disponibili, ci si limita alle parti necessarie. Il paragrafo 2 aggiunge che quelle informazioni non possono servire a creare un programma sostanzialmente simile. In Italia è l'articolo 64-quater della legge sul diritto d'autore, con lo stesso divieto.

C'è un secondo spiraglio, ed è stretto anche lui. Nel 2021, nel caso Top System, la Corte di giustizia ha detto che chi ha acquistato legittimamente un programma può decompilarlo per correggerne gli errori. Correggere un bug, non rifare il prodotto.

«Tanto è per me» non è un'esenzione. In Italia l'articolo 174-ter della legge sul diritto d'autore punisce chiunque utilizzi abusivamente un'opera protetta con una sanzione amministrativa di 154 euro, fino a 5.000 nei casi gravi o recidivi. Se c'è un fine di profitto diventa reato: l'articolo 171-bis prevede da sei mesi a tre anni per chi duplica abusivamente un programma «per trarne profitto». La Cassazione ha letto quel profitto in senso ampio, non solo come guadagno di denaro. Se il risparmio di una licenza per un uso puramente personale basti a farlo scattare, la giurisprudenza non lo dice in modo netto. Ed è una zona grigia, non un alibi.

La licenza conta. Quasi ogni software arriva con un contratto di licenza, e molti vietano il reverse engineering. La direttiva dichiara nulle solo le clausole che vietano l'interoperabilità, la copia di riserva e lo studio dell'articolo 5. Il resto del divieto regge, e violarlo è un inadempimento contrattuale. Lo stesso vincolo ti toglie anche l'ultima difesa: la direttiva sui segreti commerciali (2016/943) considera lecito smontare un prodotto che possiedi legittimamente, salvo che un vincolo valido lo vieti. La licenza è quel vincolo.

E no, non posso dare la colpa all'agente. L'AI Act non si applica a chi usa un sistema di AI per un'attività puramente personale e non professionale (articolo 2, paragrafo 10). Vuol dire che non mi carica obblighi, ma anche che non mi protegge: la violazione del diritto d'autore resta mia, chiunque abbia materialmente scritto il codice. L'agente è lo strumento. Il responsabile sono io.

Se un giorno lo distribuisco, cambia tutto. La distribuzione al pubblico è un altro diritto riservato al titolare, e mettere in circolazione copie illecite è proprio ciò contro cui la direttiva chiede misure agli Stati. Se poi lo vendessi come prodotto, dal dicembre 2027 entrerei anche negli obblighi del Cyber Resilience Act, che riguarda il software messo sul mercato in un'attività commerciale.

Il costo che non sta in nessuna legge

Anche togliendo il diritto, resta la parte che mi preoccupa di più da sviluppatore.

Il codice decompilato non si aggiorna. Ogni falla che il produttore chiude, nella mia copia resta aperta. Quando compri un SaaS paghi anche questo: qualcuno che patcha al posto tuo, ogni settimana.

Il codice generato non è sicuro per default. Uno studio di IOActive di aprile 2026, su 730 prompt e 27 modelli, ha trovato il 31,6% di campioni completamente sfruttabili. La Cloud Security Alliance ha misurato che i commit scritti con l'AI espongono segreti, come chiavi e password, nel 3,2% dei casi, contro l'1,5% di quelli scritti a mano. Un'app ricostruita da un agente eredita questi numeri, e non c'è un team di sicurezza dietro.

La febbre attira gli avvelenatori. Pochi giorni dopo il boom di REA girava già un falso installer Windows del tool, con dentro un malware. Chi corre a clonare scarica in fretta, e chi scarica in fretta è il bersaglio migliore.

Esci da una catena, ma resti solo. Un attacco alla supply chain colpisce un fornitore per arrivare a tutti i suoi clienti, ed è il motivo per cui conviene all'attaccante. Rifarti uno strumento ti toglie da quella catena. Ma ti toglie anche chi la presidia.

E i dati sono tuoi, nel senso peggiore. Se il tool tratta dati personali, anche solo i contatti di un cliente, il titolare del trattamento sei tu. Privacy by design e misure di sicurezza adeguate, gli articoli 25 e 32 del GDPR, le devi dimostrare tu, non un fornitore con una certificazione.

Lecito non vuol dire giusto

L'ultima domanda non la risolve nessuna norma.

La proprietà intellettuale esiste per remunerare chi investe in ricerca e sviluppo: un monopolio temporaneo, in cambio del rischio. Se l'investimento non si recupera, il prodotto dopo non si fa.

Ma l'imitazione è anche il motore del mercato. Schumpeter non la chiamava furto. È come il mercato seleziona chi resta.

ArtCraft è il caso comodo. Rifà Adobe, è gratis, e chi l'ha fatto ha un motivo che molti condividono: a marzo Adobe ha chiuso un accordo da 150 milioni di dollari con il Dipartimento di Giustizia americano, che l'accusava di nascondere le penali di recesso, negando ogni illecito. Contro Adobe non si scandalizza nessuno.

La domanda vera è se lo stesso gesto resta giusto quando dall'altra parte c'è uno sviluppatore indipendente, con un'app da pochi euro e due anni di lavoro dentro. Clonare Salesforce non toglie niente a nessuno che se ne accorga. Clonare quell'app gli toglie il prodotto.

Quello che resta

Il SaaS non muore perché un agente sa decompilare. Muore il SaaS che vendeva solo codice, perché il codice è diventato la parte facile da rifare.

Quello che resta difendibile è ciò che dal binario non esce: i dati, la fiducia, qualcuno che si prende la responsabilità quando qualcosa si rompe.

E per chi, come me, è tentato di rifarsi gli strumenti: il modo pulito c'è. Guardare come si comporta un'app e rifarne le funzioni da zero è lecito. Aprirla no.

Un agente ti rifà il software in un weekend. Non ti rifà i dati, e non te lo mantiene.