Introduzione

Questo breve articolo vuole essere un semplice parere sul motivo per il quale trovo che la dipendenza da MySQL non faccia assolutamente bene al software libero, ma, anzi, a lungo termine porti a nuocere gravemente per la nostra libertà.

Innanzitutto analizziamo cos’è MySQL e come è legato al software libero: si tratta di un software per la gestione di database (DBMS) rilasciato sotto licenza duale GPL e non libera. Grazie a questa doppia licenza, chiunque sia interessato all’uso di MySQL in un ambiente libero od OpenSource può utilizzarlo sotto i termini della normale licenza GPL, mentre chi lo volesse utilizzare per scopi non liberi può acquistare la licenza d’uso dai proprietari del software (MySQL AB), e quindi evadere le restrizioni poste dalla licenza GPL (che come tutti sappiamo è «infettiva»).

Tale licenza viene erroneamente dichiarata da MySQL AB come licenza commerciale, in realtà non è esatto chiamarla in questo modo, poiché un software libero può essere allo stesso tempo commerciale. Tale licenza sarà dunque chiamata in questo articolo come licenza non libera, che rende meglio l’idea sull’uso che viene effettivamente fatto di tale licenza. Similmente, la licenza GPL viene definita da MySQL AB come licenza opensource, ma anche questo è il termine sbagliato, essendo la licenza GPL una licenza libera, mentre una licenza OpenSource può non essere libera.

Quindi un software libero, scritto sotto licenza GPL o GPL-compatibile, può utilizzare MySQL secondo la licenza GPL come per un normale software libero. Invece un software proprietario, volendo utilizzare MySQL o i driver per la connessione ad un database MySQL, deve acquistare una licenza da MySQL AB. Un’eccezione viene fatta per il software OpenSource (o libero e GPL-incompatibile), rendendo quindi MySQL una scelta facile per chiunque lavori su soluzioni libere e OpenSource.

Innanzitutto vorrei sottolineare che MySQL non è assolutamente il miglior DBMS presente sulla piazza: attualmente non supporta a pieno titolo le linee guida per i database relazionali, cosa che ne limita molto le funzionalità paragonato a prodotti proprietari quali Oracle o SQL Server. Ma non si tratta dell’aspetto tecnico che voglio parlare ora, poiché su quello è possibile parlare a lungo, ma richiederebbe una conoscenza più approfondita del vero e proprio lavoro sui database stessi.

Effetti della licenza duale

MySQL è male per il software libero per un motivo abbastanza semplice in realtà: la sua licenza duale. Prendiamo un attimo in mano il concetto stesso della licenza duale: utilizzando tale licenza è possibile evadere l’infettività della licenza GPL, infettività nata per preservare la libertà del software a cui viene applicata: ogni lavoro derivato deve essere a sua volta distribuito secondo la licenza GPL. Mentre, nel caso di lavori derivati per i quali sia stata acquistata una licenza non libera da MySQL AB, non è più necessario distribuire il prodotto finale sotto una licenza libera.

Ma se questo può essere scocciante per i puristi del software libero, non è ancora il punto a cui voglio arrivare. Per poter utilizzare questa licenza duale, MySQL AB deve risultare essere la detentrice del copyright di tutto il codice di MySQL, perché solo il detentore del copyright per un software può includere eccezioni alla licenza del proprio software (o appunto usare una licenza duale). Questo porta al primo problema: se uno sviluppatore esterno vuole contribuire, è costretto a cedere il copyright del proprio operato a MySQL AB, altrimenti le modifiche non verranno mai apportate al codice sorgente originale. Se una cosa simile già avviene in altre situazioni (per esempio gli script di installazione di Gentoo, e il software del progetto GNU), solitamente si tratta di fondazioni che mantengono il codice libero. Nel caso di MySQL AB non è così, perché il codice di cui si cede il copyright viene poi rivenduto con la licenza non libera.

A questo punto il povero sviluppatore esterno ha tre strade principali:

1. Fornire la patch – File contenente le differenze tra il codice originale e il codice modificato – a MySQL AB cedendone il copyright: la patch sarà applicata al codice sorgente originale, e sia la versione libera che quella non libera potranno usufruire delle correzioni o delle nuove feature aggiunte dalla patch stessa.

2. Fornire la patch solo sotto licenza GPL, e sperare che le distribuzioni continuino ad applicarla da quel punto in avanti: questa non sarà applicata al codice sorgente originale, perché impedirebbe a MySQL AB di rivendere il codice sotto la licenza non libera. Nel caso le distribuzioni la applicassero, i binari delle distribuzioni saranno generati da sorgenti diversi rispetto a quelli dei binari della versione non libera.

3. Non rilasciare affatto la patch, ignorare la necessità di usarla e scegliere altre vie (come per esempio cambiare database, o semplicemente non fare uso di quella particolare funzionalità).

Generalmente sono due i casi in cui non si è disposti a fornire la patch a MySQL AB: o si è puristi del software libero, e quindi non si vuole vedere MySQL AB fornire il proprio codice in licenza non libera, oppure si è più pratici e materiali, e si decide che non si vuole vedere MySQL AB fare soldi sul proprio codice.

Qualsiasi sia la ragione, a prima vista la terza soluzione è quella che provoca più danni per la comunità (se nessuno rilasciasse patch, tutto il codice ristagnerebbe), ma in realtà a mio avviso la seconda ha un’implicazione anche peggiore, a lungo termine.

Se le distribuzioni cominciassero ad applicare patch e sovra-patch a MySQL, il binario rilasciato potrebbe diventare incompatibile tra una distribuzione e un’altra, tra una versione e l’altra, fino al punto in cui i sorgenti originali e quelli modificati dalle distribuzioni saranno completamente diversi, rendendo praticamente impossibile un valido uso di MySQL su larga scala, perché funzioni che sono presenti in una determinata versione con le aggiunte di una distribuzione potrebbero non funzionare sulla stessa versione modificata da un’altra distribuzione, o potrebbero comportarsi in modo lievemente o parzialmente diverso.

Solitamente quando gli utenti finali si ritrovano a dover applicare talmente tante patch al codice sorgente originale da cambiarne buona parte del funzionamento, gli sviluppatori di tali patch cominciano a raggrupparsi per decidere cosa fare: mantenere le patch separatamente può diventare un gran problema, perché il codice modificato da una, potrebbe venire modificato da una seconda, e quindi ci si troverebbe ad avere dipendenze interne tra le patch, che comporterebbero un effetto domino se venisse cambiato il codice originale. Per risolvere questo la maniera più pratica è quella di fare un fork: rilasciare un nuovo programma, solitamente con un nome diverso o modificato rispetto a quello originale, che segue quindi una via di sviluppo sua propria.

Il problema di questa soluzione però è che di nuovo si pone un bivio: se lo sviluppo procede per la sua strada, senza più seguire lo sviluppo del programma originale, si arriverà presto al punto di avere due ambienti diversi, e chi continuerà ad usare MySQL si ritroverà di nuovo nell’identica posizione di prima. D’altro canto, se gli sviluppatori continueranno a seguire lo sviluppo di MySQL, applicando programmaticamente tutti i cambiamenti apportati alla base di codice originale, MySQL AB potrebbe decidere di smettere di supportare la versione libera di MySQL, e di proseguire il solo sviluppo della versione non libera, togliendo alla comunità uno dei software che -purtroppo, a mio avviso- è diventato cardine nello sviluppo del web libero.

La ragione per cui mi è venuto in mente questo ragionamento è stata la notizia che db4objects, Inc. ha rilasciato il proprio prodotto di punta (un altro database, orientato agli oggetti stavolta), con una doppia licenza (libera e non libera) del tutto simile a quella di MySQL AB.

Questa tendenza a lungo termine può portare all’assottigliamento del software veramente libero, fino al ritrovarsi del software che viene spacciato per libero ma in realtà non lo è. A quel punto saremmo costretti a scendere a patti col software proprietario fino ad avere del software -quasi- libero.

Soluzioni

Possiamo fare qualcosa per evitare ciò? Beh perlomeno ci si può provare: esistono altri database liberi, oltre a MySQL, db4o e Firebird — la versione libera di Borland Interbase, rilasciato sotto licenza MPL 1.0, quindi già meno subdolo. PostgreSQL è uno di questi.

Uno dei problemi maggiori nell’uso di questi database è che non tutti i software, specialmente le web application scritte in PHP, non forniscono supporto a database diversi da MySQL. Se siete dei programmatori PHP, e state utilizzando una web application che supporta solo MySQL, provate a pensare se riuscireste ad aggiungere il supporto a PostgreSQL o altri database liberi a tale applicazione. Se siete dei semplici webmaster che utilizzano delle web application che supportano solo MySQL, provate a cercare degli equivalenti che possano usare anche PostgreSQL o altri database liberi. Anche nel caso in cui non possiate fare altro che usare MySQL per qualsiasi ragione, evitate le applicazioni che possono usare soltanto MySQL, in questo modo saranno più invogliate a supportare database alternativi.

L’altro maggiore problema è il fatto che la maggior parte degli hoster web forniscono solo spazio con database MySQL, e sono veramente rari quelli che forniscono a richiesta un altro database libero. Questo comporta la necessità di usare in ogni caso MySQL e di consequenza molte applicazioni che vengono scritte per lavorare su questi hoster vengono scritte solo per MySQL. Quindi se siete hoster, pensate a fornire a richiesta un altro database libero su cui lavorare. Invece se siete in contratto con un hoster che non fornisce altro che MySQL, domandegli se è possibile avere il supporto a database alternativi.

Non è affatto mia intenzione iniziare una di quelle campagne di boicottaggio, perché credo che ognuno sia libero di scegliere gli strumenti di cui ha bisogno, o di usare quelli che ha a disposizione. Vi chiedo soltanto di pensarci, e di guardare se potete fare qualcosa per limitare il problema.

Ringraziamenti

Desidero ringraziare, per i commenti e i consigli durante la stesura di questo articolo, Riccardo “mala” Furlan, Alberto “Albertoz” Zennaro e Isaac Rallo

Inoltre voglio ringraziare Stefano “SnoopyX” per avermi aiutato a capire come riscrivere l’articolo in LaTeX.