问题
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?
回答1:
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.
回答2:
You may need to consult a lawyer. I am not one. But here are some things to consider:
- 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.
- 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.
- 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.
回答3:
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)
回答4:
Oracle (neé Sun, neé MySQL AB) will happily sell you a GPL exemption for the C API library. Then you can distribute the MySQL++ DLL along with your program and only be subject to the LGPL.
来源：https://stackoverflow.com/questions/1260591/about-mysql-gpl-and-lgpl