Un servizio online che promette di “liberare” il software dai vincoli delle licenze può sembrare una provocazione (e in larga parte lo è…). Il progetto Malus.sh nasce come esperimento dichiaratamente satirico, ma funziona davvero: carichi codice, paghi pochi centesimi e ottieni una riscrittura completa che replica il comportamento del software di partenza senza ereditarne le condizioni legali.
Negli anni ’80 il reverse engineering richiedeva mesi di lavoro umano: oggi bastano modelli di generazione automatica del codice. E il risultato rischia di incidere su un settore che, secondo dati della Linux Foundation, sostiene indirettamente oltre il 70% delle infrastrutture software globali.
Dal BIOS IBM alla clean room moderna
Per capire cosa c’è dietro l’idea del progetto Malus.sh serve tornare al 1982, quando il BIOS IBM PC rappresentava il cuore dei personal computer.
Aziende come Columbia Data Products cercavano compatibilità senza violare il copyright: nacque così il metodo clean room. Una squadra analizzava il comportamento del sistema originale e produceva delle specifiche; un’altra, isolata da qualsiasi esposizione al codice sorgente, implementava una versione funzionalmente equivalente.
Il modello clean room resistette a verifiche legali e contribuì alla nascita del mercato dei PC compatibili: replicare il comportamento di un software può non costituire violazione, a condizione che non siano copiati codice o elementi espressivi protetti, ma la distinzione comunque resta giuridicamente complessa.
Il punto è che, fino a pochi anni fa, quel processo richiedeva tempo, competenze e budget elevati. Oggi, con i LLM (Large Language Models) addestrati su enormi dataset pubblici, la separazione tra analisi e implementazione può essere simulata da agenti software.
Come funziona Malus.sh sul piano tecnico
Malus.sh adotta una versione automatizzata della clean room: un primo agente AI genera specifiche funzionali partendo dal codice originale; un secondo agente produce una nuova base di codice senza accesso diretto all’input iniziale. In pratica si crea una barriera logica tra osservazione e implementazione, replicando il modello storico ma comprimendo tempi e costi.
Il servizio non si limita alla generazione: include test automatici, benchmark e scansioni di sicurezza per individuare vulnerabilità comuni come injection o buffer overflow. Il pricing riflette una logica industriale: circa 0,01 dollari per kilobyte di dipendenze analizzate. Una cifra simbolica, ma sufficiente a dimostrare la sostenibilità economica del modello.
Va detto però che la qualità del codice prodotto dipende fortemente dal modello utilizzato e dal dataset di addestramento. Sistemi simili a Claude o GPT (OpenAI) tendono a generare codice plausibile, ma non sempre coerente con architetture complesse o pattern progettuali avanzati. Il rischio di introdurre bug difficili da scovare resta comunque elevato.
Licenze open source e reinterpretazione tramite AI
I modelli copyleft, basti su licenze libere GNU – come quelle promosse da Free Software Foundation, FSF -, obbligano chi modifica il codice a mantenere le stesse libertà. Licenze come GPL o LGPL garantiscono continuità e collaborazione; altre, come MIT o BSD, risultano più permissive. Per capire la portata della tematica, basti fare riferimento intorno alla polemica avviata da FSF sull’uso della licenza AGPL da parte di ONLYOFFICE.
Con l’uso dell’AI, alcuni sviluppatori sostengono che una riscrittura completa generata automaticamente non costituisca opera derivata. Il caso della libreria Python chardet lo dimostra: una versione riscritta tramite AI è stata rilasciata con licenza MIT, poi modificata in 0BSD dopo le critiche della comunità. La vicenda, tuttavia, non ha prodotto un precedente legale.
Proprio dal punto di vista legale, non esiste ancora una giurisprudenza consolidata sull’output dei modelli generativi. Secondo la valutazione più diffusa, il codice generato non sarebbe coperto da copyright se privo di originalità umana significativa, ma la questione è ancora aperta e varia a seconda della giurisdizione; altri evidenziano che i modelli apprendono da codice esistente, rendendo difficile sostenere una reale indipendenza creativa.
Effetti pratici: manutenzione, sicurezza e debito tecnico
Un clone di un software generato automaticamente con l’AI può funzionare, come dimostra Malus.sh, ma introduce un problema spesso sottovalutato: la manutenzione.
Il software open source non è solo codice scaricabile: i vari progetti fanno perno su un processo continuo fatto di patch, revisione e gestione delle vulnerabilità. Una replica clean room perde tutto questo.
In pratica, chi utilizza una versione generata si ritrova con un progetto isolato: nessun maintainer, nessuna roadmap, nessuna risposta coordinata a nuove vulnerabilità: così, il rischio di accumulare debito tecnico aumenta rapidamente.
Una provocazione che anticipa scenari reali
Malus.sh alla fine nasce come provocazione, ma riflette dinamiche già in atto. Il suo valore non sta tanto nella tecnologia, quanto nel messaggio: il modello economico del software collaborativo potrebbe non reggere l’impatto della generazione automatica.
Chi lavora nel settore lo percepisce chiaramente: da un lato, l’efficienza aumenta; dall’altro, si erodono meccanismi che hanno sostenuto lo sviluppo software per decenni.
Oltretutto, nell’articolo abbiamo parlato essenzialmente di software libero e open source: tuttavia, approcci simili potrebbero essere applicati anche a software proprietario, ma in questo caso entrano in gioco restrizioni legali legate a licenze, reverse engineering e modalità di accesso al codice. In ogni caso, non passerà molto tempo prima di vedere una versione in grado di analizzare un file binario e di generare codice aperto che ne replica il funzionamento.
La sensazione, parlando tra gli addetti ai lavori, è che il problema non sia se questi strumenti saranno effettivamente usati, ma come verranno regolamentati. E, soprattutto, chi ne sopporterà i costi quando qualcosa smetterà di funzionare.