This was prompted by another question which reminded of a past experience.

Consider the following:

  • An open-source project supports a plug-in architecture
  • The project is released under a copyleft license
  • The plug-ins are discovered by the project by virtue of being installed into a specific directory (i.e. no registration with, modification to, or even recompilation of the project is required to add a plug-in).
  • The plug-ins are self contained, not needing to link to or call into the parent application beyond perhaps including a single header-file for declarations only.

A theoretical example might help to clarify:

  • Project X processes images
  • Plug-ins provide additional algorithms, or support for existing algorithms on new file types.
  • A plug-in simply exports a small number of functions which are called with all the necessary data to perform their processing and return the result.
  • Project X takes care of all rendering, updating menus, etc.

Now suppose I want to publish a commercial plug-in for project X which implements a very proprietary algorithm, and which I intend to sell. Obviously, I don't want to publish the code for this implementation.

Does the copyleft license on Project X consider my code to form a "combined work" or similar term when installed on the user's machine, and thus require me to publish the source code of my plug-in?

4 Answers 4


Maybe. Yes, you have to comply with the terms of the host application's license. However, a copyleft platform can choose to go either way. Some copyleft applications have a specific licensing exemption for plugins; in other cases, the technical architecture does not result in a derived work and thus an obligation.

Consider a plugin architecture where a plugin is just a command line that gets run and reads a file of unformatted data. In such a case, the plugin would involve no IP of the host, and have no interaction with the license. Pay particular attention to the GPL's definitions around 'linkage'.

On the other hand, if the connection between a plugin and its host counts as linking (like: the plugin must link in a library to work), or if a plugin must incorporate source code from the host to build and operate, then the plugin is fully subject to the copyleft terms.

The fact that a user aggregates your plugin with their copy of the platform does not cause you to have obligations. It can't. You're not the one doing the plugging. What causes a derivative work or linkage is the relationship between your IP and the platform's IP.

Given some other answers, I want to point out that there are some areas of open source licensing where the legal situation is clear, and there are some areas where the legal situation is less clear, and some where it's positively contentious. Some of the situations related to plugin architectures tend toward the later side of that spectrum. If you are building a plugin for a GPL-licensed platform, and the copyright owner of that platform makes a public statement that the GPL reaches plugins, you would be wise to avoid betting your livelihood on the possibility that they are wrong, or at least seek competent legal advice.

  • There are interesting elements here ... but I think I'll need to go to a new question at some point. I think my scenario falls outside the linkage definition but need to ponder it more.
    – kdopen
    Commented Jul 17, 2015 at 17:01

The answer is: A host application's license apply to plug-ins written for it if the License is a Copyleft License (such as the GNU GPL), and you distribute the plugin with the application (so no private use exception apply).

(The same rules do not apply for a permissive license such Expat (MIT), but your question specifies Copyleft.)

Drupal is a CMS that uses a plug-in architecture like the one described in the question. Plug-ins for Drupal is known as "modules". Drupal is licensed under the GNU GPL version 2 or later (GPLv2+). This question is answered in the Drupal Licensing FAQ: 7: If I write a module or theme, do I have to license it under the GPL?. Quote:

Yes. Drupal modules and themes are a derivative work of Drupal. If you distribute them, you must do so under the terms of the GPL version 2 or later.

Please note Drupal does not try to stop anyone from distributing Drupal modules and themes outside the Drupal-controlled ecosystem (the Git repo hosted on Drupal.org, and this policy has made some project's move to GitHub). This is because such distros is permitted inder the private use exception.

However, this not some random opinion. The Drupal Licensing FAQ is written by copyright lawyers after careful discussion between the lawyers and the Drupal Association.

Wordpress simply refers to the Drupal FAQ on its page about its license.

Some people say "it depends", and go on to say that it is the software architecture used for linking will decide whether the plugin will be a derivative or not. However, this is very much a programming outlook, not a legal one. As pointed out in this answer, a court may decide that a program that shares a file format with another program will be a derivative work of the latter.

  • Note that Drupal's position depends on linking being considered a derivative work, which is contentious. Commented Jul 16, 2015 at 20:51
  • I also suspect that Drupal's plug ins use resources (functions etc) provided by Drupal itself, so there's a co-dependency
    – kdopen
    Commented Jul 17, 2015 at 17:05
  • @curiousdannii, Drupal's position does not depends on linking being considered a derivative work. The rationale behnd this poition is that modules and themes designed for Drupal depends on Drupal to function (i.e. they do not able to provide any "function" to end users except when they're combined with Drupal). The people in charge of formulating and maintaining this policy for Drupal is completely agnostic about the mechanisms used for creating a composite work. The fact that the linking happens at run-time (which is always the case with PHP) is not considered relevant. Commented Jul 17, 2015 at 17:59
  • This is the first I've heard that dependency in this sense results in a derived work under copyright law, but I'm not a lawyer.
    – bmargulies
    Commented Jul 17, 2015 at 19:36

Yes unless you specify otherwise.

The plugin is derived from the API which specifies which functions the plugin needs to export and what they should do.

If you released X under GPL you can add an exemption for the plugins and dual license the API itself with a less restrictive license that allows non-GPL license for the plugin.

That way you can allow distribution of the plugin alongside the project without requiring the plugin to be released under GPL.

  • But what about opensource.stackexchange.com/questions/762/…? Doesn't that relate to your comment about being derived from the API? Arguably, Google was just implementing the API. How is that different?
    – kdopen
    Commented Jul 17, 2015 at 17:04
  • @kdopen I specifically said that you need to license the API under a more permissive license. That gives permission to everyone to implement it. And that you need to decouple the license of the project from the requirement of the plugin's license. Because X is under GPL that allows everyone to implement that side (under GPL) as well. Commented Jul 17, 2015 at 17:14
  • YEah, I think what I'm struggling with is whether this is an API or ABI
    – kdopen
    Commented Jul 17, 2015 at 17:15
  • This is about an API. ABI is a function-call convention (how parameters are passed and values returned) Commented Jul 17, 2015 at 17:17
  • 1
    Which is exactly what the plugin is implementing . It exports a single function which is called by the host. No calls back from plugin to host. Two physical libraries are ABI compatible if you can use either one without recompiling or relinking the caller. Consider changing a symlink to point to a different library implementation or a point release of the same library.
    – kdopen
    Commented Jul 17, 2015 at 17:18


Many open source CMS projects cover this in their FAQ, Drupal and Wordpress being two notable instances.

The Drupal FAQ #7 states that plugins are derivatives of the original; the Wordpress Support forums tell you the same thing.

From there, it just depends on how the original is licensed. Wordpress is under the GPL, so derivative works must also be licensed under the GPL. Other licenses, such as MIT, might allow you to pick your own license for your plugin even though it's a derivative.

The LGPL, notably, would also in theory allow you to pick your license, because the plugin merely dynamically links to the original work, which is allowed under its terms. However, check that one before using it - IANAL.

  • We have chosen the LGPL for the GIMP libraries to allow for different licenses for plug-ins - and so far, no one has told us that there would be any problems with that. On the contrary, we have been criticized for not making that part strong copyleft as well :) Commented Jul 16, 2015 at 18:25
  • But in my scenario, this would not be true: "because the plugin merely dynamically links to the original work" Beyond knowing the signature of the function to be exported, there is no linkage from the plugin to the host app.
    – kdopen
    Commented Jul 16, 2015 at 19:19
  • @kdopen It's an interesting conundrum. I wouldn't rely on that protecting you from lawyers, they may claim that's enough of a link.
    – ArtOfCode
    Commented Jul 16, 2015 at 21:19
  • Yeah, hence the question :)
    – kdopen
    Commented Jul 16, 2015 at 22:35
  • Note that Drupal's position depends on linking being considered a derivative work, which is contentious. Commented Jun 26, 2016 at 21:49

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.