5

We are building an embedded system where performance and startup time is important and space is sparse so I had the idea to statically link to a LGPL licensed library AND - in case a .so of this lib is present - prefer the dynamically loaded library.

The system is only used internally and by external service providers doing contract work for us.

Is this compliant with the LGPL terms?

Edit: Specifically this section is interesting 4.d.1):

https://www.gnu.org/licenses/lgpl-3.0.html

Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version.

This section does not make any statement regarding the additional static linking. Both a) and b) should still be satisfied.

12
  • Linking is not covered by the LGPL at all, so as written this is compliant. What do you do with the binaries once you have linked them? Aug 23, 2021 at 16:26
  • 5
    @Philip I think the relevant question here is "does this approach satisfy the requirement to grant recipients (i.e., the contractors) ability to relink with a modified library?"
    – apsillers
    Aug 23, 2021 at 21:06
  • @PhilipKendall once linked there will be one big elf file (which can also be shared with everybody) which is converted to a binary stream and downloaded to a embedded hardware device.
    – sneusse
    Aug 24, 2021 at 7:12
  • @apsillers yes that's what I would like to know. There will be a folder accessible via FTP on the device where everybody could place a modified version of the library. Additionaly the single static ELF file itself could be made available so anybody could strip the library symbols and relink with a modified version again.
    – sneusse
    Aug 24, 2021 at 7:17
  • 1
    If the space is so limited in the execution environment, then how will I actually have room to place MySpecialLibrary.so next to your binary in order to run it?
    – Brandin
    Aug 24, 2021 at 12:15

1 Answer 1

3

I think this is legally fine, but not technically feasible.

You're proposing that a library is linked into a binary both statically and dynamically, with the statically linked version serving as a fallback in case no dynamically loadable library has been provided. This seems to meet the LGPL-3.0's definition of a “suitable mechanism”. The phrasing of that definition says you must be able to operate properly with a dynamically loaded library provided by the user, not that it must be possible to remove the old version.

But this is easier said than done. You might have to effectively implement your own static and dynamic linker for this to work. With static linking, calls are resolved at compile time, and optimizations such as inlining are possible. This would be incompatible with your goal of linking the library dynamically instead. The dynamic linker would also need to know that this library is optional. An alternative might be to load the library explicitly via dlsym() and to make all calls through a function pointer table that you create yourself, but that might be error-prone. There could also be interesting conflicts if the library in question uses global variables or has initializers/finalizers. All that I know about ELF points toward this approach being a bad idea.

I think the most realistic approaches are going to be:

  • Just use dynamic linking. This is going to be the easiest solution by far. Relocation is cheap compared to the effort of combining static with dynamic linking, unless you're operating at massive scale.
  • Just use static linking, and recompile with modified library versions if necessary. It seems that the software in question will only be used within your organization and by its agents, not e.g. by customers or external partners. It is questionable whether the LGPL would even impose any conditions in this scenario.
2
  • Thanks for the answer and your ideas! An alternative might be to load the library explicitly via dlsym() and to make all calls through a function pointer table that you create yourself That's by the way how it is implemented now, called with the handle of the dynamic lib or with NULL to be found in the static image.
    – sneusse
    Aug 25, 2021 at 6:37
  • It is questionable whether the LGPL would even impose any conditions in this scenario. Yes, that might be true as well but I cannot be sure about that.
    – sneusse
    Aug 25, 2021 at 6:47

Your Answer

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

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