Allow non-GPL plugins in a GPL main program

Question

Suppose I'm writing a certain program, which I wish to license under strong copyleft license such as GPLv3. At the moment I have not used any 3rd party GPL code (I think there might be an LGPL library but I assume that's not an issue), so if I understand correctly I'm allowed to modify the license (Am I mistaken?)

Anyway, the main issue is that the program supports plugins loaded at runtime (binary DLLs) and presents a certain plugin API. I wish to allow 3rd parties to distribute non-GPL plugins if they wish, but only if they use the official plugin API and nothing else. To avoid any workarounds, I also want to forbid adding new API calls to the main program, or more accurately, adding such API calls would be allowed but any plugin using any such added calls would have to be GPL licensed.

I'd like to know whether that is possible and how do I add that permission to the GPL license.

Answer 1

Maybe possible, but could be tricky.

As the only copyright holder to the GPL-covered components of the software, you are free to add exceptions and additional terms to the GPLv3, as described in section 7 of that license. In fact, the LGPLv3 is just such a GPLv3 section 7 additional permission, allowing the component to be linked to proprietary code.

Writing your own additional permissions is tricky, just like writing your own license is tricky. If in any way possible, strongly consider whether the existing LGPLv3 or other widely accepted GPL exceptions would be sufficient for your purposes.

But yes, in principle you could write your own exception that only grants permissions to link with modules that use a specific plugin API. It is tricky to define that well, since it would be permissible (under the GPL) to change that plugin API, possibly widening it more than expected. It could be necessary to tie the license exception to versions published by you, but that would raise the question whether the resulting license is Open Source in practice (while it would certainly be GPL-compatible, the power asymmetry introduced by the exception could be argued to violate the Open Source definition).

There is prior art for a GPL-covered program that loads non-GPL extensions, but only permits access to specific APIs: the Linux Kernel. All kernel modules must declare a license. If the module declares a GPL-compatible license, the module has full access to the kernel's APIs. For other licenses, only access to a restricted subset of APIs is granted. The enforcement here is primarily legal, but the kernel also uses linker tricks to enforce proper licensing on a technical level. The kernel also does not expect eBPF programs to have a GPL-compatible license, since these are essentially user-space programs executed in a virtual machine.

In practice, it is probably best to side-step the in-process plugin question entirely. For example:

• only allow GPL-compatible plugins, as would be the default here (compare also GPL FAQ entry “If I write a plug-in to use with a GPL-covered program, what requirements does that impose on the licenses I can use for distributing my plug-in?”).
• provide a plugin interface that makes it absolutely clear that the main program and the plugin are separate programs, and not combined into a single program. This is typically done by having the program and the plugin communicate over a simple protocol via pipes or sockets. For example, the program might offer a REST API on a localhost server. Personally, I think that such a clear separation could also be maintained within a process using sandboxing technologies such as WASM.

Answer 2

As long as you are the sole rightsholder, or have the consent of all other rightsholders, licensing under GPL-plus-exceptions is perfectly lawful.

The canonical example is probably the Linux kernel, which makes clear that user-space programs that access the kernel via normal syscalls are not considered derivative works, and so are not required to be GPL-licensed, which allows proprietary software to run on Linux.

I'd use the kernel exception document as a starting point, and write something similar that specifically says that plugins using only the following API calls (insert list) are not considered derivative works.

Note that if you accept contributions, you'll need to get contributors to accept a CLA that permits you to make this exemption for versions of the core code that include their contributions.

I also want to forbid adding new API calls to the main program, or more accurately, adding such API calls would be allowed but any plugin using any such added calls would have to be GPL licensed

This is a problem. Any modified version, such as one that added extra API calls, would be a derivative, and would need to be licensed under GPL; but you have no power to stop the downstream licensee from adding his/her new calls to the list of exempted calls. You may, however, refuse to accept those into your version of the core software, or refuse to accept them unless the contributor agrees not to add the new calls to the exemption list.

Answer 3

I suggest you can use GPL-3.0-or-later WITH GCC-exception-3.1 for your case.

That's the GPLv3 with the GCC Runtime Library Exception 3.1.

The exception text states:

The purpose of this Exception is to allow compilation of non-GPL (including proprietary) programs to use, in this way, the header files and runtime libraries covered by this Exception.

So, adding new API would fall under GPLv3, but using existing API would be covered by this exception, if the plugins are considered "Independent Modules".

The main part of the exception text reads:

You have permission to propagate a work of Target Code formed by combining the Runtime Library with Independent Modules, even if such propagation would otherwise violate the terms of GPLv3, provided that all Target Code was generated by Eligible Compilation Processes. You may then convey such a combination under terms of your choice, consistent with the licensing of the Independent Modules.

Answer 4

The key thing is not really an exception to the license. The key thing is to make sure that the new code for the plugins is not a "derivative" of the original code.

There are several things you should do to ensure this

• provide a clear simple documented interface and state clearly that any code examples in that documentation under a clear license like the MIT license which has no restrictions
• give an example plugin that people can start from and make the code of that example be under a different license such as, again, the MIT license
• provide further documentation and explanations of how to write plugins and make that documentation and any contents of it be under the unrestricted license

In creating these files and documents, since you are the original author of the program, you are clearly within your rights as long as you don't copy from ("derive from") anyone else's code which you used in your program.

Once these things exist, plugin authors can use them freely because they are under an unrestricted license and not under the GPL license. If you don't do this then plugin authors probably can find a way to do things similarly but it will be much more difficult and would have legal risk so they probably won't want to do that.

Answer 5

A fundamental principle of GPL is that any distribution that contains GPL code written by anyone who has not agreed to alternative terms, must either:

1. Merely include the code, unmodified, as part of an aggregation that is not a derivative work, or

2. Be a derivative work which is covered under GPL.

An additional principle is that there are no restrictions upon the production of derivative works that are not distributed.

Thus, one may distribute a quantity of code under whatever license one sees fit, along with an unmodified copy of GPL code, and instructions for how to produce a derivative work that combines them, but which may not be distributed. If your code is designed in such a way that plug-ins would need to incorporate some of your copyrighted material, then you could impose whatever license terms you want on the material in question. On the other hand, if you're intending that your code be freely distributable as opposed to commercially licensed, someone could distribute code for a plug-in which is complete except for your portion, along with instructions on how to incorporate the appropriate parts of your freely distributable code.

If you were commercially licensing code, recipients of such instructions would be required to buy a copy of your code before they could incorporate it into their plug-in, but if your code is deliberately freely distributable, I think you have to allow for the possibility that recipients might do things you don't like.