GPL audio plugins incompatible with closed-source hosts?

The GPL license v3 explicitly states that linking GPL-licensed code (e.g. a plugin) within the same address space of another program (e.g. a host) would constitute a combination of the two, effectively requiring the host to be licensed under GPL too.

If I understand correctly, this prohibits a closed-source host to be bundled with GPL plugins, at least in the same download. Is that correct?

Wouldn’t this also forbid any commercial host to run GPL audio plugins? I mean, they become a combined program at the time the plugin is loaded.

I thought this kind of bundling was an “aggregate” as per GPL terms, because the host does not require the plugins to work and the bundling is merely a convenience thing for the user.

What would be the best way of bundling a GPL plugin with a commercial hosts? Is there any?

AFAIK, it depends on the link type. This applies to static link (not static libraries, but shared libraries that were linked to the app), not dynamic lin (where the plugin is loaded dynamically and the entries inside are discovered on the fly).
The list of the entries is the issue. In the case of the VST3 SDK, it is now dually licensed (AU have an exception, as they are part of the system, VST2 have their custom API in JUCE, so their dual license apply here), so a plugin entirely in GPL (not possible before, even with a GPL JUCE) can interact with a host that was built with th non-GPL VST3 SDK.

Thank you for your quick reply. Actually the question is:

Can GPL audio plugins be distributed together with a commercial host? Either as separate installers, or as optional components of the main installer?

This is really interesting. In all my time working with JUCE I’ve never considered this but I think you’re correct (IANAL). When you ship a GPL plugin with a non-GPL DAW, you’re dynamically linking bundled GPL’d code to non-GPL code without sharing the full source code (not allowed). Theoretically if JUCE was LGPL this was mitigated. The whole “the program can function perfectly fine without the bundled GPL code” aspect is interesting too.

A workaround (consult a lawyer, ROLI, or something!) could be to package and distribute all your plugins separately from your closed source product so the whole process behaves like the generally accepted methods of GPL plugin distribution.

Please share whatever solution you figure out is the correct one!

1 Like

Having JUCE LGPL would not change a thing, as it would become GPL due to the GPL license of the other code.
The trick is the dual license of the API/ABI. As the plugin uses one version and the host the other, you don’t have an issue. Of course, you can distribute both of them together, but you need to carefully warn the user about the difference in license in the components you are installing.
RHEL distributes code that is GPL, BSD and a bunch of other licenses together, it works.

Just for the record: we obviously don’t mind if people use our code under the GPL and run it in a DAW, so I don’t think it’s worth anyone losing any sleep over this… :slight_smile:

I’m rather losing sleep over the idea that I can’t distribute together with my host application a GPL plugin that I contributed to.

The separate download link may be a workaround, but that would not make for a great user experience.

1 Like

There is no issue if you distribute a GPL VST3 plugin (or AU plugin or VST2 plugin compiled with JUCE) with a closed-source app. Lots of people do so, all Linux distributions do BTW (think nVidia/AMD drivers and the Linux kernel).
As long as the API is dual licensed in some way or compatible with the GPL (so no AAX), you are good.

Do you know a specific example of a proprietary host that ships with GPL plugins?

We don’t need examples of DAWs, I gave an example of a Linux distribution and it has exactly the same problem.
As long as the API has a license that allows for GPL and non GPL usage, you are good.

Actually with Linux, it’s exactly the other way round: A GPL “host” (Linux) with proprietary “plugins” (drivers). Also, the Linux license includes a clause that clarifies this case explicitly.

This is not the case with GPL, which says: Link dynamically with a GPL library and you’ll get a “combined work”. TBH, I don’t yet understand the significance of the API being used and if it really makes a difference.

I think you were right about the “aggregate”. But it seems to be a gray area of the GPL.

Seems like at a minimum you would need the installed GPL plugin accessible from other DAWs.

Also, a word of caution. As a developer of a GPL plugin, this would definitely get my attention. I’m not sure if I would do anything but I know a lot of other GPL developers would be upset if they saw a proprietary developer benefiting off of their work.

Absolutely agree. It goes without saying that all developers are actively involved. I’d not make a move without an agreement. I’m all for mutual benefit.

So I wrote this up the other day with the intent of posting it somewhere near the FSF to encourage a discussion. I couldn’t find a forum that was freely accessible (ironically), so instead of deleting it, I thought I would share it with you. This is LONG, but I hope it is worth reading.

The current GPL text is unclear whether the communication between plugins (audio, video, photo, web) and host programs (music production, video/photo editing, browsers) is sufficiently “at arms length” for the two to be considered separate “programs”.

This raises a question that potentially affects a very large number of plugin and host developers: Does the “aggregate” term apply to plugin/host combinations, or does the technical process of dynamic linking dictate a “combined work” relationship?

In the audio production world, for example, it is common practice that audio plugins and hosts are dealt with as independent entities, because there are thousands of plugins and possibly hundreds of hosts that are freely interoperable and replaceable with each other, thanks to a standardized third-party API (VST, AU, etc). No plugin is tailored to a specific host, and vice versa.

It is worth noting that, at the user’s choice, multiple host programs typically have access to and interoperate with all plugins installed on the same computer. A host can run fine without any plugin, but plugins can’t accomplish anything without a host (unless there’s a standalone version).

An example: Does loading a Photoshop plugin really turn Photoshop into a “combined work” derived off of the plugin? Does this curtail the rights of users to freely use, modify, share, etc. the code of the plugin? Isn’t it actually the other way round: The plugin only makes sense because there’s a Photoshop API in the first place? Wouldn’t this actually make the plugin a derived work off of Photoshop?

It should be noted though, that the Photoshop API is different from the audio world, in that there is only a single “host” available for it (to my knowledge), while for audio hosts there is plenty choice.

At the core of this question are standardized plug-in APIs (VST, AU, AAX as examples for audio plugins) that effectively work more similar to a network protocol, rather than a specific linkage between two parts. It’s the third-party API that enables the free interoperation and arbitrary replacement, not unlike the PCIe standard for expansion cards.

The standardized API ensures the freedom of users to combine plugins and hosts of their choice, while no host is dependent on any specific plugin, or the other way round. IMO, this makes plugins and hosts communicate sufficiently “at arms length” in order to be covered by the “aggregate” condition.

In fact this is even more “at arms length” than, for example, the external execution of ffmpeg by a video converter app through the command line: The video converter depends on ffmpeg. It can’t accomplish much without it.


In regard to the definition of “at arms length” and “aggregate”, the GPL license should address and clarify the role of standardized APIs and where the line is between free “plug and play” interoperability and program-specific linking.

It seems highly unlikely that a developer intended a plugin to be used exclusively with GPL hosts only. This would be contrary to the purpose of a plugin, especially in the audio world, where the most widely used hosts are non-GPL.

Going LGPL with plugins would probably not be necessary, if this point was stated clearly enough in the GPL terms.

GPLv4 anyone?