MySQL: Inserire record che potrebbero esistere già

Agosto 12th, 2009

L’SQL è un linguaggio imperativo. Questo significa che è costituito da una serie di comandi che indicano un’azione da compiere, lasciando poco spazio per le strutture di controllo del flusso. Sappiamo che il suo sottoinsieme noto come DML (Data Manipulation Language) comprende tre istruzioni fondamentali: DELETE per cancellare i record, UPDATE per aggiornarli e INSERT per inserirli. Sono azioni piuttosto elementari, che nel nostro lavoro quotidiano dovrebbero combinarsi formando istruzioni più complesse. Un esempio di richiesta complessa che spesso si vorrebbe rivolgere a un database è: “se un certo record nella tabella XXX esiste già, allora fai questo”. Mancando in SQL le istruzioni condizionali, generalmente questo tipo di logica è contenuta nel programma che si occupa di lanciare le query (esempio: uno script PHP). Un’alternativa è scrivere una Stored Procedure che se ne occupi, perchè tali procedure ammettono estensioni procedurali al linguaggio SQL, o possono essere scritte in altri linguaggi. MySQL però comprende alcune comode estensioni non standard che permettono di comunicare al server come si debba comportare nel caso in cui un certo record già esista.

Valori unici

Cosa significa per un database “questo record esiste già”? Come sappiamo, un record può essere identificato da una o più chiavi, ognuna delle quali può essere un campo, la prima parte di un campo o una combinazione di più campi. Generalmente la Chiave Primaria, che è il modo principale per identificare un record, è costituita da un campo numerico (UNSIGNED INTEGER) chiamato `id`. Vi possono essere delle Chiavi Candidate, che consistono in velori o combinazioni di valori che sono unici per ogni record. In MySQL questi sono i campi che rappresentano gli indici UNIQUE.

INSERT IGNORE

La prima di queste estensioni è la clausola IGNORE dell’istruzione INSERT. Essa semplicemente chiede a MySQL di ignorare gli errori dovuti al tentativo di inserire valori duplicati nella chiave primaria. In altre parole, se si tenta di inserire un record ma esso non può essere scritto poiché contiene un valore unico già presente in tabella, non viene generato alcun messaggio di errore. Se si tenta di inserire diversi record con un’unica INSERT e alcuni di questi non possono essere scritti perchè contengono valori duplicati, gli altri record verranno scritti senza problemi e non viene restituito alcun errore. Spesso i messaggi di errore hanno effetti collaterali che si desidera evitare.
Un’ulteriore possibilità è usare, oltre alla clausola IGNORE, anche la clausola DELAYED. Essa chiede a MySQL di non generare alcun messaggio di errore in nessun caso. Questo vale per gli errori di tipo “Duplicate key”, ma anche ogni altro tipo di errore - ad esempio la mancanza dei permessi necessari per scrivere sulla tabella, disco pieno, etc. Se tale comportamento ci è comunque gradito (perchè non abbiamo intenzione di gestire alcun tipo di errore) allora la clausola DELAYED è da preferire per ragioni di performance. Infatti ciò che rallenta maggiormente le applicazioni sono le comunicazioni di rete e il mancato invio di messaggi di errore che verrebbero comunque ignorati è un’ottimizzazione intelligente. Comunque, è bene ricordare che gli unici Storage Engine a supportare questa clausola sono MyISAM, MEMORY, ARCHIVE e BLACKHOLE. Se usata su tabelle che usano altri motori, DELAYED provoca un errore.

Esempi:

INSERT IGNORE INTO `clienti` (`nome`, `cognome`, `tel`) VALUES ('Mario', 'Rossi', '123456');
INSERT DELAYED IGNORE INTO `clienti` (`nome`, `cognome`, `tel`) VALUES ('Maria', 'Bianchi', '654321');

REPLACE

Il comportamento appena illustrato è desiderabile nel caso in cui il record che si tenta di inserire non possa essere più completo di quello già esistente. Se però nel record già presente in tabella alcuni campi sono vuoti (o meglio, impostati ai valori di DEFAULT), anche nel caso in cui l’istruzione INSERT contenga tali valori, essi andranno persi.
Esiste però il caso opposto, cioè quello in cui si presume che il record già presente contenga meno informazioni (o informazioni meno aggiornate) rispetto a quelle che si sta tentando di inserire. In tal caso è ragionevole chiedere a MySQL si inserire sempre e comunque il nuovo record, sostituendo quello che eventualmente potrebbe essere già presente. Per fare questo si utilizza l’istruzione REPLACE.
Essa è una combinazione di DELETE + INSERT. Questo implica alcune conseguenze non del tutto ovvie. La prima riguarda i permessi: per eseguire REPLACE bisogna avere i permessi di DELETE e INSERT. Inoltre, se si esegue REPLACE su una tabella InnoDB (o su altre tabelle che supportano le Chiavi Esterne) prima di inserire il nuovo record si cancellerà il vecchio, scatenando l’evento ad esso associato (come ON DELETE SET NULL). Infine, se sulla tabella sulla quale si esegue una REPLACE esiste un trigger associato all’evento DELETE, questo verrà lanciato.

Esempi:

REPLACE INTO `clienti` SET `nome`='Mario', `cognome`='Rossi', `tel`='123456';
REPLACE DELAYED INTO `clienti` SET `nome`='Maria', `cognome`='Bianchi', `tel`='654321';

Si noti, infine, che REPLACE potrebbe eliminare più di un record prima di inserire il nuovo. Infatti, come si è detto, una tabella può avere più chiavi uniche (PRIMARY KEY e campi UNIQUE) e naturalmente un record potrebbe contenere diversi valori duplicati. Dopo aver lanciato questa istruzione, il numero di affected_rows() restituito corrisponde a 1 (il nuovo record inserito) + il numero di record eliminati. Sapere questo ci permette di determinare facilmente se uno o più record sono stati liminati e quanti:

$deleted_rows = mysqli_affected_rows($con) – 1;

INSERT … ON DUPLICATE KEY UPDATE

Vi è poi un ultimo caso, che è una via di mezzo tra i due precedenti. Può darsi che si voglia inserire un record nel caso esso non sia già esistente, ma che se esso esiste non vogliamo perdere né alcune informazioni già scritte in tabella, né alcune informazioni presenti nell’istruzione. In tal caso si utilizzerà INSERT con la clausola ON DUPLICATE KEY UPDATE.

Vediamo subito un esempio, nel quale tentiamo di inserire un nuovo utente; se esso esiste, vengono modificati il suo indirizzo email e l’url del suo blog, lasciando però inalterate tutte le altre informazioni.

INSERT INTO `utenti` (`username`, `password`, `email`, `www`)
VALUES ('pippo', 'sesamo', 'pippo@topolinia.com', 'pippo.noblogs.org')
ON DUPLICATE KEY UPDATE `email`='pippo@topolinia.com', `www`='pippo.noblogs.org';

INSERT … ON DUPLICATE KEY UPDATE non può essere utilizzata con DELAYED, sebbene ciò non generi alcun errore. E’ possibile inserire diversi record come si fa talvolta con le INSERT anche utilizzando la clausola ON DUPLICATE KEY UPDATE. Il numero di affected_rows() equivale al numero di record inseriti + (il numero di record modificati * 2). Questo implica che non è possibile sapere con esattezza quanti record sono stati aggiunti e quanti sono stati modificati basandosi esclusivamente su affected_rows().

Venenux: un’altra distribuzione Libera

Agosto 11th, 2009

All’elenco delle distribuzioni GNU/Linux Libere riconosciute dalla FSF si aggiunge un nuovo nome: quello di VENENUX. Si tratta di una distribuzione realizzata da e per utenti di software libero latinoamericani.

VENENUX dichiara che non includerà mai pacchetti non liberi. Il sistema ha come primo obiettivo quello di essere fortemente ottimizzato. L’equipo che si occupa del suo sviluppo non è costituito solo da programmatori, ma anche di esperti di vari settori che sono in grado di stabilire i requisiti da soddisfare per venire incontro ai bisogni degli utenti avanzati. Inoltre il tutto è preconfigurato per adattarsi meglio a un’utente latinoamericana.

Con queste premesse, entra nella schiera delle distribuzioni libere un sistema operativo che non solo è libero dal punto di vista formale, ma favorisce una buona quantità di utenti che sono normalmente sono ignorati per motivi geopolitici.

Kongoni, un altro modo di dire gnu

Luglio 24th, 2009

All’elenco delle (poche) distribuzioni GNU/Linux completamente libere si aggiunge Kongoni:

http://www.kongoni.co.za/

Kongoni (che in lingua shona significa gnu) è una distribuzione basata su Slackware con desktop KDE. Ancora non compare nell’elenco ufficiale della FSF, che però ha terminato di esaminare l’ultima release, chiamata Nietzsche e rilasciata meno di due settimane fa. Gli unici pacchetti non liberi che sono stati trovati sono il firmware Ralink e i font Lucida - nel prossimo update del sistema verranno eliminati. Kongoni si impegna inoltre a eliminare qualsiasi altro pacchetto non libero che venga loro segnalato.

Essendo una distribuzione sudafricana, in futuro hanno intenzione di includere alcuni software liberi che la maggior parte delle altre distribuzioni (libere o non libere) non può includere per problemi di brevetti o altre questioni legali che però in Sudafrica non sussistono.

MySQL Wikibook

Luglio 12th, 2009

Ho appena aggiunto una sezione di una pagina del progetto di documentazione libera di MySQL (metadati sugli eventi). E’ un lavoro sporco, o meglio noioso, ma qualcuno doveva pur farlo. Mi dispiace solo che al momento il progetto sia un po’ abbandonato a sè stesso, perchè non ce n’è mai stato così bisogno come oggi.

Spero che a qualcuno venga voglia di contribuire. Non fatevi intimidire dall’inglese. Prima di tutto, credo che i contributor più attivi non siano madrelingua inglese. E poi c’è sempre bisogno di una traduzione in italiano - anche se fosse parziale e aggiornata di rado sarebbe meglio di niente.

Buona rivolta.

Licenze libere senza copyleft

Luglio 5th, 2009

Cos’è il copyleft?

Il termine copyleft è chiaramente il contrario di copyright. La traduzione italiana (contestata) è permesso d’autore. Ma che cosa significa?

Il copyright sono i “diritti” dell’autore di un’opera, intesi come divieti per chi ne possiede una copia. La famosa frase “All rights reserved” (tutti i diritti riservati) rende abbastanza ovvio l’ossimoro: non si parla di diritti, ma di rigide imposizioni.

Il copyleft è una clausola che può essere applicata a una licenza libera. Quest’ultima garantisce le libertà basilari all’utente. Tra queste libertà vi è quella di distribuirla. Il problema nasce proprio qui: se io scarico un software libero, ho il diritto di:

  • Distribuirlo come software non libero?
  • Aggiungervi moduli non liberi?
  • Integrarlo in un software non libero di cui sono proprietario?

Personalmente penso che la risposta alle domande sopra poste debba sempre essere no. Per lo stesso motivo per cui si sviluppa software libero, bisognerebbe impedire che tale software venisse distribuito non liberamente o andasse a integrare altri software che liberi non sono.

Altri la pensano diversamente. Ritengono che impedire le tre azioni sopra elencate equivalga a privare gli utenti di alcune loro libertà. A questa obiezione rispondo che non bisogna abusare della parola libertà. La mia libertà inizia dove finisce la tua? Bene, allora non ho il diritto di prendere un software (scritto da me o da altri), fornirtene una copia e decidere cosa farai tu con quella copia. Che senso ha lagnarsi di “non essere liberi di imporre”? E’ pura retorica.

Ad ogni modo non tutti la pensano così e non riuscirò, con questo post, a convincerli a rivedere le proprie idee. Con questa introduzione voglio principalmente spiegare cos’è il copyleft: è il “copyright al contrario” che impedisce di distribuire un software libero (o i suoi moduli) come software non libero.

L’uso del programma in rete

Le licenze, con o senza copyleft, hanno un problema storico. Come ho spiegato in un post precedente, le licenze libere tradizionali sono state scritte anni prima della diffusione di internet come la conosciamo oggi. Di conseguenza esse garantiscono tutte le libertà fondamentali agli utenti che ricevono una copia del programma, che avranno quindi la possibilità di eseguirlo in locale o installarlo essi stessi su di un server. Quando utilizzano il programma attraverso una rete però (webmail, forum, mailing list…) non ricevono alcuna copia del programma e i termini della licenza non si applicano. Queste persone non vedono il codice sorgente, tanto meno lo possono modificare o ridistribuire. Eppure, da un punto di vista logico, non esiste un motivo per il quale chi usa Evolution debba avere più libertà di chi usa una webmail.

L’unica licenza che prende in considerazione questo problema, e che quindi garantisce a chi usa un programma attraverso la rete le sue libertà basilari, è la GNU AGPL. Si tratta di una licenza libera dotata di un forte copyleft, derivata dalla GPL.

Al momento, chi non ama il copyleft non ha a disposizione una licenza già pronta che risolva i problemi legati all’uso di un programma in rete. Vi è però una motivazione: inserire una clausola che garantisca le libertà degli utenti di rete significherebbe inserire una forma di copyleft. Infatti non si garantirebbe solo la libertà di chi riceve il programma che si sta distribuendo, ma anche la libertà degli utenti del suo server.

Chi considera una regola simile inaccettabile, a mio parere, dovrebbe comunque garantire in prima persona almeno i diritti degli utenti dei propri siti internet. Nulla gli vieta infatti di distribuire i sorgenti di tutti i programmi liberi che crea o che utilizza, se la licenza lo consente.

Le licenze senza copyleft

La più famosa licenza priva di copyleft è indubbiamente la BSD. Quando si utilizza questo nome però bisognerebbe capire cosa si intende. Esistono infatti due versioni: la licenza BSD a 4 clausole (o licenza BSD originale o FreeBSD license) conteneva la cosiddetta clausola pubblicitaria (ad clause). La clausola numero 3 imponeva infatti di includere nel software una frase che riconoscesse la paternità del programma alla This product includes software developed by the University of California, Berkeley and its contributors. Non si tratta ovviamente di un abuso, ma questo ha portato il problema della proliferazione dei riconoscimenti. Poichè ogni autore di un “pezzo” di software tendeva a modificare questa licenza aggiungendo il proprio nome o quello della propria organizzazione, man mano che nuovi programmatori miglioravano il codice si aggiungevano sempre più nomi. Lo stesso FreeBSD ha deciso di eliminare quella clausola e tentare di eliminare i nomi che potevano essere eliminati quando, nel 1997, ha dovuto rilasciare una versione con ben 75 riconoscimenti. Va comunque detto che non vi è nulla di non libero in tale licenza, solo qualche problema pratico.

La versione successiva della licenza viene generalmente chiamata la BSD a 3 clausole, o modificata. La clausola publicitaria è stata depennata. Questa licenza, in pratica, permette a chi riceve una copia del software di farne ciò che desidera. Anche distribuirlo in forma binaria - purchè naturalmente applichi la stessa licenza.

La licenza X11 non obbliga l’utente a includere il nome dell’autore originale (l’X Consortium) ma al contrario impedisce l’uso di tale nome a fini pubblicitari, a meno che non si disponga di esplicita dichiarazione scritta da parte dell’interessato.

La SGI Free Software License B, versione 2.0, è molto simile alla X11. Le versioni precedenti alla 2.0 non sono considerate libere. Tuttavia esse permettono di ridistribuire il software con una versione successiva della licenza, perciò la loro non-libertà si può annullare ni maniera banale.

La licenza Expat permette essenzialmente di fare qualsiasi cosa con il software che copre, purchè non si elimini la licenza. Inoltre essa si applica esplicitamente anche ai file di documentazione distribuiti con il programma.

Sia la licenza X11, sia la Expat sono talvolta chiamate licenza MIT. Data l’ambiguità del termine sarebbe meglio evitarlo.

Come si combinano queste licenze con la GPL e la AGPL?

Tutte le licenze senza copyleft qui elencate sono compatibili con la GPL. Questo significa che il codice coperto da GPL e il codice libero coperto da queste licenze possono essere combinati insieme formando un’unica entità distribuibile, modificabile e ridistribuibile. Ogni parte di codice sarà sottoposto solo alle regole stabilite dalla licenza alla quale è associato.

Queste licenze sono compatibili anche con la AGPL. Si tenga presente che un modulo coperto da una di esse, se inserito in un software più ampio coperto da AGPL, viene sottoposto a una delle clausole della AGPL. Se modificato, quindi, il suo codice sorgente dovrà essere reso disponibile alle persone che se ne servono attraverso una rete.

Approfondimenti sulla AGPL

Luglio 5th, 2009

Ho già parlato (un paio di post fa) della licenza GNU Affero General Public License, o AGPL. Ma vorrei approfondire il tema.

Differenze con la GPL

La AGPL3 differisce con la GPL3per principalmente per la sezione 13. La riporto, in inglese, perchè GNU non ha ancora fornito una traduzione in italiano.

13. Remote Network Interaction; Use with the GNU General Public License.

Notwithstanding any other provision of this License, if you modify the
Program, your modified version must prominently offer all users
interacting with it remotely through a computer network (if your version
supports such interaction) an opportunity to receive the Corresponding
Source of your version by providing access to the Corresponding Source
from a network server at no charge, through some standard or customary
means of facilitating copying of software.  This Corresponding Source
shall include the Corresponding Source for any work covered by version 3
of the GNU General Public License that is incorporated pursuant to the
following paragraph.

Notwithstanding any other provision of this License, you have
permission to link or combine any covered work with a work licensed
under version 3 of the GNU General Public License into a single
combined work, and to convey the resulting work.  The terms of this
License will continue to apply to the part which is the covered work,
but the work with which it is combined will remain governed by version
3 of the GNU General Public License.

Per prima cosa, essa dice che, se si modifica il codice sorgente del programma, bisogna offrire ai propri utenti (che interagiscono con il programma attraverso la rete) la possibilità chiara (prominently) di ricevere una copia dei sorgenti stessi.

La AGPL e le altre licenze

Il codice sorgente del programma rilasciato con la AGPL potrebbe includere delle librerie o altri moduli, che possono anche essere stati scritti da altri programmatori, e che potrebbero essere coperti da licenze differenti. Allora sorge la domanda: se si modifica queste librerie, occorre poi distriburle agli utenti che le utilizzano attraverso una rete?

Risposta: si, a meno che non si tratti di librerie di sistema. Non sarebbe ragionevole, infatti, chiedere che chi modifichi libc ne fornisca il sorgente agli utenti del proprio sito. Tuttavia, se si utilizza una libreria per la connessione al database e questa viene modificata, i sorgenti dovranno essere pubblicamente disponibili.

Per la precisione, la sezione 13 utilizza una definizione ben precisa parlando del “codice sorgente” che deve essere distribuito: lo chiama Corresponding Source. Questo termine è definito nella sezione 1 della AGPL:

The “Corresponding Source” for a work in object code form means all
the source code needed to generate, install, and (for an executable
work) run the object code and to modify the work, including scripts to
control those activities.  However, it does not include the work’s
System Libraries, or general-purpose tools or generally available free
programs which are used unmodified in performing those activities but
which are not part of the work.  For example, Corresponding Source
includes interface definition files associated with source files for
the work, and the source code for shared libraries and dynamically
linked subprograms that the work is specifically designed to require,
such as by intimate data communication or control flow between those
subprograms and other parts of the work.

The Corresponding Source need not include anything that users
can regenerate automatically from other parts of the Corresponding
Source.

The Corresponding Source for a work in source code form is that
same work.

AGPL e GPL: compatibili?

La AGPL3 richiama esplicitamente la GPL nella sezione 13 riportata all’inizio. Essa è compatibile con la versione 3 della GPL. Questo significa che è possibile usare una libreria distribuita con GPL3 all’interno di un programma AGPL.

Tuttavia, la AGPL non è compatibile con la GPL2. Questo accade perchè quanto richiesto dalla sezione 13 è definito come Further Resctrictions dalla sezione 7 della GPL2. Essa proibisce qualsiasi ulteriore restrizione, perchè si rischierebbe che un distributore aggiunga alla licenza imposizioni che non hanno a che fare con la libertà.

Scegliere tra AGPL e GPL

La maggior parte degli sviluppatori web che rilasciano script coperti da licenza AGPL3, semplicemente non hanno riflettuto sul fatto che questa licenza non garantisca realmente la libertà degli utenti o non sono a conoscenza della AGPL.

La AGPL andrebbe sempre utilizzata al posto della GPL. Nel caso in cui si stia rilasciando uno script PHP che produce output in HTML, le ragioni sono ovvie. Ma anche quando si sta rilasciando un programma di altro genere è saggio utilizzare la AGPL. Infatti il software potrebbe essere scaricato da programmatori che decideranno di migliorarlo, eventualmente aggiungendovi nuove funzionalità - questa pratica è prevista dalle licenze libere ed è da incoraggiare. Tuttavia questo significa anche che un programma pensato per essere eseguito in locale potrebbe diventare un programma che offre funzionalità di rete, che magari l’autore originale non immaginava. E’ quindi una buona abitudine utilizzare sempre la AGPL.

Troppo libera per Google

Google si proclama sostenitore del software libero e fornisce strumenti per alcuni progetti. Google Code però ha preso una decisione drastica: ha bandito la AGPL. Chiedendo gentilmente agli autori dei progetti coperti da questa licenza di… andarsene.

Mailing list anti-cloud

Luglio 3rd, 2009

Un breve post per segnalarvi che Ac LAB (Anti-cloud LAB) ha ora una sua mailing list. La lista è pubblica. Consiglio l’iscrizione a chi è interessato all’argomento.

GPL? No, AGPL

Giugno 30th, 2009

La licenza storica del progetto GNU è la GPL. Essa è apprezzata da alcuni e mal sopportata da altri perchè, oltre a garantire all’utente le quattro libertà del software, è dotata di un forte copyleft.

Copyleft è il contrario di copyright. Significa che una licenza, oltre a garantire delle libertà, impone (se di imposizione si può parlare) che queste libertà vengano preservate. Un copyleft minimo consiste nello stabilire che, quando un software viene stabilito, esso sia accompagnato dalla stessa licenza con la quale lo si è avuto. In caso contrario una persona potrebbe prendere un software libero e distribuirlo come software proprietario.

Il copyleft della GPL è particolarmente forte, perchè vieta di aggiungere parti di codice proprietario al programma. Si può modificare e migliorare il software e non distribuirlo. Ma se si desidera distribuirne una versione modificata, i sorgenti delle proprie modifiche devono poter essere visionati da chiunque riceva il software stesso e devono essere coperti da licenza GPL o altre licenze compatibili. Il software o parte di esso inoltre non potrà essere usato come modulo per un software non libero. Vi sono poi ulteriori “restrizioni”, che in realtà non sono altro che garanzie di libertà per l’utente finale.

Ma la GPL ha un forte limite: il suo spirito originale viene completamente snaturato se utilizzata con applicazioni web. Questo perchè quando essa è stata scritta internet non esisteva.
Spieghiamo questo limite con un esempio. Paperino scrive un programma, poniamo un web forum, e lo distribuisce sul suo sito. La licenza è la GPL. Topolino scarica questo forum e lo installa a sua volta sul suo sito. Dal suo punto di vista è software libero: può usarlo come vuole, studiarne i sorgenti, modificarlo e distribuirlo (anche in versione modificata). Infatti, dopo aver constatato che manca una funzione di ricerca tra i messaggi vecchi, Topolino stesso la implementa. Fa qualche prova e si sfrega le mani: va che è una scheggia! Paperoga si collega quotidianamente al sito di Topolino e usa il forum. Un giorno decide di mettere su un forum anche lui, si collega al sito di Paperino, scarica il programma e lo installa. La funzionalità di ricerca non c’è e purtroppo Paperoga non ha le conoscenze per implementarla. Topolino (che mi è sempre stato un po’ antipatico) non ha condiviso con la comunità il codice che ha scritto.
Questo non è giusto: Paperoga usa il forum che gira sul sito di Topolino, è a tutti gli effetti un utente del software. Eppure non gode di nessuna delle quattro libertà sopra citate. Perchè? Tecnicamente perchè non ne ha mai ricevuto una copia. Lo usa attraverso una rete. Topolino, non distribuendo il programma in sè, non è tenuto a fornire nè i sorgenti nè la licenza GPL.
Tutto ciò è perfettamente legale ma profondamente contrario alle intenzioni di chi ha scritto la licenza.

Fortunatamente la società Affero ha scritto una nuova licenza, che è in realtà una variante della GPL. E’ la licenza chiamata GNU Affero General Public License, o semplicemente AGPL. Essa è molto simile alla GPL ma con un’aggiunta importante. Stabilisce che chi modifica il software ricevuto e lo installa su un server pubblico deve condividere con la comunità le modifiche apportate.

In questo modo viene a cadere l’assurda distinzione tra chi utilizza un software dopo averne ricevuta una copia e chi lo utilizza attraverso la rete. Almeno in teoria.

Due saggi di Eben Moglen

Giugno 28th, 2009

Consiglio la lettura di due saggi “politici” riguardanti il software libero. Entrambi sono di Eben Moglen, che è stato l’autore originale della licenza GPL e ha collaborato fino alla stesura di una bozza per la terza versione.

Spero che la lunghezza e il fatto che il primo sia in inglese non scoraggino la lettura. Se siete a conoscenza di traduzioni in italiano di Anarchism tiumphant vi prego di segnalarmele.

Buona lettura.

LGPL, una strana licenza

Giugno 28th, 2009

La licenza libera per eccellenza scritta e utilizzata dal progetto GNU è la General Public License (GPL). Fin dagli albori o quasi, alla GPL hanno affiancato un’altra licenza un po’ meno libera: la LGPL. Questo acronimo inizialmente stava per Library General Public License e questo ha portato molti sviluppatori a credere che fosse la licenza più adatta per le librerie. Per risolvere l’inconveniente il nome della licenza è stato cambiato in Lesser General Public License: licenza pubblica “un po’ meno generale”.

Infatti le librerie, per essere libere e dotate di un buon copyleft, dovrebbero essere rilasciate con licenza GPL o AGPL. La LGPL è un compromesso tra la libertà assoluta che la GPL giustamente esige e le logiche di mercato. Infatti la differenza tra queste due licenze è molto semplice: una libreria LGPL, pur essendo tecnicamente libera, può essere utilizzata all’interno di un software commerciale.

Sembra strano che il progetto GNU e la Free Software Foundation non possano tollerare che alcune righe di codice proprietario siano inserite in un programma libero (la GPL giustamente lo vieta) ma allo stesso tempo chiudano un occhio se una libreria libera implementa funzionalità che poi verranno utilizzate da software proprietari. In altre parole: un programma libero con un pezzo di codice proprietario non va bene; un programma proprietario con un pezzo di software libero va bene. Eticamente non regge.

Oltretutto interi programmi (e non solo librerie) sono stati rilasciati con licenza LGPL e sono considerati liberi.

Sul sito di GNU vi è un articolo intitolato Why you shouldn’t use the Lesser GPL for your next library, nel quale, oltre a spiegare perchè la LGPL normalmente non dovrebbe essere usata, si spiega perchè in alcuni casi sia ritenuta preferibile. Essenzialmente il ragionamento è questo: se una libreria offre funzionalità che nessun’altra libreria offre, o se la sua qualità è nettamente superiore a quella delle librerie non libere, è giusto che sia rilasciata come GPL; se però teme la concorrenza di altre librerie proprietarie, la sua licenza potrebbe essere la LGPL. Il motivo addotto da GNU è il seguente: i software proprietatari, se possono scegliere quali librerie usare, le scelgono tra quelle che permettono al programma stesso di rimanere non libero; se le librerie libere sono nettamente superiori alle loro concorrenti, non devono porsi questo problema, perchè un software per essere di qualità potrebbe/dovrebbe utilizzarle e divenire libero; se invece non lo sono, per trovare una maggiore diffusione, devono permettere il proprio utilizzo all’interno di programmi non liberi, quindi usare la LGPL.

Il progetto GNU, quindi, sembra partire dal presupposto che un programma proprietario che utilizza una o più licenze LGPL sia eticamente migliore di un programma proprietario che non utilizza alcuna libreria libera. Questo potrebbe essere in parte vero, ma mi rifiuto di esaminare il problema da questo punto di vista. Loro stessi, in altri casi, rifiutano questo tipo di approccio: si veda l’articolo di Stallman Avoiding ruinous compromises, nel quale definisce “rovinoso compromesso” l’inserimento di driver non liberi all’interno delle distribuzioni GNU/Linux allo scopo di aumentarne la diffusione.

Se poi lo scopo è non imporre limitazioni per vie legali, chiedendo implicitamente protezione a quegli stessi poteri che limitano tutte le nostre libertà (digitali e non), allora non bisognerebbe usare alcuna licenza. In tal caso si deve dichiarare esplicitamente il proprio software di pubblico dominio, per che in caso contrario All rights are reserved, come dice la SIAE. Questa è una scelta di tipo diverso, che non giudico migliore nè peggiore.

Usare la LGPL per diffondere maggiormente una libreria, accettando un compromesso eticamente ancor meno accettabile (potenziamento di software proprietari/monopolistici), non è peggio che includere driver proprietari?
Non sarebbe ora che la Free Software Foundation e il progetto GNU allargassero il proprio concetto di “Rovinoso compromesso” e dessero alle fiamme la licenza LGPL?