Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
LGPL Static Linking
learc83 last edited by
After reading up on the LGPL license it seems that I'm probably OK releasing statically linked executables as long as I include a way for end users to change/update the Qt libraries the library uses. 
I've heard talk about releasing object files so end users can recompile, but what about just releasing 2 versions of an executable-- One that is statically linked and one that is dynamically linked. That way anyone who wanted to change the libraries could simply download the dynamically linked version.
MuldeR last edited by
This all comes down to the question, what is considered a "work that uses the library" and what is considered a "derivative of the library". If your program is a "work that uses the library" you may release it under a proprietary license, even if it uses a LGPL'd library. Only any modifications that you applied to the library itself would ave to be released under the LGPL. BUT: As soon as your application becomes a "derivative of the library", the complete source code of your application must be released under the LGPL, no matter what.
The LGPL says:
[quote]A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.
However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables.[/quote]
This all is a bit vague and I'm not a lawyer. But I know from my experience as a software developer that linking an application against a "shared" library (DLL or SO or DYLIB file) is generally accepted as being a "work that uses the library". At the same time, when linking the library in a "static" way, the resulting all-in-one binary (EXE) file, is considered a "derivative" of the library.
That's why commercial application, if they make use LGPL'd libraries, pretty much always ship those as a separate DLL or SO or DYLIB file...
See also here: