I know this question seems to be the nth of this sort, but I could not find a clear answer to my question.

I am working on a keyboard launcher app. Its license is a custom proprietary license. The code is source available. The plugins have their own licenses. Almost all of them MIT.

I have a particular math parser plugin that has a GPL(-2) dependency. Now I am unsure about the implications of the GPL.


What exactly does the GPL impose on plugin that directly links to the GPL library and uses its public interface? Does it have to be source available, of the same license, of a compatible license, of a copyleft license? How is distribution affected?

Core app

The core app does not interface the GPL library at all. The math parser plugin inherits the core library QueryHandler interface class to qualify as query handler. The core app searches such plugins on disk. Initially none of them are loaded. On behalf of the user configuration these plugins are loaded. On user queries QueryHandler::handleQuery(str) is called which returns items which will be displayed to the user. Note that the core app is totally functional without any such plugin loaded. Is there any implication for the core app and its distribution?

For user (and packager) convenience the app is intended to be shipped including all upstream plugins. Does the use of a GPL library affect the way the bundle has to be packaged?



2 Answers 2


The Free Software Foundation believes that a plugin may or may not form a single program when combined with the base application, depending on how it works. The plugins you describe are pretty close to the line that the FSF draws (I would encourage you to read their explanation in full).

If the plugin is not a derivative work of the proprietary application, then it probably needs to be GPL'd (because it uses a GPL'd library), but the application does not, and everything is more or less fine. If the plugin is a derivative work of the proprietary application, then... things are a bit of a mess.

In the case where the proprietary app and the plugin form a single combined work, you can't distribute them together, because the proprietary license would be an "additional restriction" in the parlance of the GPL. If the application and the plugin are created by different people, it is somewhat plausible that you might not want to do that in the first place, and so this prohibition might not affect you. However, the GPL anticipates this loophole by making distribution of the plugin a GPL violation all by itself.

The tricky part, therefore, is figuring out whether your plugins are derivative works of your application. You describe this as a "keyboard launcher app," and from the way you talk about the plugins, it sounds as if the application just passes a string from the user along to the plugin, and then the plugin does all further processing itself. This is not the exchange of intimate data structures that the FSF contemplated when they suggested that plugins sharing an address space automatically makes a derivative work exist. Quite the opposite - what you describe looks a lot more like the userspace equivalent of fork/exec (with the necessary differences in semantics). That puts this right on the FSF's boundary line.

Now we run into a hard problem. Up until now, we've been talking about the FSF's opinion. But the FSF's opinion is just that, an opinion. The FSF does not control how the law works. They are in a reasonably good position to have an informed understanding of how the law is likely to work, but that's not the same thing as actually knowing how a lawsuit would necessarily play out in any given legal system. The issue of whether dynamic linking always (or even usually) creates a derivative work is very much unsettled in most (if not all) jurisdictions.

But we're not flying completely blind. In the US, it is likely that any lawsuit would involve application of the abstraction-filtration-comparison test to the plugin and application. This analysis is rather complicated, and highly fact-specific, but courts have at least written down how you're supposed to do it, which is better than nothing. So a competent copyright attorney could probably, with enough time and effort, give you a provisional answer, a sort of "best guess" at what would happen for that particular set of facts. I doubt you want to spend the money on an attorney, but if you're trying to turn this into a serious business (and not e.g. a hobby or the like), it is more or less inevitable that you will be hiring lawyers for all sorts of reasons anyway. You'll just have to decide whether this is a valid reason to hire another attorney, or if you'd prefer to stay out of the business of GPL'd plugins altogether.

  • Hmm, but whether the plugin is a derivative of the application has only some impact if the license of the application restricts that, and there is no GPL in there. Commented May 22 at 22:47
  • If the plug-in could be used with either a GPL application or a non-GPL application, I fail to see how the existence of the non-GPL application that is compatible with the plug-in could cause the plug-in to violate the GPL.
    – supercat
    Commented May 22 at 23:03
  • 2
    Further, even if using the plug-in would cause the running application to become a derivative of the GPL work, the GPL expressly allows for the creation of derivative works that are not distributed.
    – supercat
    Commented May 22 at 23:08
  • @supercat: The question specifies that the plugin uses an interface provided by the proprietary library. Using it with a GPL application seems rather questionable to me. Regardless, the answer already addresses both the "what if I just distribute the plugin?" question and the "what if the plugin is not a derivative work?" question.
    – Kevin
    Commented May 22 at 23:38
  • @Kevin: If the plug-in is distributed in such a way that someone wouldn't need to buy any proprietary software to build something that's just as useful as the distributed plug-in (perhaps because they have a friend who has the software, but isn't a programmer, and would like to have them build a tweaked version of the plug-in) the fact that someone with proprietary software would find the plug-in more useful than someone without shouldn't be relevant from a GPL perspective, especially if all of the information needed to use the plug-in without proprietary software is included with it.
    – supercat
    Commented May 23 at 16:24

The primary restriction imposed by the GPL is that derivative works may only be distributed if they satisfy certain requirements. The GPL gives essentially unlimited permission to produce derivative works that are not distributed, and to include legitimately-distributable packages containing GPL works within "aggregations" without having to treat the latter as derivative works of the GPL works therein.

If the author of the plug-in can partition the materials necessary to build and run the plug-in into two categories--material which is unambiguously GPL-compatible, and material which is unambiguously free of any GPL content not produced by the plug-in author, the GPL would expressly allow distribution of the first set and would have no authority to restrict the second. Consequently, the GPL would waive any authority to restrict distribution of an aggregation containing both two parts.

Note that if any code in the second part of the aggregation made reference to the aggregation as a whole, that might be perceived as making the aggregation a derivative work of the GPL works therein. Such issues could be dealt with by bundling the aforementioned aggregation in a larger aggregation with an open-source set of scripts that could be used by the person who would be using the code to unpack the aggregation and process the contents thereof to produce a derived work that could be executed, but not distributed.

As a parting node, bearing in mind that interface descriptions or "simple" mechanical transcriptions thereof are not copyrightable, an application designer should strive to make it easy for plug-in authors to partition things as described, and to ensure that recipients of the plug-in wouldn't need any proprietary software to to produce loadable artifacts that are just as useful as any that are included with the distribution; whether or not any open-source program presently exists that would usefully employ the plug-in, enough information should be available to allow a sufficiently motivated person of reasonable skill who wanted to make a program that uses the plug-ins to do so, without need of the proprietary program or license.

  • As an alternative to that last point, could the application designer explicitly release just the interface under an open-source licence (GPL, or perhaps more permissively LGPL or even MIT) to avoid any doubt over the copyright status? Or even release a simple(/test) consumer of that interface which would form a fully self-contained open-source system with the plugin, that just happens to also work with the proprietary application?
    – Bob
    Commented May 24 at 4:08
  • 1
    @Bob: Indeed, it would probably not be a bad idea for the application designer to do that. My main point was that if a GPL's library requires that client code pass e.g. a function that takes a certain set of arguments, the fact that the main application passes a callback function that takes such arguments would not make the main application a derivative work of the GPL library, since a work cannot be a derivative work of another work without embodying some (possibly transformed) identifiable copyrightable aspect of the original.
    – supercat
    Commented May 24 at 15:18
  • @Bob:: BTW, an aspect of "derivative works" which is well established with music and motion pictures is that a combination of a silent motion picture and an instruction suggesting that it be watched while listening to some particular copyrighted musical piece would not be a derivative work if it didn't embody any of the music, but a combined audiovisual file produced using such instructions would be a derived work of the musical piece.
    – supercat
    Commented May 24 at 15:22

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.