Dubbi su MySQL e licenza GPL.

[Massimo Masson]

Marco Bisetto ha scritto:

[...]

>>Ma il fatto di utilizzare programmaticamente (si dice?) un dbms non 
>>implica l'utilizzo del suo query-language e delle sue specifiche 
>>interfacce e quindi, almeno indirettamente, delle sue librerie 
>>d'interfaccia?
> 
> Pero` il query language di MySQL e` SQL, un linguaggio standardizzato. 

Certo che si! Intendevo dire che se si vuole usare "da programma" il 
query language ci si deve "interfacciare" ad una libreria del podotto, 
ed a quel punto credo si stia entrando nella zona copyleft-protetta 
della GPL (ma prima di commentare quest'affermazione vedi il discorso 
che faccio qualche riga più sotto)... ammetto comunque di aver espresso 
in maniera eccessivamente confusa quel che avevo in mente. Rispetto alla 
mia frase, l'attenzione sarebbe da focalizzare sul discorso della 
libreria d'interfaccia!

[...]

> L'interpretazione secondo la quale l'unico modo per utilizzare MySQL
> licenziato GPL con un software proprietario, sia di scriversi in casa
> il software proprietario stesso mi pare troppo restrittiva. Questo

Però uno dei vincoli della GPL è proprio che i lavori derivati debbano 
essere rilasciati in un certo modo (copyleft). Ora piuttosto la 
questione è definire "lavoro derivato" con correttezza.

Io avevo in mente una cosa del tipo: scrivo un programmino, che fa le 
sue cose (e vede gente... ;) ). Come "archivio" decido di appoggiarmi a 
MySQL, e quindi da programma mi interfaccio verso le sue funzioni. Ad 
esempio, uno scheletro di codice come il seguente (esempio con Python 
perchè mi viene più facile):

<py>
import MySQLdb	# questa cosa rende il mio sw un lavoro derivato?

Con = MySQLdb.Connect(host="hostaddress", port=3306, user="username", 
passwd="password", db="dbname")
Cursor = Con.cursor()
Cursor.execute("codice-SQL")
Results = Cursor.fetchall()
print Results
Con.close()
</py>

per me è un lavoro derivato in quanto, nel momento in cui utilizzo 
"import MySQLdb", mi sono appoggiato alle librerie (che si appoggiano 
alle librerie per interfacciarsi a) MySQL. Il mio programma "funziona" 
con MySQL, e cado nella GPL, ovviamente se e quando "ridistribuisco".
Nulla questio sul fatto che l'ipotetica riga in cui è contenuto 
.execute("codice-SQL") nulla ha a che vedere con licenze, 
ridistribuzioni e quant'altro...

> perche' MySQL e` pur sempre un server che comunica tramite protocolli
> standardizzati: TCP/IP e SQL. Sarebbe come se l'utilizzo di Apache
> fosse condizionato dal modello di licenza dei contenuti (gli script
> php o python, per esempio) del server web di cui e` motore.

Bella osservazione. Io credo che si debba dire questo: un conto è il 
protocollo, un conto il software che lo "usa".
Intendo questo: nell'esempio, Apache risponde a chiunque richieda info 
con un protocollo ben formato. E su questo problemi di licenza non penso 
ce ne siano.
Il problema si potrebbe porre nel momento in cui io scrivessi un mio 
software, che interroga un web server (servito da Apache, o da qualsiasi 
altra cosa, ovviamente...).
Tale sw potrebbe appoggiarsi a delle librerie per eseguire 
l'interrogazione (lasciamo ora perdere il livello, non mi interessa 
http, piuttosto che TCP o IP). Per determinare le questioni inerenti le 
licenze, si dovrebbe capire come sono licenziate le librerie stesse. Se 
fossero GPL, di conseguenza il sw sarebbe obbligato ad essere GPL. In 
effetti, proprio per questo nasce la "LGPL", specificatamente utilizzata 
per le librerie, in quanto non vincola il rilascio di eventuale codice.
Se per ipotesi io mi scrivessi la mia libreria TCP/IP da zero, porei 
licenziarla ed utilizzarla come voglio. Se invece utilizzassi una 
libreria già pronta, dovrei sottostare alle specifiche della sua 
particolare licenza, qualunque esse fossero! (gpl o commerciali).
A maggior ragione, in quest'ottica riprendo la tua citazione delle faq 
di mysql stessa:

[...]

> http://www.mysql.com/products/licensing/faq.html

che mi pare confermino le osservazioni su esposte, nel senso che lo 
stesso MySQL, una volta licenziato con lgpl, legittimava chiunque a 
farne uso nei propri lavori senza il vincolo della gpl.

> Il punto fondamentale dell'interpretazione secondo me e` quel "tightly
> coupled". Ovvero: se sei un produttore di software, e scrivi del
> codice proprietario che funziona _esclusivamente_ se accoppiato a
> MySQL, utilizzandone le librerie, allora significa che stai producendo
> un derivato di mysql e devi pagare la licenza. Se invece il tuo codice

Sono sostanzialmente d'accordo con questa affermazione.

> funziona altrettanto bene con altri motori SQL, allora il tuo cliente
> non e` legato a mysql dalla tua applicazione (ovvero non e`
> _obbligato_ a procurarselo, non ricadi nella clausola "copy, modify or
> distribute MySQL" citata all'inizio) e quindi puo` usarlo rimanendo
> nei termini della GPL; purche' tu non distribuisca MySQL assieme alla

d'accordo se per interfacciarmi a mysql non ho bisogno di nulla che non 
sia gpl. Ma, mi domando, per interfacciarsi via software a mysql credo 
che, bene o male, tutti i moduli d'interfaccia sfruttino le api di 
mysql. Per "uscirne" bisognerebbe scriversi un modulo d'interfaccia 
apposito, che non utilizzi _una_ riga di codice gpl-ed, e il "problema" 
penso sarebbe superato. D'altronde il codice e le specifiche di mysql 
sono "pubbliche", quindi tecnicamente la "missione" dovrebbe essere 
fattibile.
Queste considerazioni peraltro fanno meglio capire per quale motivo 
certi sistemi (leggi *BSD) siano in una fase di riscrittura di una serie 
di utilities gpl-ed con diversa e meno restrittiva licenza (leggi di 
nuovo bsd).

Qui forse sono carenti le mie conoscenze, ma i moduli d'interfaccia che 
ho visto per mysql sono tutti gpl. Nel caso tuttavia fosse possibile 
utilizzarlo esclusivamente via tcp/ip senza altro codice, ovviamente, le 
considerazioni che ho fin qui esposto non si applicherebbero.

> Comunque sia, personalmente mi pare che alcune restrizioni vadano
> oltre la GPL e siano pericolose. Allora per lo stesso motivo Microsoft
> avrebbe ragione di chiedere una licenza per l'uso di Linux, o Samba,
> considerato che in essi ci sono parti di codice capaci di leggere e
> scrivere i filesystem FAT e NTFS o di integrarsi, tramite il
> protocollo SMB, con altri computer basati su sistemi operativi
> Microsoft. Con un'interpretazione cosi` vasta di "lavoro derivato",

Non credo sia così, se questo si capiva dal mio intervento precedente 
dev'essere solo perchè probabilmente mi sono espresso male nella frase 
"incriminata" di cui sopra (vedi il discorso di cui sopra sulla 
distinzione tra codice/libreria e protocollo/linguaggio).

> molti programmi liberi potrebbero essere considerati derivati di altri
> prodotti commerciali (fatto che alcune ditte detentrici di brevetti
> vogliono forzare all'estremo). Ma il principio che un prodotto A sia
> derivato dal prodotto B solo perche' A si interfaccia con B, pur non
> contenendone una sola riga di codice, mi pare sia decisamente nefasto.

Condivido anche questa tua affermazione, non credo di aver detto ciò, e 
spero di aver meglio chiarito la mia interpretazione con questo post...

...ciò nonostante resta una mia interpretazione, ed ovviamente in quanto 
tale non è detto che sia nè vera, nè quella corretta!

Ad ogni modo, esulando dal tema originario, uno dei problemi legati al 
tema dei brevetti software è proprio che io non potrei più disengare, ad 
esempio, una progress-bar perchè qualcun'altro ne ha i diritti ed io 
dovrei chiedergli il permesso... (cosa su cui ovviamente non sono 
d'accordo...)

Ciao,
Max.

p.s. da questa discussione è nato un thread molto interessante, imho...