MySQL AB distribuisce lo stesso sorgente sotto due licenze incompatibili tra loro: la GNU General Public License (GPL) e una licenza commerciale a pagamento. È questo il meccanismo che rende vendibile un database scaricabile gratis. Per capire perché funziona bisogna guardare la clausola della GPL che quasi tutti scambiano per un difetto.

Contesto

MySQL è sotto GPL dalla versione 3.23.19, uscita nel giugno 2000. Prima il server usava una licenza propria, più permissiva nell’uso ma con condizioni meno nette sulla ridistribuzione. Il passaggio alla GPL non ha reso il prodotto più libero di prima — si scaricava già senza pagare — ma ha cambiato la natura giuridica di ciò che un terzo può fare con il codice quando lo integra in un prodotto suo.

Lo stesso schema si ritrova altrove. Trolltech distribuisce la libreria Qt sotto GPL — o, in alternativa, sotto la Q Public License — dal 2000, e vende a parte una licenza commerciale a chi sviluppa software proprietario. Sleepycat Software distribuisce Berkeley DB sia sotto licenza copyleft sia sotto licenza proprietaria. Aladdin Enterprises ha applicato per anni una variante dello schema a Ghostscript. In tutti questi casi il titolare detiene il copyright sull’intera base di codice: senza quella condizione non potrebbe rilasciarla sotto termini diversi a destinatari diversi.

Architettura della licenza

Il nodo tecnico è la sezione 2(b) della GPL versione 2: impone che ogni opera derivata, se distribuita, esca per intero sotto GPL. Per una libreria, o per il codice client che un’applicazione collega (link) al proprio eseguibile, la conseguenza è diretta: l’applicazione che ne risulta eredita l’obbligo, e se la distribuisci devi rendere disponibile il suo sorgente sotto GPL.

Per chi sviluppa software proprietario da vendere in forma binaria, questo obbligo non è accettabile. Le vie d’uscita lecite sono due. La prima è non collegare affatto il codice GPL e parlare con il database solo attraverso un confine che non genera opera derivata — di norma un processo separato che comunica via protocollo di rete. La seconda è comprare da MySQL AB una licenza commerciale dello stesso codice, senza la clausola di reciprocità.

La doppia licenza vende quindi esattamente ciò che la GPL nega: il diritto di non ridistribuire le proprie modifiche e di non rendere GPL il prodotto finale. Il valore commerciale del prodotto a pagamento cresce con la forza vincolante della licenza gratuita. Una licenza permissiva in stile BSD, che già consente di chiudere il sorgente derivato, svuoterebbe la versione commerciale: non resterebbe niente da comprare.

Dove finisce l’opera derivata

La parte tecnicamente più scivolosa non è il server, che gira come processo a sé, ma la libreria client libmysqlclient. Un’applicazione la collega per parlare con il server, e quel link è proprio l’atto che la GPL considera fonte di opera derivata. Da qui nasce un problema concreto per i progetti open source con una licenza diversa dalla GPL. Il linguaggio PHP, per dire, esce sotto una licenza propria più permissiva, e la sua estensione MySQL collega libmysqlclient: a leggere la GPL in senso stretto, un’estensione di un progetto non-GPL che si collega a codice GPL sta in una posizione quantomeno discutibile.

È qui che la doppia licenza mostra la sua fragilità. Il confine dell’opera derivata, nel caso del linking, non lo definisce un test meccanico ma un’interpretazione giuridica mai messa alla prova in tribunale per casi del genere. Le aziende pagano la licenza commerciale anche, e a volte soprattutto, per uscire da questa zona grigia: comprano certezza, non funzionalità. Una parte di ciò che vendono è l’assenza di rischio interpretativo, non codice migliore.

Ricadute sullo storage engine

Lo stesso ragionamento si estende ai motori di storage che MySQL integra. Le tabelle transazionali InnoDB le sviluppa la finlandese Innobase Oy e finiscono dentro il server: distribuite con MySQL, seguono la GPL. Quando il database integra codice di terzi sotto licenze diverse, ogni componente deve restare compatibile con i termini con cui MySQL AB vuole rilasciarlo due volte. Un componente con licenza incompatibile con la GPL, o con un titolare del copyright che non concede a MySQL AB il diritto di rilicenziarlo, spezzerebbe la catena: l’azienda non potrebbe più offrirlo sotto licenza commerciale.

Ne deriva che il modello a doppia licenza vincola la struttura tecnica del prodotto. Ogni dipendenza esterna va trattata non solo sul piano funzionale ma su quello del copyright: o si ottiene la cessione dei diritti, o il componente resta fuori dalla versione commerciale, o lo si riscrive. La libertà architetturale di chi mantiene il prodotto è limitata dalla necessità di poterlo rilasciare due volte.

Limiti del modello

La doppia licenza ha bisogno di una condizione che non tutti i progetti open source hanno: il copyright concentrato in un solo soggetto. Un progetto con contributi sparsi tra centinaia di autori, ciascuno titolare del proprio, non può rilicenziare nulla senza il consenso di tutti, e quindi non può vendere una versione proprietaria del codice comune. Per questo lo schema appartiene quasi sempre ad aziende che chiedono ai contributori la cessione o una concessione ampia dei diritti — una pratica che sposta il controllo del progetto verso il titolare e lo allontana dallo sviluppo distribuito di Linux o di Apache.

Resta aperto un punto che nessuna licenza chiude da sola: stabilire cosa sia opera derivata nel caso del linking dipende dalla giurisdizione e non ha precedenti consolidati. La doppia licenza lascia in piedi questa incertezza e la trasforma in una voce di ricavo.

Immagine di copertina: David Axmark e Michael “Monty” Widenius, i due fondatori di MySQL AB, ritratti insieme nel 2003 — foto di Werner Popken, CC BY-SA 2.5 — https://commons.wikimedia.org/wiki/File:Monty-Widenius-David-Axmark-MySQL-2003-05-09.jpg