7

This is a bit similar to what asked in this question, unless that here the case is that the application only directly loads LGPL code, and this one then may dlopen a proprietary lib, so:

  • GPL Program links to an LGPL library
  • LGPL library can dlopen's and use a proprietary module (optionally linked with the lib), that is optional to have
  • The module will provide structures and methods that the GPL application will consume or call, but will not use any library or data of the GPL application, while it will use the ones provided by the LGPL lib.

So, is this legal (as this parapgrah is a bit confusing)?

5
  • 1
    How do you plan to distribute this GPL + LGPL + proprietary module combination (the GPL calls this a "Combined Work")?
    – Brandin
    Dec 18, 2019 at 18:36
  • By the way, dlopen is equivalent to dynamic linking. So it's simpler if you just say that you've got an LGPL program linked with a prioprietary one, which is generally fine (the whole point of the LGPL is to allow that). But linking a GPL program with a proprietary one is much more questionable; your question seems like it is actually about that. I don't understand why you also throw in the LGPL part.
    – Brandin
    Dec 18, 2019 at 18:38
  • See also this GPL faq item which seems to directly address this question (linking GPL + proprietary module): GPL FAQ - How can I allow linking of proprietary modules with my GPL-covered library under a controlled interface only?
    – Brandin
    Dec 18, 2019 at 18:40
  • @Brandin GPL and LGLP work will be distributed by a standard linux distro, while the proprietary code will be added by HW producers.
    – Treviño
    Dec 19, 2019 at 13:47
  • 1
    @Brandin I'm mentioning the LGPL part, because it's the library that loads the proprietary lib, not the program itself that works anyway without the shared proprietary module. And the program is GPL while the library that it uses is LGPL
    – Treviño
    Dec 19, 2019 at 13:48

1 Answer 1

3
+25

No, what you propose is not legal.

The LGPL license is written in such a way that the linking exception only works one way.

  • All the code that an LGPL library depends on must be under a GPL-compatible open-source license
  • Code that depends on an LGPL library may use a GPL-incompatible license.

The fact that the LGPL library gets used by a GPL application is not really relevant.

The only way out is if the proprietary code can be treated as a plugin that only communicates "at arms length" with the GPL application and the LGPL library. This means that the proprietary code must run as a separate process and the (L)GPL code may not depend on (complex) data structures defined by the proprietary code.

6
  • The LGPL library doesn't depend on proprietary code, the library may load at runtime some proprietary code (hw drivers, afterall), but would work even without it.
    – Treviño
    Jan 8, 2020 at 21:26
  • @Treviño, loading a driver with dlopen is also a form of dependency, even if the code can function without that driver. Jan 9, 2020 at 7:27
  • Mh, i'm not fully sure. One thing is that this library can be de-facto considered an application because by definition is "any work that makes use of an interface provided by the Library, but which is not otherwise based on the Library.". So given that the driver only uses the LGPL library interface, but not its code, it should not violate anything, isn't it?
    – Treviño
    Jan 10, 2020 at 13:52
  • 2
    gstreamer.freedesktop.org/documentation/… isn't a similar case?
    – Treviño
    Jan 10, 2020 at 14:20
  • 2
    Even better: gstreamer.freedesktop.org/documentation/… clarify the case, it seems it's basically the very same situation, so once the plugins is distributed alone there's no problem with this.
    – Treviño
    Jan 10, 2020 at 14:26

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.