3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices.
problem 1: even if your code says “version 2.1 of the lgpl (and no later version)” this clause opens the door to your code being relicensed under gpl3.
(maybe) problem 2: some vendor forks gtk+ and modifies it. they include the modified version in their proprietary product. they release their changes to the code under gpl (using the clause above). upstream is unable to integrate these changes.
the reason i say “maybe” is as follows: the act of linking against the library and the act of the relicense can be seen as two separate acts. these acts have to be done one before the other.
consider the case of relicense first. in this case you are linking your program to a gpl’d library and the only way that this is possible is if your code is gpl too. ok. this is probably pretty much what rms intended.
now the case where you link to the library first and then relicense. in this case, you made changes to the _lgpl_ version of the library and must release those changes as lgpl?
i guess the question is if someone can sort of atomically gplify the copy of the lgpl’d library that they modified for use in their own product and, by doing so, meet their code-release requirements under the lgpl.
it seems quite ambiguous… i am not a lawyer.
The FSF says that the LGPL is deprecated. Why are you GTK guys still using it? Still think Corporate $upport is more important than Freedom?
@Bill: the gkt guys could still choose a dual-licence (or more).
Maybe they’ll switch to the GPL3? :D
I’m certain that the FSF regard this as a _feature_ of the license. The LGPL was always intended to be a stop-gap licence to encourage adoption, and I don’t think the FSF ever really considered that people wouldn’t “upgrade” to the latest version of the GPL when it was announced.
That said, the LGPL has been around for some time now and this has never gotten in the way despite the existence of weenies like your first troll comment here. Presumably this is because people know how damaging forks are rather than because they haven’t read the licence.
– Chris
Seems like a bug that got fixed in the upcoming LGPLv3 http://gplv3.fsf.org/lgpl3-dd2-guide/
If the company wants to do that, they’d have to ship their whole product as GPL, since if they ship the library with that license they aren’t allowed to link it with proprietary programs.
You can’t compile a library and have multiple licenses apply to the individual lines of code. The compiled code has a license too.
I don’t think there is much room for confusion here. Consider the following:
If they release the source code under the GPL, then the only thing you could build from that source is a GPL’d library. Assuming the GTK authors have given no additional permissions, the GPL would not give the ISV the right to link that library to their proprietary app and distribute the result (they can’t rely on permissions given by the LGPL because they took the option to convert).
If they are relying on the LGPL, then they need to release the full source code to the library (including their changes). Releasing the patch under the GPL does not cut it, since the result of compiling GTK and the patch would not result in an LGPL covered binary.
The thing to remember here is that both the GPL and LGPL are applied to source, and the distribution rights of the binaries are inherited from the source code they were compiled from.