Sun acquisisce MySQL per un miliardo di dollari

[mjordan]

Originariamente inviato da xeal

A proposito di java: non ho ancora ben capito tutte le implicazioni dell'adozione della gpl per i software sviluppati su piattaforma java (non me ne sono interessato molto: ma già utilizzando le librerie della piattaforma - swing, util, ecc. - non è come linkare a porzioni di codice coperte da gpl? non scatta la sua "viralità"? ù

La viralità non scatta perchè è un requisito rilassato nella LGPL, licenza piu' adatta alle librerie, proprio perchè prevede eccezioni nel caso di un utilizzo "implicito" mediante linking statico o dinamico. Swing è coperto da LGPL che prevede il linking di librerie (sia esso sorgente o binario) anche in progetti chiusi e commerciali. Pensa ad esempio a GCC. Il compilatore in se è basato su GPL ma è perfettamente lecito usarlo per compilare codice chiuso grazie alla LGPL con cui vengono rilasciate le librerie C/C++ e quant'altro (con qualche eccezione, ovviamente).

poi mi piacerebbe anche capire in cosa consista la "compatibilità" della gpl con altre licenze open, come la bsd 2).

Questo lo stabilisce la OSI che è l'organo competente a certificare le licenze in base all'appartenenza o meno al concetto di "free software", definito da ciò che si chiama la "Open Source Definition", documento che fu stilato da Bruce Perens e ispirato dallo "GNU Manifesto" originariamente scritto da Stallman. Organo capeggiato da Bruce Perens, che ha idee leggermente differenti da Stallman (fortunatamente)
Tutti i dettagli li trovi qui:
http://www.opensource.org/

In sostanza è "scorretto" dire che la BSD è compatibile con la GPL. Oggi è piu' corretto dire che sia la GPL che la BSD sono compatibili con la open source definition (la compatibilità reciproca è quindi una conseguenza)
Compatibilità nel senso debole del termine. Non sono un esperto ma credo che un software non si possa rilasciare con entrambe le licenze, a causa di alcune clausole che collidono, pur mantenendo lo spirito originale dell'OSI.

[xeal]

Per java: ah, bene, mi mancava che in parte fosse sotto LGPL, adesso mi è più chiaro il meccanismo

Per le compatibilità: 'spetta un po', io so che ci sono due versioni della bsd (che era un esempio): la versione originaria che è dichiarata incompatibile con la gpl e la "seconda versione" che è dichiarata compatibile (la prima praticamente impone di riportare il nome dell'autore originario un po' dappertutto, il che crea problemi se i contributori sono molti, almeno così ricordo di aver letto tra le motivazioni dell'incompatibilità, ma è passato un po' di tempo). Mi piacerebbe capire un po' meglio il meccanismo della doppia licenza (in particolare se una delle licenze è virale come la gpl).

In ogni caso, Thanks for the info!

[xeal]

@mixmax99:

Saresti così gentile da chiarirci il dubbio sulla licenza di mysql sollevato da cionci, riguardo l'uso con php o java + jdbc non coperti da gpl? Thanks

[Motosauro]

Originariamente inviato da xeal

@mixmax99:

Saresti così gentile da chiarirci il dubbio sulla licenza di mysql sollevato da cionci, riguardo l'uso con php o java + jdbc non coperti da gpl? Thanks

*
È una vexata quaestio che anche a me piacerebbe vedere risolta, dato che lo uso come DB per tutti i miei progetti a lavoro (non il sorgente, sia chiaro, solo il motore)

[mixmax99]

@ Xeal

molto volentieri. Abbiamo due modelli di licenza, uno free basato su licenza GPL ed uno commerciale.

Vado a riassumere brevemente gli scenari:

1. Azienda che utilizza MySQL per uso interno: puo' decidere se usare la versione community o quella enterprise
2. Azienda che svilluppa e vende prodotti che girano su MySQL: in questo caso se MySQL non e' incluso nella distribuzione, l'acquisto o meno della licenza e' a carico del cliente finale. Un esempio e' l'azienda che sviluppa siti web con java o php usando i driver nativi php o jdbc: non c'e' nessuna licenza da pagare, spetta al cliente finale.
3. OEM, societa' che sviluppa prodotti che includono (embedded o meno) il database. Qua ci sono due opzioni: se il prodotto e' GPL si puo' usare MySQL con licenza GPL, altrimenti la societa' deve comprare una versione commerciale.

Questi sono i 3 scenari generalmente piu' diffusi, spero di aver coperto le tue necessita'. Sono a disposizione se avete altri dubbi e/o perplessita'.

[cionci]

Originariamente inviato da mixmax99

2. Azienda che svilluppa e vende prodotti che girano su MySQL: in questo caso se MySQL non e' incluso nella distribuzione, l'acquisto o meno della licenza e' a carico del cliente finale. Un esempio e' l'azienda che sviluppa siti web con java o php usando i driver nativi php o jdbc: non c'e' nessuna licenza da pagare, spetta al cliente finale.

Ma qui l'azienda che acquista il prodotto DEVE pagare MySQL ?

Comunque confermi che per qualsiasi applicativo non GPL sviluppato con libmysql (quindi diciamo C e C++) e che non ricade nella FLOSS exception list, allora bisogna pagarlo.

[cionci]

Originariamente inviato da xeal

Per java: ah, bene, mi mancava che in parte fosse sotto LGPL, adesso mi è più chiaro il meccanismo

La JVM ora è GPL che io sappia: http://www.sun.com/2006-1113/feature/index.jsp
Sono le librerie ad essere LGPL.

[Motosauro]

Originariamente inviato da mixmax99

@ Xeal

molto volentieri. Abbiamo due modelli di licenza, uno free basato su licenza GPL ed uno commerciale.

Vado a riassumere brevemente gli scenari:

1. Azienda che utilizza MySQL per uso interno: puo' decidere se usare la versione community o quella enterprise
2. Azienda che svilluppa e vende prodotti che girano su MySQL: in questo caso se MySQL non e' incluso nella distribuzione, l'acquisto o meno della licenza e' a carico del cliente finale. Un esempio e' l'azienda che sviluppa siti web con java o php usando i driver nativi php o jdbc: non c'e' nessuna licenza da pagare, spetta al cliente finale.
3. OEM, societa' che sviluppa prodotti che includono (embedded o meno) il database. Qua ci sono due opzioni: se il prodotto e' GPL si puo' usare MySQL con licenza GPL, altrimenti la societa' deve comprare una versione commerciale.

Questi sono i 3 scenari generalmente piu' diffusi, spero di aver coperto le tue necessita'. Sono a disposizione se avete altri dubbi e/o perplessita'.

Grazie mille per la disponibilità intanto

Originariamente inviato da cionci

Ma qui l'azienda che acquista il prodotto DEVE pagare MySQL ?

Comunque confermi che per qualsiasi applicativo non GPL sviluppato con libmysql (quindi diciamo C e C++) e che non ricade nella FLOSS exception list, allora bisogna pagarlo.

*
Avrei inoltre questo dubbio:
Mettiamo che l'applicazione che sto sviluppando sia fornita come closed-source e sia disegnata per funzionare pescando da un database tramite jdbc.
Io fornisco l'applicazione al `cliente` separatamente dal database, solo con le istruzioni per crearsi le tabelle e configurarsi jdbc.
In quel caso chi deve pagare la licenza a MySQL?
Tenendo presente che l'applicazione non integra parti di codice di MySQL

Quello che sto scrivendo per i fatti miei (un frontend per dentisti) sarà distribuito in questo modo e volevo capire come siamo messi per le licenze (anche se io lo rilascerò sotto GPL quindi non dovrei aver problemi di sorta).

[cionci]

Originariamente inviato da Motosauro

*
Avrei inoltre questo dubbio:
Mettiamo che l'applicazione che sto sviluppando sia fornita come closed-source e sia disegnata per funzionare pescando da un database tramite jdbc.
Io fornisco l'applicazione al `cliente` separatamente dal database, solo con le istruzioni per crearsi le tabelle e configurarsi jdbc.
In quel caso chi deve pagare la licenza a MySQL?

Suppongo il cliente dal discorso fatto sopra, ma soprattutto la DEVE pagare ?

[Motosauro]

Originariamente inviato da cionci

Suppongo il cliente dal discorso fatto sopra, ma soprattutto la DEVE pagare ?

Appunto questo è il nodo.
Se deve pagare allora deve pagare anche se si (o gli si) mette su un sito in php ... ?

[mixmax99]

Come ho scritto nel punto 2, ACQUISTO O MENO della licenza di MySQL e' a carico del cliente. Sara' lui a decidere, quindi, se vuole usare la versione community o quella a pagamento per avere anche il supporto, gli hot fixes, l'enterprise monitor, ecc.

Spero di aver risposto alla domanda
Max

[Motosauro]

Originariamente inviato da mixmax99

Come ho scritto nel punto 2, ACQUISTO O MENO della licenza di MySQL e' a carico del cliente. Sara' lui a decidere, quindi, se vuole usare la versione community o quella a pagamento per avere anche il supporto, gli hot fixes, l'enterprise monitor, ecc.

Spero di aver risposto alla domanda
Max

Ah, ok
Allora è come l'ho sempre intesa io (phew... )
Grazie mille

[owoelwo]

Mixmax???
thor???
Ma sei "quel" Max che fece la storia di internet partendo da Virgilio???
Leo

[baruk]

Chissà come mai la cosa non ha interessato anche google...

[mixmax99]

@owoelwo:

Esatto, sono proprio io! Ed io spero tanto che tu non sia quel poveraccio di Leo che accompagnandomi nell'avventura ha dovuto subire le follie di questa mente malata...

@baruk

Perche' Google dovrebbe essere interessata allo sviluppo di un database? Non e' certo il so core business. Google e' un grande utilizzatore di MySQL a cui ha dichiarato amore eterno ed e' anche un code contributor

[xeal]

@cionci: si, si, mi riferivo proprio alle librerie

@mixmax99:

Mille grazie, adesso è molto più chiaro

Un piccolo chiarimento sul caso 3: se il software è in parte coperto da gpl e in parte no? Ad esempio, se vengono fornite delle librerie di interfaccia sotto lgpl (oppure se viene distribuito con doppia licenza, di cui una open source ma "non virale" come la gpl - ammesso che possano essere compatibili), che so, per facilitare l'integrazione con un'infrastruttura preesistente? (immagino già la risposta, anche perchè così potrebbe essere un'escamotage per non far pagare la licenza nè all'oem, nè al cliente - cosa a cui non sono interessato, tra l'altro non sto scrivendo nulla del genere, è solo per capire un po' meglio, perchè tendo a perdermi un po' nei meandri delle implicazioni della gpl e della compatibilità tra licenze).

Thanks

[mixmax99]

hai immaginato bene! Anche in questo caso si paga (e poi c'e' da vedere come tu possa includere nella tua distribuzione a codice chiuso alcuni elementi GPL...)

[serious.max]

[xeal]

Eh, eh, tralasciando la parte "a codice chiuso", direi che "mia" e "distribuzione" non vanno tanto d'accordo

Era solo un esempio che mi sembrava un po' al "confine" tra due scenari, per vedere se avevo capito. Pensavo a un back-end gpl che poggiasse su libmysql, per creare/sfruttarne un subset e modificare/aggiungere funzionalità accessorie, o roba del genere, più un front-end (anche non il solo) sotto Lgpl che si integrasse facilmente (come componente sostitutivo, o roba del genere) con un'infrastruttura già in possesso del cliente, ad esempio per sostituire un altro database e fare da ponte, traducendo da un "dialetto" all'altro (e quindi si comporterebbe un po' da middleware tra l'infrastruttura del cliente e il back-end). Se ho capito bene, laddove il componente lgpl (o vattelapesca) di "collegamento" fosse realizzato internamente dal cliente, rientrerebbe nel primo caso, e il back-end gpl rientrerebbe nel 3° tra gli usi consentiti, siccome però entrambi vengono realizzati dall'ipotetico oem si ricada interamente nel 3°, ed essendo una parte del codice che richiamerà in qualche modo il database (il ponte) non gpl allora scatta l'obbligo di pagare la licenza.

Il fatto è che quando c'è di mezzo la gpl (ma anche altri tipi di licenza) con o senza eccezioni, mi vengono in mente sempre dei casi limite che mi confondono le idee (il limite dev'essere mio, ma essendo la licenza la parte più "burocratica" di un software, spero di non essere il solo: almeno sono in buona compagnia ). Una volta che ho beccato uno che ci lavora e ha dimestichezza con eccezioni e situazioni al limite, per il tipo di licenza che usa (tecnicamente è una gpl con eccezioni, giusto?), ne approfitto

Grazie per la pazienza