views:

540

answers:

8

Hi all.

MySQL++ is licensed though LGPL, that means that I could release an executable dynamically linked against it without worrying about the source code not being GPL. But, MySQL++ DOES link against libmysqlclient{_r}.{a,so} ( http://tangentsoft.net/mysql++/#linkerrors ) which is GPLed.
As seen as then MySQL++ is technically just a 'wrapper' (btw a very well implemented wrapper, don't get me wrong) towards the GPLed libmysqlclient{_r}.{a,so}, if I link against MySQL++ is like linking against libmysqlclient{_r}.{a,so} ?
If this is the case, then the purpose of MySQL++ being LGPLed is pointless as seen as then any executable dynamically linking against it MUST be then linked against libmysqlclient{_r}.{a,so} as well.

Where am I wrong?
Cheers,

+3  A: 

If your program is licensed under one of the licences listed in the EXCEPTIONS-CLIENT file in the MySQL distribution, then your program doesn't have to be GPL-compatible to use the MySQL client library.

But in general, yes, if you want to link to a GPL library then your program has to be GPL-compatible.

Chris Jester-Young
+1  A: 

I believe that you are correct in concluding that linking against LGPL library A which itself links against GPL library B is the same as linking against a GPL library, and so requires your program to be under the GPL.

So I would agree that libmysql++ being LGPL is pretty pointless, but I think it may be that way because older versions of the MySQL client libraries used to be LGPL. (They're all full-GPL now, though, as you noticed)

Tyler McHenry
Because of the "special exception" for the MySQL client, libmysql++'s LGPL licence isn't necessarily pointless, as long as the program using it is within the list of allowed licences (which are not all GPL-compatible).
Chris Jester-Young
So, what is "special exception" for MySQL client C library? Any link?Cheers,
+1  A: 

You may need to consult a lawyer. I am not one. But here are some things to consider:

  1. Using MySQL++ under the LGPL only works when the resulting work is applicable to the GPL license for MySQL, which is a GPL+exceptions. Therefore your program would need to be GPL, or one of the excepted licenses. Anything else would likely be a violation of the GPL.
  2. GPL and LGPL apply when works are distributed. I can legally install the nVidia binary driver into the GPL kernel on my computer because I'm not distributing it that way. If your application is not a derived work of MySQL it doesn't fall under MySQL's copyright. If distributing your app doesn't violate MySQL's copyright, then you don't need to worry about the terms of MySQL's license. A lawyer can tell you where the derived work boundary lies. The FSF claims that linking creates a derived work.
  3. It may be that if your program does not link against MySQL but only against MySQL++ then your application is not a derived work of MySQL. This is generally true whenever you have a thick enough layer between two components. A Java app running in the JVM links to the JVM but not to the kernel, for example. It could not be considered a derived work of the kernel (*pedantic note: most kernels do not consider programs to be derived works. But the concept is the same).

Remember that the (L)GPL's power derives from copyright. If A is a derived work of B, you need permission from B's copyright holder to distribute it. If A isn't, you don't need permission to distribute A. If A derives from B, but B derives from C, A may or may not derive from C. You need permission from all copyright holders to distribute their works or derivative works. The (L)GPL specifies under what conditions that permission is automatically granted.

Mr. Shiny and New
Mate, I've used the term dynamically linking, so I can link a non GPL software to a LGPL library without having to release the software against GPL if I have to distribute it.The point is another: as seen as the LGPL component links (dynamically and or statically in this case is the same) to a GPL component, isn't this (being LGPL) pointless?
A: 

So again, to make the LGPL license globally valid or they would recommend to link against the old LGPL mysql C connector library (thank god C ABI doesn't change so this is possible at run time provived the API of the C connector is the same - but I doubt) or they should implement the C layer themselves.
But another question would be then why not re-implement the C API inside so it can be totally LGPL ?

Cheers,

A: 

What if my code does not link to the GPL'd library but instead uses dlopen() to exploit the GPL'd library?

The FSF will probably tell you that you're still subject to the GPL, but it hasn't been tested in court. See http://en.wikipedia.org/wiki/GNU_General_Public_License#Linking_and_derived_works
Warren Young
A: 

First, 'your' code (dlopen etc etc) should be placed into MySQL++; second, given that there is no market for different implementation of mysql C connectors with same API, this would be probably seen as a circumvent of the GPL (eg. you don't use dlopen to dynamically load a plug-in but a library with basic functionality for your whole program, MySQL++, which is dependant on it). As far as I know MySQL++ without the C connector from MySQL AB doesn't work.
I guess the only way to properly release MySQL++ against the LGPL would be to implement the functionality that is exported by the C connector inside it.

Any other idea?

+1  A: 
Warren Young
A: 

Yes, I see...but again, the purpose of LGPLing MySQL++ is pointless. At the end of the day you have to buy support from Oracle or you should rewrite the C api to relese your closed source app against MySQL++ or making it GPLed.

Cheers,

No, it's not pointless. The LGPL says that if you modify MySQL++ and distribute it with your program, you have to give the recipients the changed library source so they can rebuild it and relink it to your program. Or, you can try and get your patch into the main MySQL++ tree, which amounts to the same thing. The MySQL C API license is a separate issue.
Warren Young