How can LGPL and proprietary licenses be combined?

Question

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?

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.