JUCE GPL and VST SDK License Mystery

#1

Hello all,

I'm sorry if this has been beaten to death, but I can't find a definitive answer anywhere. So is it true that the GPL license and the VST SDK's license aren't compatible? I've been searching around the web and there's all kinds of mixed opinions on this matter. So many people say that you can't, but then some people (like Jules in a thread 10 years ago) say you can. Its quite confusing! I just had someone tell me you cant, so I'd really like to figure this out. 

I think the commercial JUCE license is totally worth the cost, but I would like to create free open source plugins at first. It would be a real shame if I wasn't able to (legally) do that. 

So what is the general consensus on this? Jules? Thanks in advance for any replies on this topic. It really has me curious.

#2

I am interested about this too. 

While it can be argued the Juce license isn't too expensive, it is a bit too steep to pay when developing products which do not have any guarantees of ever generating any (significant) revenue...And it looks like the acquisition of Juce by Roli hasn't so far resulted in any new commercial licensing options. Under these circumstances even releasing VST plugins GPL licensed seems a viable alternative to consider, if it is possible given the Steinberg licensing hurdles. (I suppose this same issue exists with AudioUnits plugins too...)

#3

AS far as I’m aware just don’t include the VST sdk in your project and you are good to go.

There are many open source plugins about so this really isn’t an issue. People are just required to register and download the VST sdk themselves, you cannot include it in your project.

#4

Yes - this is a good summary!

Obviously everyone is free to write and publish source code that is dependent on whatever libraries you want it to be.

The GPL and Steinberg's licenses are just concerned with permission to redistribute these libraries. As long as you don't break Steinberg's license by directly giving a copy of their SDK to other people, then you aren't breaking any rules.

#5

Awesome! Thanks y'all. That's how I figured it was, but SO many people argue against that. I tried reading both licenses, but I really couldn't figure it out from that. I'm just going to go with what y'all said. :)

#6

LV2 can be an option if you are really worried about licensing. (it's MIT/ISC licensed)

Hopefully it will be part of juce soon :)

 

#7

But what about the GPL source code requiring the Steinberg code in order to be compiled? The software doesn't seem so "free" in that case. Besides, Steinberg could at any point cease to distribute anything related to the VST SDK. (Theoretical of course, but still a possibility.) The software that was supposed to be free to be modified and fixed would no longer be so, because it couldn't be compiled. I strongly believe this could be considered a GPL violation by the Free Software Foundation.

#8

I thought it was explained pretty well above, but I'll try explaining again in a different way...

If you write an open-source app then you're simply saying:

"Here is my own code: you may use it under [some license of your choice]. To compile it, you will also need to get a copy of JUCE (under the GPL) and VSTSDK (under their own license)."

You are not distributing either JUCE or VSTSDK. So you are not breaking any rules. You're only distributing your own source code, and you may obviously do anything you like with code that you wrote.

The end-user who actually compiles your app is responsible for complying with any licenses involved. That means your own license (whatever you choose), the JUCE GPL (which is easy as long as they don't release the app as a binary), and the VSTSDK (which just involves going to Steinberg's site and agreeing to the license).

#9

"End user who compiles"...Hmm...Even though that generally isn't too difficult for me, I still prefer never to do that unless absolutely necessary, as an end user. And so do 99.9999% of other Windows and OS-X users.

So let's forget about source code for now and consider that binaries are publicly available to download. Does that change the situation in any way?

 

edit : Surely you are not suggesting things to work so that the original developer of the plugin wouldn't build and distribute the binaries but rather some 3rd party would take care of that, also assuming any legal responsibility in case Steinberg or the Free Software Foundation would come after them? That would be a complete nightmare and not practical at all for a niche thing like VST plugins!

#10

Ok, then you are probably technically breaking the GPL by distributing the binary.

But as I've said many times on the forum and elsewhere, we actively want people to be developing open-source plugins with JUCE so obviously would never treat people who add the VSTSDK to their project as being in breach. (I should probably mention that our upcoming new licensing model will provide an official route around this issue)

#11

OK, thanks for clarifying that up!

I wasn't worrying so much about you, Raw Material Software or Roli causing problems along the line but rather Steinberg or the Free Software Foundation doing that. Steinberg obviously has the concerns of a proprietary commercial entity and the Free Software Foundation has an unpleasant scent of fanaticism about them...I can't see much good coming out of that.

Very interesting news about the upcoming license changes, I will be waiting with interest!

#12

FWIW you wouldn't be breaking Steinberg's license by using it in a GPL project - they allow you to use it freely as long as you agree to their terms + conditions.

#13

I think this is not correct. The GPL is contaminent, so the SDK would HAVE to be released under the same conditions.

The only way for the VST SDK (and perhaps also AU SDK) is to have a specific GPL license for Jules that explicitely says that the VST SDK may not be covered by the GPL license if both or integrated in the same piece of software.

I agree that you may not be concerned by the violation, but any user of the binary can sue/ask for the whole source code to be provided (note that in the GPL there are explicit exception for system libraries) under the GPL so that it can be recompiled. As such, it includes the VST SDK.

The issue bit several scientific library users, and all their lawyers were explicitely saying exactly what I'm saying (you can check for instance the Eigen license thread on their mailing list).

#14

The problem with GPL is not only with VST SDK but as well with the derivative works. Because view of FSF is that linkage does not matter wheter the work is derived or not - it is derived. https://www.gnu.org/licenses/gpl-faq.html#GPLStaticVsDynamic At this point of view GPL plug-ins can not be loaded into proprietary host. But there are other views as well. According to wikipedia there is a different application about plugins with GPL2.0 and GPL 3.0. Which part of JUCE are released under which license? (GPL2.0, GPL3, AGPL?). Currently I am writing a series of blog post about it - GPL and audio plugins - although IANAL.

#15
"At this point of view GPL plug-ins can not be loaded into proprietary host. But there are other views as well."

https://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF

"However, you can resolve that legal problem by adding an exception to your plug-in’s license, giving permission to link it with the non-free main program.

Although IANAL also (as 99 % of people that write about that subject).

#16

True. I ment it generally - not just with connection with JUCE.  You have to have exception from Jules/ROLI, your code AND any particular 3rd party library released under GPL you used. 

#17

100% agree (far clear than my own comment ;) ). You have to have the ability to make the plugin API GPL, or have an explicit exception for it.

#18

So I made an investigation and summed what I have found it to few blog posts. If you are interested you are welcome to read them:


1) GNU GPL generally - http://virtualanalogy.com/gnu-gpl-and-a ... i-gnu-gpl/
2) Open Source licenses compatibility - http://virtualanalogy.com/gnu-gpl-and-a ... ibility-i/
3) AU and VST SDK and GPL - http://virtualanalogy.com/gnu-gpl-and-a ... bility-ii/
4) Derivative works and linkage - http://virtualanalogy.com/gnu-gpl-and-a ... v-linkage/

I think the last two are the most interesting. I plan to write one or two in near future.

#19

Hi there,

can someone explain the current situation on that? Steinberg changed the license for VST3 SDK shortly into a dual license wich include the GPL3 by excluding the VST2 SDK on this. https://sdk.steinberg.net/viewtopic.php?f=4&t=286

My questions are:

  1. I can clone juce from github and build vst2 plugins out of the box without inserting the VST2 SDK headers from Steinberg. Why can I do this?

  2. Is there a posibility for building LinuxVST (VST3?) plugins under the GPL now?

I hope someone can clarify a little bit on this issue.

#20
  1. All the VST2 host-plugin communication is handled by JUCE code - we don’t use the VST2 headers.
  2. We’re working on this, but it will take a while.