Nella sua newsletter, Simon Willison racconta di un caso interessante he riguarda le reimplementazioni di codice. L’esempio tipico, raccontato anche nel suo post, è stato quando Compaq ha preso un gruppo di sviluppatori per disassemblare il BIOS dei PC IBM e scrivere un documento di specifiche relative; il documento è stato dato a un altro gruppo di sviluppatori che hanno creato un BIOS compatibile ma senza problemi di copyright, perché a essere copiate sono state le funzionalità e non il codice. Questa metodologia si chiama in gergo “clean room”, come le camere pulite dove si costruiscono (costruivano? io me le ricordo a fine anni ’80…) i chip, perché non c’è nessuna contaminazione. Il problema è che un metodo del genere è molto costoso, in termini di risorse e soprattutto di tempo. Ma ora ci sono le IA che scrivono codice: non si può far fare il lavoro a loro?
È proprio quello che è stato fatto con la libreria Python chardet, che cerca di determinare qual è il codifica dei caratteri usata in un documento. Il programma è stato creato nel 2006 da Mark Pilgrim e rilasciato sotto la licenza LGPL, e portato avanti da vari sviluppatori, soprattutto da Dan Blanchard che ha praticamente preso le redini del progetto dal 2012 e la versione 1.1. Ora Blanchard ha rilasciato una nuova versione, la 7.0.0 (al momento siamo alla 7.0.2) definita come “riscrittura da zero” con l’aiuto di Claude Code e rilasciata con la MIT license, il che significa che può essere usata anche senza far automaticamente far diventare open source tutto il progetto che la usa. Pilgrim però ha obiettato, dicendo che non era possibile cambiare licenza al software, e da qui è partita una diatriba. Blanchard ha spiegato che è partito dalla generazione di un insieme di specifiche usando superpowers, per poi partire ex novo con un progetto e istruire Claude Code a non usare codice GPL oppure LGPL. Il risultato, usando il tool JPlag che verifica la somiglianza del codice con un altro dato, è che la similarità massima è dell’1,29%.
Willison elenca poi una serie di punti che rendono il caso complicato: Blanchard sicuramente conosce fin troppo bene il codice originale, avendoci lavorato su per tre lustri; Claude Code ha sicuramente referenziato parti del codice originale, come il file che elenca le proprietà delle varie codifiche, ma d’altra parte Pilgrim aveva scritto il codice partendo da un’implementazione in C con la licenza Mozilla; Claude è stato quasi sicuramente addestrato anche con il materiale di chardet, e la sua “memoria” è sicuramente molto più affidabile di quella degli sviluppatori che compilano in una clean room. Ma naturalmente il vero problema non è tanto chardet, che rimarrebbbe con una licenza libera. Il software libero nasce proprio in contrapposizione a quello proprietario: cosa succede se il pendolo si sposta dall’altra parte e le aziende sfruttano il software libero per averne dell’altro bloccato?
Solo una piccola correzione: la licenza LGPL permette, a differenza della licenza GPL, di usare la libreria in codice proprietario. Quel che non permette è di modificarla senza licenziare LGPL anche la versione modificata, cosa che invece si potrà fare con la versione MIT.
Ma in tutto questo, cosa ci guadagna Blanchard dal cambio di licenza?
hai ragione, la LGPL nacque come compromesso per chi diceva che Stallman era troppo talebano e la GPL poteva fermare lo sviluppo del software libero.
Immagino che Blanchard abbia delle idee diverse su quale sia la licenza migliore per una libreria, e quindi dopo quindici anni abbia deciso di “ricominciare da capo”.
Nei progetti Open uno dei problemi maggiori è il funding.
Sicuramente qualche cliente ha detto nell’orecchio a Blanchard che la LGPL dava fastidio, e da qui il tutto.
Ah, ho letto un articolo su lowendbox e ho capito meglio la cosa. Effettivamente è possibile riscrivere i programmi open e appiccicarci una licenza a piacere.
Però è anche possibile prendere delle funzionalità di un programma chiuso (se non brevettate/-tabili) e ricavare una versione open senza (tanta) fatica.
Per me si sta iniziando a capire cosa vuole davvero dire che lo sviluppo software può essere automatizzato, ma solo quando talune aziende forti nel software chiuso (es. noti ERP) avranno perso valore in borsa si potrà dire che ogni aspetto dello sviluppo software è cambiato. Per ora siamo solo ad una variazione del fine-print e delle dichiarazioni di uso di software open presenti in praticamente ogni prodotto elettronico e lette sempre con grande interesse dal consumatore finale.
C’è una fondamentale asimmetria: il programma closed source, per sua natura, non è parte del processo di learning del modello. Il risultato finale è quindi più complesso da raggiungere.
Vero, ma la vicinanza funzionale tra soluzioni di produttori diversi, open o close mi fa pensare che l’AI possa cavarsela più che bene in moltissimi casi.
Del resto genialate algoritmiche pazzesche closed source sono rare e il successo dipende molto di più dalla capacità commerciale in senso ampio.
Semmai i produttori di software dovrebbero trarre enormi vantaggi dall’AI, incrementando il valore in borsa delle loro aziende, ma mi aspetto che i clienti/consulenti saranno più veloci dei tradizionalisti e il settore cambierà prima che i grossi capiscano cosa sta succedendo.
La migliore protezione contro il cambiamento resta la burofollia regolamentare, ma credo che la scarsità di persone in grado/desiderose di lavorare nel settore avrà la meglio.