3

Suppose I distribute a program dynamically linked to a third-party LGPL-licensed library A, which dynamically links to another third-party library B (not necessarily LGPL), all of them distributed together.

Now, I want to want to make this program just work as distributed. For example, the user may have LD_LIBRARY_PATH set (intentionally or not), which contains another version of library B which is incompatible with the version of library A distributed. Therefore, I am tempted to set RPATH for the program (even though RPATH is deprecated and its use discouraged) so that it will override any LD_LIBRARY_PATH set.

But it seems that this would violate LGPL, because from my understanding, LGPL requires that the user of the program be allowed to relink it to any version of library A. Am I correct? Should I prepare a wrapper script that prepends LD_LIBRARY_PATH instead?

Improve this question
4
  • 1
    Where does your RPATH point to? If it points to $ORIGIN/mylibs/blah.so, then in principle a user could use her own version of that library by placing her own version of blah.so at that location. Sure, it's not as convenient to customize as the LD_LIBRARY_PATH environment variable, but it's still possible without recompiling. In any case you'd do well to read section 4e of the license (Installation Information).
    – Brandin
    Jun 22 at 7:08
  • For LGPL 3, the effective definition for the phrase "Installation Information" is defined in the GPL 3.0 - gnu.org/licenses/gpl-3.0.en.html
    – Brandin
    Jun 22 at 7:12
  • @Brandin Yes, it points to somewhere relative to $ORIGIN. I see, so as long as I document how to replace the library, using RPATH is okay. In fact, even if I don't use RPATH, it seems I still should document how to relink the progam (through LD_LIBRARY_PATH or any other way).
    – syockit
    Jun 22 at 14:14
  • I think it would be nice to include this documentation. The extent of the documentation required by the license is not clear (e.g. maybe you can assume a user knows he can replace a .so file or a .dll file with sudo or administrator rights, etc.), but if you briefly explain how to accomplish it, then not only is it nice and convenient for users, but it also means no one can accuse you of not fulfilling your license obligations.
    – Brandin
    Jun 23 at 7:01

1 Answer 1

Reset to default
2

But it seems that this would violate LGPL, because from my understaning, LGPL requires that the user of the program be allowed to relink it to any version of library A. Am I correct?

Yes and No.

The LGPL requires that the end-user, given they have enough technical knowledge, is able to replace the LGPL-licensed portions with a different version of that code.

As far as the LGPL is concerned, that requirement is fulfilled if the end-user can overwrite/replace the binary of library A that you distribute with a different, compatible, version without breaking your application.

Improve this answer
2
  • 1
    The "no" part is that: I don't have to make sure it is relinkable to all versions of library A, but just the versions that are ABI-compatible with the one I distributed, correct?
    – syockit
    Jun 22 at 14:21
  • 1
    The "no" part is that your proposed use of RPATH does not violate the LGPL license. But you are correct that the LGPL also only requires relinking to ABI-compatible versions.
    – Bart van Ingen Schenau
    Jun 23 at 6:21

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.