My proprietary program dynamically links with an LGPL (2.1 or later) library. However, for technical and practical reasons, the need to distribute the library as a separate .so/.dll file is inconvenient.

I would prefer to statically link with the library, but my understanding is that this is only acceptable if there is some other way for the user to replace the library. Normally, this is done by providing object files and build scripts.

Instead, I'd like to use the following mechanism:

  • My program contains a statically linked version of the library.
  • However, before using the library, my program first checks whether the user has placed a .so/.dll file with a particular name in a particular place.
  • If that file exists, the library is dynamically loaded from that file and used. The statically linked version goes completely unused.
  • If the file does not exist, my program uses the statically linked library.
  • This system is documented, including instructions for building a compatible dynamic library.

In pseudocode,

function_pointer = null

if file "libfoo.so" exists:
    replacement = dlopen("libfoo.so")
    function_pointer = dlsym(replacement, "do_something")
    function_pointer = &statically_linked_do_something


I'd say this complies with the spirit of the LGPL, as it allows the user to completely replace the LGPL library.

But I worry that it may not comply with the letter of the license, because:

  1. The statically linked version remains present in the binary, even if completely unused
  2. The LGPL makes specific reference to object files, and it is not clear if alternative mechanisms are acceptable

I should also note that, if they use this mechanism, the user will be subject to the technical and practical inconveniences that motivated its creation.

1 Answer 1


I believe your proposed scheme is compliant to the LGPL, because

  1. The LGPL does not have the requirement that users must be able to delete the version of the library that you distributed. They just must be able to provide their own version.

  2. Where the (L)GPL speaks of "object code", that term is used to refer to any format of the code that is not source code. It does not specifically refer to .o/.obj files that a traditional C/C++ compiler would generate.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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