[Libreoffice-qa] Bug 59481 - FILEOPEN: Linux rpm: Native MySQL-connector aoo-my-sdbc-1.1.0 didn't work any more with LO 4.0

[Dan Lewis]

On 01/21/2013 11:55 AM, Lionel Elie Mamane wrote:
> On Sat, Jan 19, 2013 at 11:17:20AM -0500, Terrence Enger wrote:
>> On Fri, 2013-01-18 at 08:04 -0800, Joel Madero wrote:
>>> Can someone triage this one? Thanks in advance!
>> And there has been quit a bit of subsequent discussion.
>> I wonder just what Lionel was proposing [1] after the announcement
>> [2] of changed licence for the mariadb / mysql client library.
> I was commenting that for LibreOffice, this is not sufficient. We, as
> a project, have decided not to ship (binaries compiled from) GPL
> code in our main product, that is LibreOffice (we do "ship" GPL code
> that does not end up in LibreOffice, e.g. in
> http://cgit.freedesktop.org/libreoffice/contrib/dev-tools/tree/make-3.82-gbuild
> ).
>
> The MySQL native (SDBC) connector is made as follows::
>
>   MySQL SDBC connector itself (SISSL / Apache / LGPL licence,
>                                depending on version)
> using
>   MySQL Connector/C++ (GPL)
> using
>   MySQL Connector/C (AKA libmysql or client Library) (GPL)
>
>
> Swapping out the MariaDB client library for the MySQL client library
> brings the picture to:
>
>   MySQL SDBC connector itself
> using
>   MySQL Connector/C++ (GPL)
> using
>   libmariadb (LGPL)
>
> So still not OK for integration into LibreOffice proper, because still
> a GPL component.
>
> For us to be able to ship the MySQL SDBC connector (with our current
> self-imposed policy), one of these things has to be done:
>
> 1) Write an Apache/BSD/LGPL/... licensed "clone" of MySQL
>     Connector/C++
>
> OR
>
> 2) Change the MySQL SDBC connector to not need "MySQL Connector/C++",
>     but use libmysql/libmariadb directly (these are API-compatible; we
>     would ship with libmariadb, but if a downstream user would want to
>     swap it with libmysql, technically there should be no problem)
>
> But that's "only" *our* policy. Any third party can make a different
> choice, and e.g. Debian has made another choice and *does* ship GPL
> code, including the MySQL Connector/C++ and the MySQL SDBC connector
> for use with LibreOffice. It is my understanding any such third party
> would be allowed to upload the MySQL SDBC connector for use with
> LibreOffice to extensions.libreoffice.org; I don't see on that website
> a policy that forbids that. If any such third party would do that, at
> least for Microsoft Windows and MacOS X, I believe it would make some
> of our users happier.
>
      Then perhaps it is time to reconsider *your* policy. Or, perhaps 
you should explain to us what problem does the GPL license present to 
LibreOffice? This seems a little hypocritical. You will not include GPL 
licensed code in LO that you make available for download. Yet, the same 
website can contain extensions that include GPL licensed code. As a 
result, we the users of LO may have to use inferior software in the 
extensions because you will not provide us with a good SDBC to connect 
to MySQL or MariaDB.
      There is another possibility: provide a JDBC that can be used. Is 
there a license problem with that also? I know there is a potential Java 
problem.

--Dan

>> How would this compare in effort and benefit to the job of making
>> the mysql extension work with LibreOffice 4.0?
> The MySQL extension just needs to be compiled/linked against
> LibreOffice 4.0; then it should work. No development work needed. Only
> building (for GNU/Linux and MacOS (if necessary): on an OS install as
> old as what the extension wants to be compatible with).
>
> So, here's how "it" compares in effort and benefit, "it" being "the
> stuff described in the ESC minutes that you linked to".
>
>   - MUCH more work
>
>   - MUCH more benefit, since it would allow the MySQL SDBC connector to
>     be bundled with LibreOffice. I will *gladly* review a patch that
>     does that!
>
>> Just by the way, does this change of licence return mysql to
>> consideration for LO's built-in database [4]?
> No, because this is only the client library, not the database engine
> itself. For our embedded database, we want to ship a database
> engine. The database engine is still GPL. Be it MySQL or MariaDB.
>