The future of VST2 support in JUCE

Roli and Steinberg have obviously done some kind of an agreement about Roli being allowed to temporarily distribute the VST2 headers.

I don’t think there is such an agreement. Or I’d like to know how they managed that when Steinberg is clearly heavily bent towards killing VST2 (as if it works that way): https://github.com/zeromus/openvi/issues/1

This is the Steinberg license (emphasis is mine):

LICENSE
(c) 2015, Steinberg Media Technologies GmbH, All Rights Reserved

This Software Development Kit may not be distributed in parts or its entirety
without prior written agreement by Steinberg Media Technologies GmbH.
This SDK must not be used to re-engineer or manipulate any technology used
in any Steinberg or Third-party application or software module,
unless permitted by law.
Neither the name of the Steinberg Media Technologies nor the names of its
contributors may be used to endorse or promote products derived from this
software without specific prior written permission.

If ROLI and Steinberg have a written agreement, ROLI can do whatever they want.

Oh yes, I agree, but I don’t think there is one. There is no reason why Steinberg would do this given their current behavior.

The VST2 headers are under the following license:

// LICENSE
// (c) 2018, Steinberg Media Technologies GmbH, All Rights Reserved
//-----------------------------------------------------------------------------
// This Software Development Kit may not be distributed in parts or its entirety  
// without prior written agreement by Steinberg Media Technologies GmbH. 
// This SDK must not be used to re-engineer or manipulate any technology used  
// in any Steinberg or Third-party application or software module, 
// unless permitted by law.
// Neither the name of the Steinberg Media Technologies nor the names of its
// contributors may be used to endorse or promote products derived from this 
// software without specific prior written permission.

Thus, they cannot be redistributed under GPLv3. This means that JUCE’s develop branch is no longer GPLv3.

There is no way ROLI would be so stupid as to do something like this without a prior written agreement. Anyone who has seriously developed audio software is aware of the license stipulations of Steinberg SDKs.

Don’t forget that JUCE has been around for a long time now and has had a massive impact on the audio software industry. I guarantee engineers at ROLI know engineers at Steinberg and they both agreed it made sense before they made this move. Then they had their lawyers go into a room and do whatever it is lawyers do and here we are.

That said, if someone from ROLI could confirm this, then we could all stop debating :wink:

2 Likes

Yes, we’ve discussed this in depth with Steinberg and they’re happy for us to distribute these files as part of the JUCE repo.

But just for clarity: we’re only delivering these files to you - obviously we don’t own the copyright of their content and we’re not in any way claiming to offer any kind of special licensing arrangement for them just because they’re in our repo. Anyone who has worries about how the VST SDK license interacts with their own legal situation would need to discuss that with Steinberg directly.

4 Likes

ROLI cannot claim that JUCE is GPLv3 on one hand, and then ask us to discuss legal matters with Steinberg on the other hand. That doesn’t make any sense.

When someone makes a fork of JUCE on GitHub, they cannot selectively exclude the VST2 headers. This means that anybody who presses the “Fork” button on GitHub - juce-framework/JUCE: JUCE is an open-source cross-platform C++ application framework for desktop and mobile applications, including VST, VST3, AU, AUv3, LV2 and AAX audio plug-ins. is infringing Steinberg’s license. Or do you expect them to contact Steinberg before pressing the “Fork” button?

1 Like

Sorry, but I can’t really see any other option - it’d be highly inappropriate for us to comment on what Steinberg’s license permits you to do with their code!

Nobody ever claimed that ALL the files in the JUCE repo are GPLv3. Yes, our bits are GPL, but the repo has always contained other 3rd party libraries which are not our copyright, and which use other licenses (generally more permissive).

The JUCE repo is a handy way to download a collection of code that you need to build JUCE apps. But doing due diligence on all the content that you’re using is your responsibility, and we can only realistically help you with questions relating to the bits of it that we actually own!

It seems like someone has been scanning Github for VST headers lately and issuing DMCA requests. Does this mean that any Juce based project could potentially be flagged? Having to manually remove the files would be a huge pain.

In my personal projects I usually don’t include any juce code. Either I expect the users to have it already installed (and tell in the README, where to get it), or I add it as submodule and tell in the README to clone using git clone --recurse-submodules so the user will get the code from the JUCE repository. And for getting the code from JUCE, like was said before, there is a regulation in place.
Copying code into your repository is not state of the art anyway and leaves you with the task always to update the copies you made.

The only moment, where questions could appear are forks from the JUCE repository.

This was the default behavior in the Projucer for a long time no?

ROLI stance on GPL was always… grey. VST2 SDK was always incompatible with GPL, and still ROLI encouraged people to distribute binaries build with JUCE GPL and VST2.

When a developer includes some GPL code the entire body of work must be licensed under the GPL if they wish to release it under the GPL (so there must not be code using incompatible licenses included in their derived work). If we have a position where including the VST2 (or other) headers by default means developers have included code that is not compatible with the GPL it might be useful to tweak this bit of the readme which suggests that developers should/can release their derived body of work under the GPL if they don’t want to use a commercial Juce license because it looks to me as though that option is not actually available to them.

Once your business hits the Revenue Limit for your JUCE license, you will either have to upgrade your JUCE license or release your Applications under the GNU General Public License v.3, which means, among other things, that your code can be freely copied and distributed.

1 Like

The option is available for a long time, yes. If it was default on for a long time, I cannot say. It definitely isn’t in the time I used JUCE, which is now roughly 3 years.