I have a project, a big portion of which can be released as LGPL, but there are still some portions that must keep a more restrictive license. I'm not sure what exactly is allowed. The intent is distributing the whole package with source code, but allow redistribution and modification beyond personal use only for the LGPL portions.

  1. Can a proprietary program link to an LGPL library? Yes, that's the main point of LGPL, I understand.

  2. Can the link be static or dynamic? Yes to dynamic, for static linking a way to link to a later version must be given. I assume this is subject to "later versions" being compatible, and providing the source code (and necessary build elements) is enough, even if the source code is not redistributable.

  3. Can an LGPL program link (dynamically or statically) to a non-free library? In this case it would be an "optional" feature, a way to get some enhanced functionality, but the core of the program would work fine without the library.

  4. Can the build system for the LGPL code dynamically (and optionally) fetch non-free code and compile it? Say I distribute the LGPL source code, everyone is free to use it, compile it and redistribute it; but those with an "extended" license get access to additional non-free code which they can compile together with the LGPL portions, and they are not allowed to redistribute this part. Would that be fine?

  5. Assuming the authors and copyright holders agree, can the LGPL license be modified to add an exemption that allows linking to other proprietary portions of the project?

  • If you are the copyright holder of all the code, as I gather from your question, you are not bound by the LGPL and can do whatever you want with your code.
    – EMBLEM
    Aug 21, 2016 at 15:25
  • 1
    @EMBLEM Indeed, but there may be other contributors in the future. And especially if they modify the LGPL portions, I won't be allowed to do "whatever I want" with the modified LGPL code ;)
    – Jellby
    Aug 22, 2016 at 8:40

1 Answer 1


Let me first specifically answer each of your questions, and then I will give you my real advice.

  1. Yes, it can.

  2. You are right to think that the difference between dynamic linking and static linking is to allow users to upgrade the library. So you can link statically if you provide the full source.

  3. No, by default a LGPL program cannot link to a proprietary library. LGPL is basically GPL + an exception allowing proprietary programs to link to it. So the general guidelines on what is possible inside GPL programs still apply. If you want to do such linking, the FSF recommend adding an exception to the license: https://www.gnu.org/licenses/gpl-faq.en.html#GPLIncompatibleLibs So now, you have the GPL with two exceptions: one to allow linking from proprietary, one to allow linking to proprietary!

  4. Yes, as far as I can see that would be fine because you are distributing the two parts separately and the user makes the linking. In that case, it would even be fine with a GPL license. The restrictions apply only when you redistribute, not to personal use.

  5. Yes, see the answer to (3). However, multiplying exemptions is generally risky as you are basically creating "a new license" less well-known with no existing court cases to rely on to interpret it.

My advice

Are you aware of the philosophy behind the GPL and LGPL? https://www.gnu.org/philosophy/philosophy.html It was not created for such a use case. See in particular this piece on the LGPL https://www.gnu.org/licenses/why-not-lgpl.html

It so happens that another weak copyleft license has been created by people who really wanted hybrid software with an open source part and a proprietary part to be possible. It is called MPL 2.0, it is compatible with (L)GPL and it is much simpler to use. Its principle is very simple: it applies to each file independently. Those files where it applies are open source and protected by copyleft but they can be combined in whatever way with proprietary files.

  • Thanks. Regarding #4, would the user be allowed to redistribute the compiled binaries? LGPL says yes (I think), but the closed-source parts of the code prevent it. Is there a conflict?
    – Jellby
    Aug 22, 2016 at 8:48
  • No, unless you make specific provisions to allow it, the user would not be allowed to redistribute the binaries for two reasons: because of #3 and because the resulting binaries would be proprietary overall. If I didn't get your query, please elaborate by editing the original question.
    – Zimm i48
    Aug 22, 2016 at 9:31
  • 1
    Re point 2: You can satisfy this requirement by providing object code only (i.e., the collection of the .o) and the scripts/Makefile to rebuild the executable(s). No source.
    – vonbrand
    Aug 23, 2021 at 22:17

Your Answer

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

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