In un saggio dell’aprile scorso Richard Stallman mette in guardia sul problema generale che si ha quando un software libero (nel senso Gnu del termine) per funzionare dipende da altri componenti non liberi e focalizza la discussione sui programmi scritti in Java.In realtà il problema è gia capitato in diversi momenti storici dell’evoluzione del software libero, si pensi alla necessità di avere un compilatore C e una libreria C liberi per poter eliminare dipendenze proprietarie dai programmi di sistema, oppure al kernel di Gnu/Linux, che elimina la dipendenza da un kernel Unix proprietario, fino ai toolkit grafici Gtk, Lesstif e Qt che permettono di non dover dipendere dagli equivalenti proprietari Motif e Qt (versione non-free).
In generale si ha una questione di «taining» (tipica quando un modulo proprietario viene caricato dal kernel di Linux) o di «proprietary dependency injection» (introduzione di dipendenza proprietaria) quando in una catena di produzione o funzionamento del software viene inserito un elemento proprietario.
àˆ solo una questione accademica? Il software proprietario viene in genere rilasciato in sola forma binaria e i suoi prerequisiti (librerie, altri programmi da cui dipende e su cui è stato testato) sono di fatto un limite all’utilizzo che se ne può fare, non essendo possibile modificare il codice per adattarlo a situazioni diverse da quelle per cui è stato sviluppato e testato.
Inserire un componente non libero equivale di fatto a stabilizzare la catena su quanto richiesto e concesso dal componente non libero e a dipendere dal produttore di quest’ultimo per eventuali adeguamenti.
Nella pratica ci si può trovare a non poter aggiornare qualcosa (magari per risolvere problemi di sicurezza noti) causa un componente proprietario che non supporta l’upgrade. Come di solito (non) si dice, il software libero risolve il problema del «controllo» complessivo della soluzione, non del «costo zero» della medesima. àˆ esattamente quanto succede nella realizzazione di programmi Java che vorrebbero essere liberi ma che poi richiedono una Jvm o librerie Java non libere.
Da cui la conclusione di Stallman che la scrittura di software libero che dipende da software non libero è un controsenso o comunque una trappola da evitare.
La sua soluzione è coerente con l’approccio adottato nel caso del compilatore e della libreria C: compilare il proprio software Java usando il tool libero Gcj (front-end Java verso il Gcc) e far sì che esso sia in grado di funzionare con l’implementazione libera Gnu della libreria Java, il progetto Gnu Classpath. In questo modo sono completamente eliminate le dipendenze da Jvm/Jdk non liberi (il Gcj genera un eseguibile nativo, che non necessita di una Jvm).
Se invece si vuole mantenere l’approccio del bytecode, il Gcj può comunque produrlo e il risultato può essere eseguito usando una Jvm libera: tre esempi sono Kaffe, SableVm o JamVm.
Queste Jvm utilizzano comunque il Gnu Classpath come libreria base run-time Java. In questo modo le richieste di bugfixing e d’adeguamento funzionale che vengono fatte ai gruppi di lavoro che mantengono questi progetti hanno l’effetto di migliorare giorno per giorno la qualità di queste implementazioni libere colmando il divario rispetto ai riferimenti proprietari, che al momento godono di un vantaggio di posizione significativo.
Resta inteso che un obiettivo neanche troppo nascosto di queste attività è riuscire prima o poi ad avere a disposizione un’ implementazione libera «ufficiale», certificata, di Java.
Il mondo è abbastanza maturo per potersela permettere.
JamVM
Il saggio di Richard Stallman
La definizione «Gnu» del software libero
