5

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)?

  • 1
    How do you plan to distribute this GPL + LGPL + proprietary module combination (the GPL calls this a "Combined Work")? – Brandin Dec 18 '19 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 '19 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 '19 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 '19 at 13:47
  • @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 '19 at 13:48
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.

|improve this answer|||||
  • 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 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. – Bart van Ingen Schenau Jan 9 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 at 13:52
  • 1
    gstreamer.freedesktop.org/documentation/… isn't a similar case? – Treviño Jan 10 at 14:20
  • 1
    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 at 14:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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