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") else: function_pointer = &statically_linked_do_something function_pointer() 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:
- The statically linked version remains present in the binary, even if completely unused
- 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.
