From this question on SO, I read that:

Proprietary Source code + LGPL Source code

  • statically linked:
    • Either you must release both parts as LGPL.
    • Or provide everything that allow the user to relink the application with a different version of the LGPL source code. In this case the other requirements are the same as if it was dynamically linked.

So it does sound like providing object files is enough to satisfy LGPL in terms of statically linking a LGPL library to a proprietary code application. While the executable is statically linked, providing the object files allows the end user to recompile the application, linking to different version of the library.

Is this correct, and if not, then why?


Yes, you are completely correct. Providing the object files for your application is sufficient to satisfy the LGPL because it allows the user to replace the LGPL'd library with some other version if they so choose.

The FSF even says so explicitly in their FAQ:

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.

(2) If you dynamically link against an LGPL'd library already present on the user's computer, you need not convey the library's source. On the other hand, if you yourself convey the executable LGPL'd library along with your application, whether linked with statically or dynamically, you must also convey the library's sources, in one of the ways for which the LGPL provides.

  • 1
    So why are Qt "insiders" and employees continuously claiming otherwise? Is Qt's LGPL modified or something?
    – IvanB
    Mar 14 '16 at 23:08
  • I'm not familiar with the Qt situation, but from skimming their licensing pages I don't see any language that explicitly denies this possibility. I think they merely omit it in favor of recommending dynamic linking (which probably is the simpler solution for most users). The most relevant wording I see is: "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.", which is entirely reasonable.
    – Ixrec
    Mar 14 '16 at 23:23
  • It also looks like some modules of Qt are only available under the GPL rather than the LGPL, if I'm reading these pages right, so it's possible that if they did mention the static linking with objects option they'd have to also tack on "unless you use X, Y, or Z" and similar boring tangential details.
    – Ixrec
    Mar 14 '16 at 23:26
  • 1
    In a perfect world, dynamic linking might be great, but in this world and when dealing with Qt, dynamic linking is hell. Like 60+ megabytes of dlls, many of which the deployment tool doesn't bring in and dependency walker doesn't detect. In their own LGPL FAQ I see a 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. but nothing about being mandatory.
    – IvanB
    Mar 14 '16 at 23:31
  • 6
    Reading their FAQ, it seems they are just shy of making a (false) claim that LGPL doesn't allow proprietary applications to link statically to Qt, while very diligent at implying it.
    – IvanB
    Mar 14 '16 at 23:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.