LGPLv3 is the latest version of the GNU Lesser General Public License. It follows the successful LGPLv2.1 license, and was released by Free Software Foundation as a counterpart to its GNU General Public License version 3.
The goal of the GNU Lesser General Public Licenses is to provide software that can be used by both proprietary and free software. This goal has been successfully handled so far by LGPLv2.1, and there is a multitude of libraries using that license. Now we have LGPLv3 as the latest, and the question is how successful is LGPLv3 on this goal?
In my opinion, very little. If we assume that its primary goal is to be used by free software, then it blatantly fails that. LGPLv3 has serious issues when used with free software, and especially with the GNU GPL version 2. Projects under the GPLv2 license violate its terms if they use an LGPLv3 library (because LGPLv3 adds additional restrictions).
What does FSF suggest on that case? It suggests upgrading GPLv2 projects to GPLv3. That's a viable solution, if you actually can and want to upgrade to GPLv3. At the GnuTLS project, after we switched to LGPLv3, we realized that in practice we forced all of our GPLv2 (or later) users to distribute their binaries under GPLv3. Moreover, we also realized that
several GPLv2-only projects (i.e., projects that did not have the GPLv2
or later clause in their license), could no longer use the library at all.
The same incompatibility issue exists with LGPLv2.1 projects that want to use an LGPLv3 library. They must be upgraded to LGPLv3.
In discussions within FSF, Stallman had suggested using the dual license LGPLv3 or GPLv2, in libraries to overcome these issues. That although it does not solve the issue with the LGPLv2.1 libraries, is not a bad suggestion, but it has a major drawback. The projects under the dual LGPLv3 or GPLv2 license, cannot re-use code from other LGPLv3 projects nor from GPLv2 projects, creating a rather awkward situation for the project.
So it seems we have a "lesser" kind of license for use by libraries, that mandates free software project authors the license they should release their projects with. I find that unacceptable for such a license. It seems to me that with this license, FSF just asks you not to use LGPLv3 for your libraries.
So ok, LGPLv3 has issues with free software licenses... but how does it work with proprietary projects? Surprisingly it works better than with free software licenses; it doesn't require them to change their license.
Nevertheless there is a catch. My understanding of LGPLv3 (it is one of the hardest licenses to read - as it requires you to read first the GPLv3 remove some of its clauses and then add some additional ones) is that it contains the anti-tivoization clause of GPLv3. That is, in a home appliance, if the creator of the appliance has an upgrade mechanism, he has to provide a way to upgrade the library. That doesn't really make sense to me, neither as a consumer, nor as someone who potentially creates software for appliances.
As a consumer, why would I consider the ability to only upgrade the (say) libz library on my router a major advantage? You may say that I have additional privileges (more freedom) on my router. It could be, but my concern is that this option will hardly ever happen. Will an appliance creator chose a "lesser" GPL library when this clause is present? Will he spend the additional time to create a special upgrade mechanism for a single library to satisfy the LGPLv3 license, or will he chose a non-LGPLv3 license? (remember that the goal of the LGPL licenses according to FSF is to use them in software where proprietary, or free of charge alternatives exist)
So overall, it seems to me that LGPLv3 has so many practical issues that actually make its advantages (e.g. patent clauses) seem irrelevant, and I don't plan to use it as a license of my libraries. I'm back to the good old LGPLv2.1.
Yeah, the compatibility matrix at http://gplv3.fsf.org/dd3-faq is quite scary, and makes me wonder how it's "protecting the user's freedom" if it's so difficult to combine code from different projects.
ReplyDeleteAs for proprietary software, is there any clear answer on how the LGPL applies to the iPhone App Store? I'm under the impression that the anti-tivoization clause of LGPLv3 means that LGPLv3 libraries can't be used in iPhone apps. Since LGPLv2.1 doesn't have the anti-tivoization clause, does that mean that GnuTLS could be used on the iPhone now that it's moved back to LGPLv2.1?
Although I loathe the locked-down nature of the iPhone as much as the next guy, the company I work for requires broad cross-platform support for our products, and that includes supporting the iPhone. So, the iPhone issue is one of the primary reasons I chose OpenSSL over GnuTLS for the project I'm working on at work. (But that decision makes me sad every day, because GnuTLS has such wonderful documentation, and OpenSSL has such terrible documentation.)
I do not know about the terms of the apple store and whether LGPLv3 is compatible with it. If however LGPLv2.1 is compatible with it then indeed you could use gnutls in that environment provided that you use a version of the gmp library that is also under LGPLv2.1 (if I remember well that is versions before 4.2.1).
ReplyDeleteUnfortunately, I don't know whether the LGPL (in either version) is compatible with the App Store. This seems to be a large gray area, with no one speaking authoritatively on it. The discussion section of this article is representative of the opposing arguments made for and against interpreting the LGPL being compatible with the App Store. And there are plenty of other opinions floating around the Internet on both sides. So, due to the uncertainty, I'm staying away from using LGPL libraries in software that might need to be ported to the iPhone. I don't know for certain that it isn't compatible, but I don't know for certain that it is. I'm guessing v2.1 might be more likely to be compatible than v3, but both seem like gray areas.
ReplyDeleteI do not know either, but I don't see why not. VLC is under LGPL v2.1 and is for quite some time on apple store.
ReplyDeleteTrue, this FAQ suggests that LGPL 2.1 is okay on the iPhone. Perhaps I've been worrying for nothing.
ReplyDeleteLGPL 2.1 is okay on the iPhone only if you use it as if it was GPL 2 (similar to what happens to LGPL3/GPL3 described in this post). The problem is that you cannot respect the relinking clause on those system: dynamic libraries are not present and, more important, the object code is signed and cannot be linked with code signed with a different key.
ReplyDeleteYou missed the and/or part of the relinking clause. A proprietary iOS app can be relinked with LGPL binaries if the author provides (on a website for instance) either all the .o files, or relinks the .o files into one big relocatable .o file, along with any scripts that will allow the final static binary to be created by linking the big .o with the LGPL libraries. The user would then have to sign the code using their own iOS developer credentials in order to be able to use it, but that is a permitted requirement.
ReplyDeletePerhaps a bit of tangent; but if Apple is distributing code that comes under the LGPL license through its app store then, as the burden of providing the source code to downstream users is on the distributor/conveyor, that in this case would have to be on Apple.
ReplyDeleteI don't see Apple doing that for you anytime soon; so imo LGPL still doesn't work with iOS apps...
The compatibility Matrix shows no issues for LGPLv2.1 projects using LGPLv3 libraries;
ReplyDeleteI believe your statement here
"The same incompatibility issue exists with LGPLv2.1 projects that want to use an LGPLv3 library. They must be upgraded to LGPLv3. " should rather be
"The same incompatibility issue exists with LGPLv2.1 projects that want to use LGPLv3 *code*. They must be upgraded to LGPLv3. "
Clearly the Free Software Foundation has blundered in creating this horrid licensing mess..., and as a result, the free software movement is embracing the MIT License completely in order to free itself from the confusing nature of the GPL2.0, GPL3.0, LGPL2.0, LGPL2.1, LGPL3 licenses.
ReplyDeleteThe licensing structure is so convoluted, that the only ones who benefit from the GPL\LGPL structure are lawyers, not the developers.