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.

  • 1
    Strongly related: opensource.stackexchange.com/q/4431/240
    – Mark
    Dec 8, 2022 at 22:29
  • 2
    Specifically about 'modifying' the license. You can release your own code under any and all licenses you wish to. If you have code written by others, you need to abide by whatever license gives you the right to use that code. If you previously released your code under the GPL and someone has it, they still have the right to use that version, and to make changes and release them under the GPL. But what you're doing sounds like you couldn't claim your code was GPL, you would have to write your own license. Dec 9, 2022 at 2:14
  • Also note that you could not force people to release their plugins under the GPL for the simple reason that linking them to your proprietary software would be forbidden, a catch-22. The LGPL might be appropriate for that, I don't know. Dec 9, 2022 at 2:15
  • What do you wish to achieve with this? The whole idea of the GPL is to avoid what you want to do. Dec 9, 2022 at 7:43
  • Is it possible at all to impose license requirements on the authors of plugins? My very primitive understanding of the case law is that if a new piece of software is designed to interoperate with an old piece of software, then usually, either the new piece of software is considered to not be a derivative work of the old software at all, or the use of the old software's interface is considered to be fair use. Dec 11, 2022 at 14:37

5 Answers 5


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:

  • If the source is available, it's open source... The FSF doesn't get to decide what terms in the English language mean Dec 11, 2022 at 12:58
  • @ScottishTapWater In a software context, the phrase “open source” was coined in 1998 by Christine Peterson, to avoid misleading connotations of the phrase “free software”. Later that year, the Open Source Initiative (OSI) was founded, and the Open Source Definition (OSD) was created, based on the Debian Free Software Guidelines (DFSG) by Bruce Perens. You're entirely right to point out that the FSF is not very relevant here, even though the OSD and the Free Software Definition are practically equivalent – the term “open source” is literally just a rebranding of the software freedom concept.
    – amon
    Dec 11, 2022 at 14:37
  • My comment stands even if you want to re-aim it at the OSI... They've got no right to dictate what it means either. They're not democratically elected by developers, nobody gave them that right. "Open Source" means exactly what you think it would prima facie... That the source is open and available. FLOSS has other connotations, but Open Source doesn't and I'm fed up of the OSI/FSF trying to dictate what is and isn't "good enough" when it comes to just how permissive open source devs want to be with their projects Dec 11, 2022 at 15:00
  • @ScottishTapWater Words have meaning, and it is helpful to be clear when talking with each other what we mean. If you want to talk about software where the source code is available, I'd suggest that you prefer the term “Source Available software”, just like I typically prefer the term “Software Freedom” when I talk about philosophical aspects. Note also that this site has defined that “open” is defined by the OSI Open Source Definition, see the help center.
    – amon
    Dec 13, 2022 at 8:29

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.

  • 14
    "you have no power to stop the downstream licensee from adding his/her new calls to the list of exempted calls" Huh? How can the downstream licensee add new exceptions to a license that also covers code that he didn't write? Can I modify two lines of the Linux kernel and also change the license text from "via normal syscalls" to "via normal syscalls or by linking to it"? Dec 8, 2022 at 18:37
  • 1
    @DavidSchwartz I think your understanding is the "correct" one, but I could see this going either way in court.
    – wizzwizz4
    Dec 8, 2022 at 18:45
  • 3
    @wizzwizz4: LKNL has a list of symbols that non-GPL'd kernel modules are allowed to call. I'm convinced that if a non-GPL'd kernel module were shipped with a patch that added new calls to the list it would get hammered down.
    – Joshua
    Dec 8, 2022 at 20:53
  • 1
    @DavidSchwartz the downstream licensee isn't adding exceptions to a licence that covers code he didn't write; the downstream licensee is adding a permission to the code he did write, which is perfectly lawful. You may not do what you describe with the Linux kernel, but you may add a syscall and specifically state that it's a normal syscall. Upstream may not accept that characterisation, in which case there's going to be a fork, but upstream can't stop you from distributing your version with the permission on your syscall.
    – MadHatter
    Dec 9, 2022 at 9:23
  • 2
    @MadHatter He's adding permission to interact with code he did write as a license exception for use of code he did not write. But he cannot add exceptions to the license of code he did not write. To distribute the code he did not write, you must comply with the license of the code he did not write with only the exceptions that the license for the code he did not write offers. The linux license works precisely because it specifies the bounds of the exception and doesn't require anyone to modify it. Dec 9, 2022 at 9:31

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.


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.


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.

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.