Hanno clonato Photoshop con l'IA. È la fine del software come lo conosciamo?

Negli ultimi giorni, nel mio feed, sono comparsi due tipi di titoli. Il primo: “Uno sviluppatore ha clonato Photoshop con l’IA”. Il secondo: “Halo, GTA Vice City e i Simpson girano nel browser grazie all’IA”. Sotto, in entrambi i casi, la stessa domanda angosciata: è finito il software?
Ho letto un po’ di articoli, ho guardato i repository e ho provato a mettere ordine. La mia risposta breve è no. Quella lunga è questo post.
Cosa è successo davvero
I cloni della suite Adobe
Brandon Thomas, sviluppatore di Atlanta, ha pubblicato su GitHub ArtCraft, una famiglia di sette applicazioni open source che rifanno i prodotti principali di Adobe: tra queste PhotoCraft (Photoshop), VectorCraft (Illustrator), FilmCraft (Premiere) e LightCraft (Lightroom). Sono scritte in Rust con l’aiuto di Claude Opus 5.5 e presentate come implementazioni clean room, cioè senza una riga di codice Adobe (Vice, HotHardware).
Il motivo, a sentire lui, è la frustrazione per gli abbonamenti Adobe e le penali di cancellazione, le stesse per cui nel 2024 il Dipartimento di Giustizia americano ha fatto causa all’azienda.
Secondo i numeri riportati in questi giorni, il repository di PhotoCraft ha superato le 50.000 stelle in poco tempo. Ma ha anche più di 800 issue aperte: problemi con i file PSD, crash, gestione del colore rudimentale, consumi di memoria esagerati sulle immagini grandi. Un’analisi tecnica molto lucida l’ha paragonato a una replica di Ferrari montata su un Maggiolino: la carrozzeria è giusta, il motore no (AkitaOnRails).
I giochi nel browser
Quasi negli stessi giorni, Kotaku ha raccontato l’ondata di versioni per browser di giochi come Halo: Combat Evolved, GTA Vice City, The Simpsons: Hit & Run e Call of Duty: Black Ops, ottenute decompilando i giochi originali con l’aiuto dell’IA. Una versione di GTA 5 è diventata virale ed è sparita poco dopo. Gli editori rispondono con le solite diffide e richieste di rimozione, una alla volta.
Due fatti da tenere a mente, perché torneranno utili:
- quali modelli abbiano generato i singoli port non è verificato: l’attribuzione a Claude Opus 5.5 viene dagli articoli, non dagli autori;
- molti di questi port usano mappe, modelli e animazioni dei giochi originali.
Il software si è sempre copiato
La prima cosa che mi viene da dire è: benvenuti nella storia dell’informatica.
- L’interfaccia a finestre nasce nei laboratori Xerox PARC negli anni ‘70. Apple la porta su Lisa e Macintosh, Microsoft su Windows. Apple fa causa a Microsoft e perde (1994): una somiglianza generica di idee non basta.
- VisiCalc inventa il foglio di calcolo nel 1979. Arrivano Lotus 1-2-3, poi Excel, poi Google Sheets. Ognuno copia l’idea del precedente e la migliora.
- Lotus fa causa a Borland perché il suo foglio di calcolo replicava la struttura dei menu di 1-2-3. Nel 1995 la corte d’appello dà ragione a Borland: la gerarchia dei comandi è un “metodo di funzionamento”, non un’opera protetta.
- SQL nasce in IBM, e dopo pochi anni lo implementano Oracle, Microsoft, MySQL, PostgreSQL.
- Più di recente, la Corte Suprema americana ha stabilito che Google poteva reimplementare le API Java in Android (Google contro Oracle, 2021).
Il diritto d’autore protegge il codice (l’espressione), non le idee. Questo per chi vende software è un problema, ma per la disciplina è un vantaggio enorme: l’informatica si muove a una velocità che in settori più blindati, come la farmaceutica, è impensabile.
⚠️ Una precisazione che conta: non è del tutto vero che il software “non si può brevettare”. Negli Stati Uniti i brevetti software esistono, anche se dopo la sentenza Alice (2014) sono più difficili da ottenere. In Europa i programmi “in quanto tali” sono esclusi, ma le invenzioni con un effetto tecnico implementate via software si brevettano eccome. E la tecnica clean room protegge dal copyright, non dai brevetti.
I modelli linguistici, in questo quadro, non inventano niente. Democratizzano un processo che prima richiedeva mesi di lavoro di persone molto specializzate.
Confesso: mentre scrivevo questo articolo ho trovato su uno store di app MCP un progetto chiamato loom, una memoria locale per agenti IA basata su SQLite. Per un attimo ho pensato “mi hanno clonato!” (il mio Loom fa più o meno quello). Poi ho controllato le date: il loro primo commit è di cinque giorni prima del mio. Linguaggio diverso, architettura diversa, stesso nome, stessa idea. Se qualcuno ha copiato, a rigor di calendario, sarei io. Non l’ho fatto: è che nel 2026 l’idea era nell’aria, e quando un’idea è nell’aria la scrivono in tanti, nello stesso momento.
Copiare, reimplementare, decompilare: non sono la stessa cosa
Qui c’è l’equivoco più grosso del dibattito.
Decompilare e ricompilare non è reimplementare. Se prendi il binario di un programma, lo trasformi in codice sorgente (con o senza IA) e lo ricompili, hai ancora il programma di qualcun altro. Il fatto che il codice sia passato per un modello non lo rende tuo. In Europa la decompilazione è ammessa solo in casi stretti, per l’interoperabilità (direttiva 2009/24/CE). Negli Stati Uniti sentenze come Sega contro Accolade (1992) l’hanno considerata uso legittimo per capire come funziona un sistema, non per distribuirne una copia.
Per i giochi il problema è ancora più evidente: un gioco non è solo codice, è grafica, musica, livelli, personaggi. Un port per browser che si porta dietro le mappe e i modelli di Halo distribuisce materiale protetto, punto. Non a caso i progetti seri di questo tipo, come OpenMW per Morrowind, riscrivono il motore e ti chiedono di fornire i file del gioco che hai comprato.
La clean room è un’altra cosa. È una tecnica vecchia (Phoenix la usò nel 1984 per rifare il BIOS dei PC IBM) che separa due gruppi:
- il primo studia il prodotto originale e scrive una specifica del comportamento;
- il secondo, che non ha mai visto l’originale, implementa partendo solo dalla specifica.
Con i modelli linguistici diventa: un’istanza analizza codice, documentazione e comportamento e produce la specifica; un’altra istanza, senza accesso ai log della prima, scrive il nuovo codice. In questo modo si può ricostruire, per esempio, un database compatibile con Redis sotto una licenza diversa, partendo dal comportamento documentato.
Funziona? Probabilmente sì, con due asterischi che vale la pena conoscere:
- il secondo modello non è davvero “pulito”: se l’originale è open source, è molto probabile che sia nei suoi dati di addestramento. È la contestazione nata a marzo sul caso chardet, una libreria Python passata da LGPL a MIT dopo una riscrittura con l’IA (Simon Willison);
- nessun tribunale si è ancora espresso sul fatto che due sessioni dello stesso modello valgano come due squadre separate.
Cosa resta protetto (e cosa no)
Per farla semplice:
| Si può replicare | Rischioso o vietato |
|---|---|
| Le funzionalità (un comando che disegna un cerchio passante per due punti) | Il codice, anche se decompilato e ricompilato |
| Gli algoritmi noti e documentati | L’interfaccia identica: icone, layout, aspetto complessivo |
| Le convenzioni d’uso e le scorciatoie che l’utente si aspetta | Grafica, musica, livelli e personaggi di un gioco |
| I formati dei file, per l’interoperabilità | Marchi e nomi commerciali |
| I linguaggi e le API (Google contro Oracle) | Le tecnologie coperte da brevetto |
Sui formati c’è una sentenza europea che dovrebbero conoscere tutti gli sviluppatori: SAS Institute contro World Programming (Corte di giustizia UE, 2012). Funzionalità, linguaggio di programmazione e formati dei file non sono protetti dal diritto d’autore.
La parte più interessante della tabella, per me, è la terza riga a sinistra. Puoi replicare le convenzioni per non spiazzare chi arriva da Photoshop, e poi cambiare tutto il resto: renderlo più semplice, più veloce, più adatto a un certo tipo di utente. Copiare esattamente, invece, non solo è rischioso: quasi sempre è anche inutile.
Il fossato non è il codice
Qui aggiungo una cosa che negli articoli sui cloni manca quasi sempre.
Gli algoritmi di base di Photoshop non sono segreti: livelli, maschere, metodi di fusione, filtri di convoluzione sono documentati da decenni e i modelli linguistici li conoscono benissimo. Oggi una coppia formata da un grafico esperto e un programmatore può davvero ricostruire, e ripensare, un prodotto complesso.
Ma il valore di Adobe non sta lì. Sta in cose molto meno affascinanti:
- compatibilità con i file: aprire correttamente un PSD di dieci anni fa con cento livelli e gli effetti giusti. Non a caso, è lì che PhotoCraft ha un centinaio di issue aperte;
- gestione del colore e standard di stampa professionali (profili ICC, CMYK, librerie come Pantone);
- modelli e dati proprietari per le funzioni generative, che non si ricavano dal codice;
- ecosistema: plugin, font, librerie condivise, formazione, certificazioni;
- manutenzione: scrivere la versione 1 oggi costa pochissimo, mantenerla per dieci anni costa come sempre. Le 800 issue di PhotoCraft sono esattamente questo.
Nel software molto specializzato, come il montaggio video professionale con modelli neurali e algoritmi complessi, un clone arriva magari al 70%. Al 70% basta alla stragrande maggioranza delle persone, ma gli studi professionali continueranno a comprare l’originale. Perché la vera protezione, lì, è il rapporto business-to-business: nessuna azienda mette in produzione un progetto trovato su GitHub, a meno che non diventi molto popolare e affidabile.
Le grandi aziende hanno smesso di stupire
C’è un fattore di contesto che secondo me spiega metà dell’entusiasmo per questi cloni.
Un tempo ogni nuova versione di Photoshop, di Office o di un sistema operativo era un evento: la si aspettava, se ne parlava, portava idee nuove. Oggi è soprattutto un aggiornamento dell’abbonamento, con qualche funzione di IA aggiunta e un prezzo che sale. Se un utente è disposto a provare un’alpha piena di bug pur di liberarsi di Adobe, il problema non è il reverse engineering: è il rapporto con il cliente.
Le squadre piccole, invece, possono ancora stupire. Con l’IA possono farlo partendo da una base che prima richiedeva anni di lavoro.
Allora è la fine del software?
Per chi vive di software i problemi sono seri, inutile girarci intorno:
- se reimplementare costa poco, meno aziende riusciranno a guadagnare vendendo licenze;
- meno aziende che guadagnano significa meno assunzioni di sviluppatori.
Dall’altra parte c’è un effetto potenzialmente enorme: un accesso molto più ampio a strumenti potenti, flessibili e adattabili alle proprie esigenze. Il fotografo che vuole solo lo sviluppo RAW senza pagare un abbonamento ogni mese, lo studio che vuole un editor su misura per il suo flusso di lavoro, la scuola che non può pagare licenze per cento postazioni.
Nel complesso credo che il saldo possa essere positivo. E l’abbiamo già visto succedere:
- Linux ha spazzato via buona parte degli Unix commerciali, e ha contribuito al declino di Sun, finita poi in Oracle;
- MySQL, PostgreSQL e Redis hanno eroso il mercato dei database e delle cache commerciali;
- PHP e i CMS open source hanno ridotto quasi a zero il mercato degli strumenti per siti web a pagamento.
Molto valore commerciale è stato distrutto, eppure l’industria ne è uscita più grande di prima. Chi è sopravvissuto, come IBM, l’ha fatto restando agganciato ai processi di business e ai grandi contratti, non al codice. Non è detto che vada di nuovo così: questa volta l’esplosione potrebbe essere più grande e più veloce. Ma chi fa un lavoro davvero eccellente, lo spazio lo trova.
Un possibile ritorno all’open source
C’è anche uno scenario che trovo affascinante.
Negli anni ‘90 il lavoro nell’informatica era poco, e molti passavano il tempo libero a scrivere software libero. Paradossalmente, con l’esplosione dei programmatori ben pagati, l’open source “da garage” è diminuito: chi aveva un buon stipendio aveva meno tempo e meno motivi per farlo.
Se l’IA riduce i posti di lavoro, potremmo vedere il movimento opposto: sviluppatori che avviano piccole aziende su software libero, con licenze che permettono comunque di guadagnare attraverso contratti con le aziende, supporto, donazioni e sponsorizzazioni. Il rischio è la dispersione: mille cloni di Photoshop, nessuno davvero finito. Ma la storia di Linux, Blender o Krita dice che, quando un progetto supera una certa soglia, la comunità tende a concentrarsi lì.
Il rischio vero: più leggi, non meno
Le uniche protezioni reali, oggi, sono legali. Il sistema americano e quello europeo, su questo, sono abbastanza simili: le funzionalità si copiano, l’interfaccia identica no. Ma farsi valere costa: servono cause e budget. Le grandi aziende possono permetterselo, il piccolo sviluppatore il cui software viene clonato molto meno.
Ed è qui che vedo il rischio più grande. Quando i meccanismi di un mercato cambiano, chi ci perde chiede regole più rigide: più brevetti, più elementi coperti da copyright, magari divieti specifici per il reverse engineering con l’IA. Sarebbe un passo indietro per un settore che è diventato quello che è proprio perché le idee circolavano liberamente.
Conclusione
Il reverse engineering con l’IA non è un’invenzione dei modelli linguistici: è una pratica vecchia quanto l’informatica, che adesso è alla portata di molte più persone. Filtri di sicurezza o no, esistono modelli aperti e una comunità molto competente: indietro non si torna.
Ma copiare il codice resta illegale, e copiare le idee resta legale come lo è sempre stato. Quello che cambia è il costo della prima versione. E quando la prima versione costa poco, tornano a contare le cose che contavano all’inizio:
- eccellenza e capacità di stupire;
- conoscenza del cliente: un target chiaro, un prezzo ragionevole invece di abbonamenti punitivi, aggiornamenti costanti;
- feedback ascoltati e trasformati in funzionalità utili, in fretta.
Se Adobe ha paura di un’alpha con 800 issue aperte, il problema non è l’IA.
E tu cosa ne pensi? Useresti un clone open source di Photoshop o di Premiere per lavoro, o solo per curiosità? Scrivimelo nei commenti.
Fonti: Vice, HotHardware, AkitaOnRails, Kotaku, Simon Willison sul caso chardet.