Static builds and LGPL again, providing object files instead of open source
-
Sorry to bring this banal topic once again, but after reading on the subject I do have a few questions and remarks.
There is nothing in LGPL that mandates dynamic linking/loading. The requirement is that the end user should be able to relink the application to a substitute set of libraries if he so chooses.
Yet the usual narrative regarding Qt is that static builds, while OK for open source projects, are "illegal" for applications whose source is closed.
Obviously, everyone can obtain the source of open source applications and compile against a substitute library. But that is also the case with proprietary code, as long as you provide your object files.
It does seem that providing object codes is enough to satisfy the LGPL requirement - the application, even if closed source, is still possible to relink to alternative libraries and still qualifies for a derived work referencing the library, even if the executable is statically linked.
https://www.gnu.org/licenses/gpl-faq.en.html
Does the LGPL have different requirements for statically vs dynamically linked modules with a covered work? (#LGPLStaticVsDynamic)
For the purpose of complying with the LGPL (any extant version: v2, v2.1 or v3):
(1) If you statically link against an LGPL'd library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.
Which is quite contrasting compared to the answer I got last week:
@iter said:
So, does this mean that if I provide object files, allowing the end user to recompile and relink, I can use a static Qt build and just forget about the deplymend/dependency hell that Qt is with dynamic linking?
@tekojo said:
With a commercial license, yes. When on an open source license, static linking means you would be using GPL and thus would have to provide your source for anyone who asks.
And from Qt's own licensing FAQ:
The LGPL allows you to keep the source code of your application private as long as it is “work that uses” the library. Dynamic linking is usually recommended here.
Recommended, but not mandatory?
Then this bit:
In case of static linking of the library, the application itself may no longer be “work that uses the library” and thus become subject to LGPL
What does "may no longer" mean? What are the conditions here? According to LGPL static linking still qualifies as “work that uses the library”.
Would someone care to elaborate, and I don't mean "no, you can't do that", I mean a sensible and well argumented response. Thanks! I also found several libraries, including wxwidgets, which encourage the usage of static linking under LGPL use.
-
I'll start off again by saying that I'm not a lawyer.
And then say that you are going into details where a lawyer is needed. A lawyer with good understanding of licensing and software.
As a layman I would say to minimally comply and statically link to LGPL libraries you would have to then provide all object files and the whole toolchain you have used for every platform you distribute on. And that is still without any legal training. The idea behind the GPL licenses is to let the user use, share and modify the product.
The additional problem with these generic questions is that different platforms have solved this problem in different ways. If you target just for instance Ubuntu and want to do LGPL, you don't need to think at all, as Ubuntu will provide the LGPL libraries for you (and you wont even be interested in statically linking). However let's say you want to target iOS, then I honestly have no idea what you need to do, as I don't know how Apple has solved this issue (plus you'll be using Apple's toolchains).
A quick googling will provide you years worth of similar discussions with very clear pointers to get a lawyer at the end.
If it ware a simple question the FSF website would have a two sentence answer. It is not.
-
But the GNU FAQ says it in straight text - providing object files satisfies the LGPL relink clause. You can keep your source code proprietary, link statically and still use an LGPL library as long as you provide object files, allowing the end user to relink to a different library version. Are you implying that the GNU license FAQ is incorrect? Because the way they put it, it is very plan and clear, yes you can statically link proprietary code to LGPL libraries.
Qt's own legal FAQ is extra careful to not make a (false?) claim that you can't use static linking under LGPL and keep your code proprietary, yet is very diligent at implying it on several occasions. What is this? Because I can tell you what it looks like, and I hate to say it, but it does look a lot like lying to people to promote commercial license sales. And it doesn't look good...
I'll start off again by saying that I'm not a lawyer.
Oddly enough, you didn't have to be a lawyer, or make such disclaimers last week when you stated that providing object files doesn't allow static linking.
Hopefully you understand my concerns.
-
I do understand the concern, and it is something that I see a lot. I'm just trying to say that it is complicated. The FSF FAQ isn't easy reading and has tons of details. Picking one single item from there isn't really how it's supposed to be done.
Qt is really careful not to say what you can do with LGPL because it is not so simple all the time. Any answers start with a bunch of "assuming that...".
So what is your exact case? (platforms, versions, the whole story) I can try and pry an answer out of a lawyer if one is willing to humour me.
-
My case is not limited to a single platform or version. I don't expect you'd get a free answer for a load of different platforms and versions out of the kind hearted generosity of a lawyer ;)
What might be possible is to clarify that "may". It does seem that the LGPL itself generally allows static linking, but there "may" be corner cases, exceptions or whatnot. THAT is what would be useful to know.
In case of static linking of the library, the application itself may no longer be “work that uses the library”
That's the "may" that needs elaboration. It is understandable why Digia would imply a legal threat here, however it would be preferable if those vague legal threats are elaborated instead of coming under scrutiny for twisting the meaning and intent of the LGPL, something I am fairly certain is NOT legal.
-
I think that single 'may' is the reason anyone has a hard time getting anything out of lawyers. It is very bad form to have such a word in legal text.
What I can with some confidence say is that desktop platforms and static linking LGPL is ok (just make sure that the distribution channels you use are ok with it). Assuming you provide the object files and toolchains (or links to toolchains, when they are considered standard for that platform).
Android makes little sense to link statically, as it has ministro and users tend to be more aware of package sizes. However if one wants to do that, the agreements Google requires look to be ok with LGPL and static linking.
iOS... I have no idea of the current situation. This used to be a real problem, but I hear it has gotten better. But really no idea.
Embedded platforms... not my cup of tea at all. But considering that LGPLwas updated to v3 partially because of embedded closed platforms, I would be careful here. (the points on what is derivative work seem to refer to attempts to close the platform)
-
I am not concerned with embedded, I currently only target user devices. Static linking on Windows would be great, at least when QML modules + static Qt is fixed - hopefully in Qt 5.7. Deployment on windows is a nightmare.
The deployment tool doesn't really work for me, maybe because I am using a 64bit build, it brings in DLLs that are not needed, it doesn't bring in the DLLs that are actually needed, and does even worse with QML modules.
I had to resolve to a brute force dependency sorting - copy ALL dlls and write a script that renames the DLLs one by one and tests whether the application runs, in order to find the actual dependencies. Not pretty. And its like 70 MB of DLLs. Not pretty either. And with a static build I end up with a 10 MB executable.
Deployment for Android does seem to work, but even then, I don't think all that many people are using ministro, in my experience most people use the default option in Creator, which is bundle the .so files in the APK. So size wise static building would be beneficial too, as it will decrease the application footprint.
iOS itself doesn't, or at least last time I checked didn't allow dynamic linking or loading for security concerns. Not on "legit" devices anyway, on jailbroken you are OK.
-
To me it sounds like you are pretty much covered (iOS aside).
The main idea with LGPL is to let the user use and modify the product. Static linking in itself is not bad if the developer is ready to provide the objects and toolchains (and scripts and whatever else is needed for the user to work on the product).
The deployment tools do have their problems, I agree with that. And when I play with Qt, I use the defaults. But then again, I definitely am not a proper developer.
