JUCE

JUCE copied to clipboard

According to Steinberg VST usage guidelines:

Whenever VST® is used or the SDK has been used to create a product or the SDK is included (Open-source GPLv3 case), it is required to add the reference to Steinberg by using the VST compatible logo as supplied by Steinberg. Included in the VST SDK, the VST compatible logo can be found in the folder VST_SDK/VST3_SDK/vst3_doc/artwork.

And GNU GPLv3 states:

All other non-permissive additional terms are considered “further restrictions” within the meaning of section 10. If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term.

So, we have Steinberg that wants to force a couple of terms on top of GPLv3, but GPLv3 says we ought to ignore such terms. Does Steinberg consider us to be breaking the license if we ignore the extra terms?

This question has been brought by to Steinberg a few months ago, but no single reply has been given: https://forums.steinberg.net/t/cannot-use-the-gpl3-option/750876

Due to this unclear license situation Fedora has removed all packages that use the VST3 SDK from their repos. See https://lists.fedoraproject.org/archives/list/[email protected]/thread/EOI3CKZPJEQIWEN2HPVNRYK5DI5QJG6Z/

I have seen this being a problem for other linux distributions as well, where they prefer to stay away from unclear licensing.

What is the expected behaviour?

There should a clear license situation when creating GPLv3 licensed VST3 plugins.

Code of Conduct

• [X] I agree to follow the Code of Conduct

Now I know this is not directly a problem caused by JUCE, but as many developers are producing VST3 GPLv3 plugins using JUCE, it is still relevant. I occasionally help with packaging, and this has been a problem growing up recently, as more and more developers move to JUCE in order to make audio plugins.

My hope is that creating this ticket brings some needed attention to the issue, and we can then eventually get a resolution on it. Thanks.

https://fsfe.org/activities/gplv3/bangalore-rms-transcript.en.html

[49:40]

The change is, at the same time, we also let you put certain kinds of additional requirements explicitly on your code. Some of these additional requirements are essentially trivial, and our view is that you could always add them. Like, a licence which says: "you can't remove my copyright notice from my code". That's trivial. We consider such licences to be compatible with the GPL already.

But, in addition to those, we've also permitted a few kinds of substantive requirements. Some of which are not trivial, and which therefore increase the range of existing licences which are compatible with the GPL. This includes, for instance, copyright-based requirements not to misuse certain trademarks. Now, there are some licence which simply state: "such and such is our trade mark". That has nothing to do with the licence for the copyright on the code. So there's no incompatibility there. Trademark law is a different law, and if they have a certain trademark, they're saying: "here's what we do with our trademark".

There are some licences which say: "as a condition for doing things under the copyright on the code, you have to obey our trademark requirements". That's different, that does conflict with the GNU GPL in version two, but in version three we have explicitly given permission to add this kind of requirement.