Does Providing Object Files Satisfy LGPL Relink Clause?

lgplstatic-linking

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?

Best Answer

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.

Related Topic