23

Let's say I develop a plugin for third-party application X. My plugin has a non-free license, and is commercially distributed. I don't distribute application X.

Application X is licensed under GPL, so an end-user of X who installs the plugin creates a combined work - which can't be redistributed as it includes my non-free plugin.

The GPL FAQ implies my plugin "should" be licensed under GPL, but unless the plugin linkage mechanism required me to compile or distribute some GPL'd files, I can't see how that can ever be applied.

If the GPL FAQ wrong, or just saying what they'd like people to do...?

  • 3
    Is this a Wordpress plugin? Because there is existing research into how the GPL affects Wordpress plugins specifically that would be very relevant to your question – Fred Stark Mar 10 at 2:58
  • 1
    Under which terms should that "combined work" be redistributed? If your plugin has a non-free license and should be bought, why should anybody else bundle it and redistribute it? – Nico Haase Mar 10 at 10:17
  • @FredStark, no, not a WP plugin. Although I'm be interested in how that's handled. – Roddy Mar 10 at 14:28
  • 3
    For WP, all plugins must also be GPL (even though many are violating terms by being proprietary). They hit all the criteria of the top answer: they behave as part of WP, access internal data structures and are non-functional without WP. – Fred Stark Mar 10 at 23:16
48

If your plugin is a derivative work of the GPL-covered software, then you can only publish/share/distribute your plugin under the terms of the GPL.

It is not clear when a plugin is a derivative work. It seems to be the belief of the FSF (the GPL authors) that the following aspects can indicate derivativeness:

  • the plugin is designed to be combined with a GPL'ed work, in particular that the plugin is nonfunctional without the GPL-covered software
  • the plugin is designed to be linked into the same process as the GPL'ed host application
  • the plugin accesses internal data structures of the host application, i.e. behaves as part of that application

In contrast, the FSF seems to believe that plugin-like services that run in separate processes and communicate over some protocol are not derivative works. For example, microservices communicating over a REST API are clearly separate works from each other. Similarly, AGPL-covered database servers have no licensing impact on the software connecting to that database.

Some people believe that the FSF's interpretation is incorrect, especially around linking. However, you are betting a business on interpretations of copyright law. It may be wise to assume the “worst case”, i.e. that the FSF's interpretation would be upheld in a court.

Other people believe that even the FSF's criteria are too narrow, and that the use of APIs could be copyright infringement without a proper license. This is related to the U.S. Oracle v Google case.

You are also making a different argument, that the customer and not you is combining the GPL'ed with non-GPL'ed software.

  • as discussed above, your plugin might be derivative regardless of whether its combined into a single work
  • there is still the issue of contributory copyright infringment, or a judge might not follow your argument that an assembly kit is totally unrelated to the assembled thing

If you do want to walk the fine line around the edges of GPL compliance, please get a lawyer to assist you. They have deeper knowledge about the copyright laws in the jurisdictions you are targeting.

In practice, it's often much easier and safer to keep a bright line between the GPL software and the proprietary software, e.g. by having a GPL-covered plugin that exposes relevant functionality via a REST API, and a clearly separate proprietary service that makes use of this API.

| improve this answer | |
  • 7
    This answer deserves a rating of 5/5 for being both comprehensive and considerate. – planetmaker Mar 9 at 14:11
  • 1
    Thanks for this. The "derivative works" section seems the key. I also found this, which is relevant and interesting. courses.cs.washington.edu/courses/cse490t/11sp/docs/… . The author notes that contributory ingringement is likely to fail because of the rights granted to users of GPL software. – Roddy Mar 9 at 14:27
  • 3
    @Roddy I agree that the contributory infringement argument is not particularly strong, as there's no primary infringement. However, I don't necessarily agree with the linked article, as it bases some of its arguments on logical fallacies. E.g. they parse the FSF's opinion as “out of process implies not-derivative” which read literally leads to contradictions. The clearer and obviously intended reading would be “in-process indicates derivative”. The fallacy is suggesting the two statements A → B and ¬A → ¬B are equivalent and then choosing the incorrect variant without justification. – amon Mar 10 at 7:29
  • 1
    @Roddy a license grants you (limited) rights which you do not otherwise have. Finding something without a license to use it does not mean you are free to use it how you wish, it means you may not use it. – Jacob Raihle Mar 10 at 17:04
  • 2
    @Roddy The default license is “all rights reserved”. If APIs are copyrightable and if you do not have a license, then implementing a plugin using that API may be a copyright violation, regardles of whether you developed it against a working system or against the API docs. Your recipe example ignores that copying and creating derivative works is reserved under copyright, but using information or cooking a meal is not. This is in contrast to patents, which also cover mere use. – amon Mar 10 at 19:41
4

The wording "should" is a dead giveaway. The FSF would generally like you (and everybody else) to comply with their ideology but they have no real means of forcing you, in general. That's not necessarily a bad thing because although it's a bit quixotic, the FSF ideology isn't bad.

In general, you are legally bound to comply with all terms that anyone (not just the FSF) puts in a license (not just GPL) if you do something, anything, that makes you subject to the license.
If you do not do anything that makes you subject to the license, people may still have opinions and wishes, but they are just that. Much like vegans tell you every day how eating animals is bad, and that you "should" not do it, but they have no means of enforcing their ideology.

In the case of GPL, in order not to be bound by its terms (all of them!), what you need to avoid is, in very simplified and somewhat inaccurate words, distributing a program that includes, links with, or derives from code which is under that license.

In some people's opinion, plugins are by their very nature derivative work since they cannot work without the host application. While there is a grain of truth in that argument, I nevertheless beg to differ on that opinion for the general case.
A plugin needs a host application to run, that's true. However, this needs not necessarily be one particular application, or even an application that is under some particular license (including GPL). Also, a plugin hopefully adds something to the program rather than just exposing functionality that is already present anyway.

Examples of plugins that will very well work with different applications can be found in the audio/video and graphics world. The same, identical plugins will work interchangeably with different programs. Plugins written in embedded scripting languages would be another example, they are not necessarily bound to one particular application.
Another example where the logic doesn't hold would be dual-licensed software. For example, you can have MySQL under two different licenses where one is GPL, and the other is not. MySQL supports plugins. So, whether or not your plugin falls under GPL depends on whether some future client buys a commercial license from Oracle? And your obligations are different for everybody else? Or only until the first person buys a commercial license? Well, no, that's hardly how it is...

So, in my opinion, the idea that a plugin is necessarily a derivative work doesn't hold. It may be, can be, but doesn't need to be.

Note, however, that a plugin needs to follow some kind of specification (some particular file format, magic numbers, exported symbols, etc) and possibly use an API of sorts to connect itself to the application. Which may require e.g. including some headers (that contain inline functions) or linking to some libraries. Or, whatever.
These may or may not be licensed under the GPL like the application, or they may be under the GPL, but with an explicit exception. You will need to verify to be sure.

Also, it is important to note that the FSF doesn't own the rights on the software (nor do I, or any other random person here), so whatever they think is widely irrelevant. What the actual author(s) has/have in mind is what's relevant.

Therefore, when in doubt about the exact intent, it is a good idea not to ask FSF or a Q&A site, but to contact the authors. A lawyer cannot really help you either (the lawyer can express an opinion, but although this opinion is very expensive, it is also entirely worthless).

Ask the authors what their intent is. Quite likely, you will get an answer like "Wait, what? No, of course that's not intended, please go ahead, write your plugin!".
That's because plugins, whether open-source or not, greatly enhance your software's visibility, exposure, and overall value. Few authors will turn that down for ideology. But if they do turn you down, you know. That's more than anyone else (me, someone else on this site, or your lawyer) can tell you.

Get an authorative reply from the authors / copyright holders, it's the only thing that matters. Whatever is written in some license document or one someone's website is entirely irrelevant, since they simply do not have a say. The only ones who do have a say are the authors.

| improve this answer | |
  • 2
    If the author of a plug-in documents everything necessary to make a program work with the plug-in, and bundles an original program that does so, the fact that the plug-in also works with a GPL program should not make the plug-in subject to the GPL. – supercat Mar 10 at 18:43
3

Most of these questions have not been decided in the courts, and it's anyone's guess how they would be decided if the question came up. A lawyer's guess might be better than yours, or it might not; the language in the FSF licenses is so vague technically that I certainly wouldn't want to hazard a guess myself.

So it comes down to what risks you are prepared to take. And remember here that risk equals (what an event would cost you) times (how likely is it to happen); so this means thinking about who might be motivated to sue you.

My own experience of developing open source software is that all the licensing questions come from my customers, not my suppliers. The people who actually wrote the open source components I use are perfectly happy for me to use the stuff. It's the customers, especially mega-rich customers (the IBMs, Microsofts, Oracles, and Googles of the world) who worry about it, partly because they employ expensive lawyers who are paid to worry (and anyone who is paid to worry does a lot of worrying), and partly because these companies are much more attractive targets for patent and copyright trolls than I am. So my advice would be: don't consult your lawyers, consult your customers. It doesn't matter what the license says, or what your lawyers say, it matters what your customers are happy with.

| improve this answer | |
  • Customers are generally happiest with whatever is the easiest or cheapest option for them. If this runs afoul of the GPL then it generally is no concern to them unless you make it a concern. – doneal24 Mar 10 at 18:02
  • As I explained in my answer, my experience is that big companies are often more concerned with risk than with price or convenience, – Michael Kay Mar 11 at 20:01
3

Let's say I develop a plugin for third-party application X. My plugin has a non-free license, and is commercially distributed. I don't distribute application X.

Okay. That would require that your plugin not be a derivative work of any work covered by the GPL. That means that it cannot contain sufficient protectable expression from the work that is covered by the GPL. It is quite hard to figure out what "sufficient protectable expression" means precisely, but that's the legal standard.

Application X is licensed under GPL, so an end-user of X who installs the plugin creates a combined work - which can't be redistributed as it includes my non-free plugin.

That's correct. Note that it's a combined work, not a derivative work. This is no different from me taking two DVDs and stapling them to each other.

The GPL FAQ implies my plugin "should" be licensed under GPL, but unless the plugin linkage mechanism required me to compile or distribute some GPL'd files, I can't see how that can ever be applied.

Whether your plugin "should" be licensed under the GPL is moral question. Whether it has to be is a legal question. The standard is pretty clear -- it has to be if it contains sufficient protectable expression taken from a work covered by the GPL and to which you have no other license. The application of that standard is, however, not so clear.

If the GPL FAQ wrong, or just saying what they'd like people to do...?

I think they're mostly trying to both explain their opinion about what the GPL means and to provide some clarification of their intent in case that might help influence future courts. But it's hard to say without just speculating.

What is clear is that your work has to be covered by the GPL if it's a derivative or combined work including sufficient elements of protectable expression from a work covered by the GPL (assuming you have no other license to those elements). What's much less clear is precisely how that standard has to be applied to your work.

In particular, how your work interacts with the GPL work when people use it is entirely irrelevant to the test. Arguments that make it relevant are based on the idea that if two programs interact sufficiently intimately, the later one must have copied some protectable expression from the earlier one. This seems obviously wrong to me as functional elements are not protectable and it seems all you need to take are functional elements. Of course, that doesn't mean you necessarily didn't take non-functional elements that are protectable.

Sorry, but it's clear as mud.

| improve this answer | |
  • Would there be any GPL-related problem with publishing an open-source plug-in interface which would serve as a bridge between a GPL program and any plug-ins, be they open- or closed-source, which use a particular documented API that is in no way, shape, or form, derived from that of any GPL'ed program, and then designing a plug-in which exposes that alternate API? – supercat Mar 11 at 20:48
  • @supercat, the intention of the GPL is that if an application uses some part that is under the GPL license, then the entire application, including any intimately associated plugins, must be under an opensource license. If your API-translating bridge doesn't put the secondary plugins at "arm's length", then the intent of the GPL is that it applies as well to the secondary plugins. To my knowledge, it is yet to be decided in court if that intent actually holds. – Bart van Ingen Schenau Mar 13 at 11:36
  • @supercat The legal test would be whether the work not under the GPL contains sufficient protectable expression that originates in the work under the GPL. The intent of the GPL would likely be considered irrelevant here because this is a question of whether or not the work is covered by the GPL at all and a license cannot set its own scope, the law sets its scope. The laws the GPL can only bind those who agree to be bound by it and copyright law sets who needs a license to do things. Nobody can change the scope of what copyright law allows or restricts by their intent but legislators. – David Schwartz Mar 13 at 17:38
  • @BartvanIngenSchenau If you're doing something that copyright law says you don't need a license to do, then you don't need to agree to the GPL to do it and thus are not bound by the GPL. If you are doing something that copyright law says you need a license to do, then if you don't comply with the GPL's terms when you do it, you are violating copyright law. Where do you see the GPL's intent coming in here? – David Schwartz Mar 13 at 17:41
  • @DavidSchwartz, the GPL license is drafted by the lawyers of FSF to express the intent within how they interpreted how copyright law works. If their interpretation of copyright law holds up in court, then they will do their best to get the GPL interpreted according to its intent. – Bart van Ingen Schenau Mar 14 at 7:33
0

If they can't distribute, then they won't

As you state, "Application X is licensed under GPL, so an end-user of X who installs the plugin creates a combined work - which can't be redistributed as it includes my non-free plugin.". This means that the user would be unable to legally distribute the combined work under GPL because they can't relicence part of the combined result (i.e. your plugin) under GPL, and they can't distribute the combined work under something other than GPL because of the licencing requirements of the rest of the application.

There's no major problem with that - they can't redistribute the combined result to others, but can use the combined result themselves, and that's probably all they need and want to do.

| improve this answer | |
  • 4
    But can the developers safely sell their proprietary plugin without the risk of being sued by the owners of the GPL app? That's what the question is about. – curiousdannii Mar 10 at 14:43
  • 1
    @curiousdannii Yes. and the plugin developer wouldn't want the end user to be able to redistribute, because $$$. – Roddy Mar 10 at 14:47
0

The plugin does not magically become covered by the GPL. However, the conditions of the GPL state that by distributing the software, you are committing to distribute the work as a whole under the GPL (this is the principal difference to the LGPL). Is your plugin part of the work as a whole or not? If you distribute the combined software and your plugin as one offering, and the offering does not make sense for the customer to acquire without either plugin or the software itself, arguably the software as a whole includes your plugin.

If it is the action of the user which combines software and plugin, there may be the argument that the user is merely acting as your agent in completing the combination since nothing else makes sense. That argument is likely weaker.

There is a strong counterargument if your plugin were usable with other software without containing special-purpose code only catering to the particular GPLed software.

Like with many licensing decisions, the situation is more on the murky side, depends on how individual courts may make a decision, and one usually wants to avoid being dragged into court in the first place.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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