4 ms·
LGPL does not allow static linking. From Qt's legal page: In case of dynamic linking, it is possible, but not mandatory, to keep application source code propr
by rlp 9y ago
LGPL does not allow static linking. From Qt's legal page:
In case of dynamic linking, it is possible, but not mandatory, to keep application source code proprietary as long as it is “work that uses the library” – typically achieved via dynamic linking of the library. 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. It is recommended to either link dynamically, or provide the application source code to the user under LGPL.
- jcelerier 9y agoPlease read the link I posted, which comes from the people who created the LGPL license: > 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 The only thing that matters from the point of view of the LGPL is that your users are able to update the LGPL parts in your app. This is possible with static linking. Else for instance how would LGPL be possible with languages that don't even have a notion of linking (eg script languages), or which only allow static linking ? See also : https://stackoverflow.com/a/15322678/1495627 https://stackoverflow.com/a/15322678/1495627
- IshKebab 9y agoThat's quite an ambiguous area of the LGPL. Qt is a C++ app so linking it with the `.o` files from your app is going to be extremely difficult. I'm not sure it would qualify for the LGPL and anyone who says it is is frankly just guessing. The language is not clear and it has never been tested in court (and probably won't ever be). I certainly wouldn't base a business on that risky interpretation, and the one business that I have been in that used the LGPL version of Qt dynamically linked it. It's just less risky (plus you don't need to build it yourself then).