GPL3 licensed plugins can be used with closed source VCV Rack?

It was also my understanding that the VST version will not be open source. Is that not correct, so that the full functionality, including the VST version, will be available in the Community Edition of Rack? If not, then such a module would be correctly licensed within the Community Edition, but not in the proprietary VST version.

Maybe I’m missing something?

Pretty sure only parts will be closed source.

Would kind of defeat the purpose of having an 3rd party ecosystem if the vst didn’t include our work :slight_smile: With the GPL we can grant permission for paid software to use our work, and with submission to the VCV library there is already a tacit assumption that you approve of this use.

Basically if you don’t want it in the VST, then don’t submit your module to the library

1 Like

I think this has more to do with the license, not with being paid or not. Fully FOSS software can still be bought. Ardour is an example for that.

As far as I understand OP, you can only use GPLv3 licensed libraries/modules when the whole software is GPL (or similar) licensed. If there are closed source parts, can these GPLv3 licensed modules still be used/distributed?

I wasn’t referring to us being paid, just the fact that the VST version is not free. I don’t expect any income from my work

That’s what I meant as well. The VST version is paid, but that doesn’t matter. What matters is the license, and if there are closed source parts in there, it isn’t fully FOSS licensed, which leads to the question of OP.

Yes, this is what my question is about. Maybe “Rack for DAWs” will be opensource as well and the source provided to those who will buy it and request the source? Just a speculation since GPLv3 (and not LGPL) is the racommended license for open source plugins:

The last information I heard about this topic was that the VST will be a wrapper for the (future) Rack-library. The Rack-library will be open source and GPLv3+. It will be used by Rack v2 and by the VST which will be closed source.
Technically the Rack-library (which is GPLv3+) will load your plugin. Maybe this helps.
Also, I have no access to non-public information, so this should be considered unconfirmed.

1 Like

Yes, GPLv3 plugins can be released to be loaded in proprietary software. For example, if you make a VST2 plugin intended to be loaded in proprietary DAWs (Cubase, Ableton, FL Studio), you can license and distribute your plugin under the GPL (such as Surge) as long as you sign the VST2 license agreement with Steinberg.

Since Rack plugins are compiled with the Rack SDK and the Rack SDK is open-source (GPLv3), you already have explicit permission to release a GPLv3 plugin, so no need to sign a license like Steinberg requires. In fact, due to the VCV Rack Non-Commercial Plugin License Exception, you have permission to license your plugin under any license of your choice: open-source, freeware, or commercial.

Of course, if VCV combines your plugin into a single software package and released it under a proprietary/commercial license, VCV would be violating your plugin’s GPL license. But if a user combines two packages into a single program for their own use, they have “unlimited permission to run” your plugin (see section 2 of GPLv3 for details). If the GPL didn’t give them this right, it would not be a free software license.

8 Likes

Thank you for taking the time to answer my question :slight_smile:

3 Likes

Just for clarification while surge is gpl3 it is not a vst2. There’s no way I can see to make a gpl3 vst2 since the vst2 source is not distributable. Once we realized this clearly 2 years ago we went to vst3 only,

That’s not relevant to the question here (which is can you load a gpl3 dynamic library in a non gpl3 container where the answer is unclear and there’s no test of it, but the entire music industry is set up assuming you can and I think I that’s a safe assumption as we’ve discussed before)

I’m no expert, but I did run into this with the flac decoder I integrated for my SFZ player. That code said you could link to it all you want, but it you want to compile to code into your app you needed to be GPL. At the time I wasn’t so I changed my license to be GPL.

Two differences in your example:

You don’t own the copyright of Surge source code. If you wrote Surge entirely by yourself, you could license the code under GPLv3 and then release a VST2 build. It’s your code, you can do anything with it. But since you don’t own the Surge copyright, distributing a VST2 binary would be a violation of Surge’s GPL license.

Secondly, a VST2 plugin binary is a derivative work of the VST2 SDK which is proprietary. A Rack plugin binary is a derivative work of the Rack SDK which is licensed under GPLv3 plus the VCV Rack Non-Commercial Plugin License Exception.

Oh yeah I know! And we agree on this completely and I think your model is smart and right. Just we get folks asking for a surge vst2 all the time so wanted to point out that we can’t

Right if you compile in GPL code you become GPL.

In the music industry everyone has decided that if you dynamically load tightly coupled GPL code as an extension you are not GPL. For instance steinberg releases the vst3 SDK as GPL3 so I can make a GPL3 synth. I don’t think anyone loading that synth into Cubase seriously thinks it makes cubase GPL3, which was basically the question here.

But the fsf says this Frequently Asked Questions about the GNU Licenses - GNU Project - Free Software Foundation which is basically the opposite of what we are all doing even though I think most folks think that’s probably wrong and Andrew’s point on the conflict between freedom to use your software and combined work constraints is I think correct.

It’s been a battle of perception and ideology for decades. The question of whether dynamic linking taints binaries with a license or not has never been before the courts and before that it’s not completely settled. But in my reckoning the overwhelming majority of people, apart from the FSF, believe that dynamic linking does not infect the license, whereas static linking does. It’s important to be aware that the work of FSF is ideologically based.

Yes it is not proven in courts and it’s not even clear how it would be. (I load a gpl3 synth you write in Logic Pro. Who even has a claim against whom?).

Remember I am agreeing here that the fsf is wrong in this regard!

And of course understanding the fsf point of view matters a lot. Totally agree.

1 Like

(This isn’t necessarily a response to @LarsBjerregaard and @baconpaul’s conversation, just throwing this into the echo chamber.)

When confused about software licensing, ask yourself questions of the form “Does person/company X violate software X’s license by doing Z?” It’s funny to me how many people say “Loading a GPL plugin in nonfree software violates the GPL!” They forget an important detail: Who violates it? Is it the user? No, the user has “unlimited permission to run the unmodified Program” (GPLv3 section 2). Is it the DAW company? No, the DAW isn’t a derivative work of the plugin, so the plugin’s license can’t possibly cover it under any country’s copyright law. Is a GPL plugin developer violating his own plugin’s license by compiling a proprietary library (e.g. VST2) into their plugin? No, that’s ridiculous, what is he going to do, sue himself?

Now, the point of the GPL is to prevent someone from taking your code and then distributing it under a different (e.g. nonfree) license. That’s why someone can’t fork Claes Johanson’s Surge code and distribute a VST2 version of it, since they would either be violating the VST2 SDK copyright or Surge’s GPL license. That’s why those two licenses are said to be “incompatible”, but I don’t like that terminology because some people thinks it means a user can’t use software with these licenses together.

3 Likes

That is absolutely true. In fact building a surge vst2 is trivial! Our readme tells you exactly how to do it and it is one env var. Just like building our new standalone with asio support. If you have a vst2 or asio license set a flag, compile, and go! (Asio is similarly not a gpl3 compatible license).

That’s not a redistributable binary though unless you get consent from all the surge copyright holders to dual license (30 or so individuals at this point I think). If someone redistributed the vst2 binary they would violate either my rights as one of the gpl3 license holder on the code or Streinberg by distributing the vst2 code to meet the gpl3 requirement. With a single license holder that conversation is easier of course as you know - since you do exactly that!

That’s what I was getting at above too. You load a properly licensed gpl3 plug-in you did not author into logic. There’s no clean party with standing to try a test case there.

But you build and distribute surge vst2 in your website and it includes a change I made? I (and any other user) can ask you for all the code. And you can’t comply.

I agree.

I think that’s understandable, when we’re talking about a work that is distributed, which we mostly are, since this is the view that, in my understanding, the FSF very much promotes.

Again, to my understanding, this is very much the view that GNU and the FSF promotes, and why people regard GPL as an “infectuous license”. The idea is that “the combined work”, plugin+DAW, using dynamic linking, becomes subject to the GPL, alternatively that you can’t use the GPL for it. The GPL is used to spread “Freedom”.

The point of the GPL from it’s creators, is explicitely to convert the world to Free Software. This is the main reason that big companies (Google, Apple, …) go to great lengths to not have GPL software in their products or codebases, as far as possible, because they have a different business model, which is very much not about converting the world to free software, and they want no risk what so ever, of the GPL (and lawyers) infecting their software products.

From the point of view of GNU and FSF, they are incompatible when the combined works (also talking dynamic linking) gives the user fewer freedoms and rights than the GPL, which in their view many other licenses do, since they provide the user with less rights and freedoms.

Just to make clear, I’m not a big fan of the views and interpretations of the FSF, but there’s a big Free Software and even Stallmann cult that promotes those, as well as other interpretations of how things work, and that is why confusion (difference of opinion) spreads. Actually I hate “software lawyering” so I think I’ll just shut up about it now :slight_smile:

2 Likes

This is a major issue with the text the FSF has used to document/describe the GPL. Their conception of “plugins” (aka dynamically linked shared libraries) is overwhelming dominated by the idea of an API that is closely coupled with a single application. For example, imagine a way to write plugins as a 3rd party that could only be loaded by a single DAW. In this case, the FSF’s description of the plugin as a derivative work of the host is accurate.

But audio plugins (VST/LV2/AU/etc.etc) don’t work this way at all. The APIs are not tied to specific hosts, and neither are the plugins. Any given plugin can be loaded into (essentially) any host, implying that neither can possibly be a derivative of the other.

Some years ago I tried to get FSF Europe to work on this problem in their documents that “surround” the GPL, but to no avail.

1 Like