To my knowledge, only Steinberg hosts support the legacy CC stuff that was added to VST3 just over a year ago.
All major DAWs seem to support this for VST2 plugins though.
Thank you all for your valuable input! Let me clarify my position:
What I want:
- Developing open source audio plugins (under GPL) in my spare time.
- Be able to share binaries (including source code or not) with people using Ableton Live 8 or 9.
What I don’t want:
- Having to pay a lawyer
- Being chased down at the end of the earth by Steinberg’s team of angry lawyers
What I don’t understand:
- How using FST headers is going to make the distribution of VST2 binaries legal? How can someone even tell whether a binary has been compiled with Steinberg or FST headers?
In my understanding, the VST2 headers were never available under GPL, and therefore could not be used in open source projects (or at least developers would have to supply the Steinberg headers themselves to build the project).
Because of this limitation, some crafty people started a reverse engineering the interfaces of various VST2 plugins and hosts, and used the info they could deduct from these imnplementations to put together headers that are compatibe with Steinberg’s. I believe the best and most up to date project is FST.
If you are wondering how such a thing is possible, take a look at Clean room design - Wikipedia
Now, I don’t think that Steinberg recognizes the legality of FST (and other FOSS projects using VST2) but it may not be up to them. The fact is that you cannot copyright the “abstract” definition of an interface or protocol, only a particular implementation of it. So if someone is able to put together working VST headers without using the VST2 SDK, I for one believe that implementation would be their property, and they would be free to publish it under the GPL.
There are quite a few open source projects using reverse engineered VST2 headers (including Ardour, I believe), so a small plugin developer would probably not be first in line if Steinberg decided to take action. I also think the Free Software Foundation might have an opinion about the legality of making reverse engineered headers available under the GPL.
So, if I were you I would just use FST headers and publish source code and binaries under the GPL.
Am I absolutely 100% positive that it is legal? No, but I wouldn’t lose any sleep over it 
3 Likes
I’m currently in a similar situation where I’d like to release a GPL project ready for compiling which therefore should include headers for the VST2 interface. I’m in the middle of the process but my approach is to use the VST header that was in the JUCE until this commit. I’m using the juce_VSTInterface.h file from the 5.3.2 release which I included in a current JUCE’s VST wrapper. A problem is that most names (enums, structs etc.) are different than the Steinberg VST header’s names which of course are used in the wrapper so at the moment I’m fixing lots of errors by finding out which names mean what. I will gladly share the file after I’m done with all the errors.
One other alternative to FST you might take is using JUCE 5.3.2. Of course, I’m no lawyer but by using JUCE’s VST implementation (or FST) I’d say that one doesn’t (at least directly) violate the VST license agreement as the VST SDK by Steinberg isn’t used. I have no idea whether Steinberg can claim any rights on the VST interface itself.
Not so sure about that… the JUCE developers had access/license to the VST2 SDK.
I’m pretty sure they can’t. There are no patents involved here and only a particular implementation of an interface can be copyrighted.
So we’re all just guessing? Where are all the lawyers when you need them?
Yes.
Probably busy counting all their money…
2 Likes
One thing I would definitely not do is to publish any Steinberg header files through GitHub or any other place on the internet. That is absolutely a copyright violation. That is why Roli removed them from the current JUCE source. It doesn’t matter if you’re using an older version of JUCE to get around it, if you do it, you are subjecting yourself to copyright infringement.
If you release binaries only, I think it would be hard for Steinberg to come after you. Doesn’t mean they wouldn’t. If they really wanted to fight you and push it, they would try to dig deeper and deeper through discovery to find out if you reverse engineered the interface used in your plugin in order to make it work in VST hosts… This would require them actually seeing your source code, which your own lawyer could block through all manner of means until Steinberg could prove that its essential for the case for everyone in court to see your source code, etc…it would drag on and cost a lot of money in legal fees to go through that…but in the end, if they got access to your source code, then they might be able to prove there was no way you could have possibly derived the interface through reverse engineering and they might even be able to prove that you actually were using their copyrighted headers.
But it would be a long and difficult court battle. For most of us,…it would be a court battle over peanuts that neither us nor Steinberg would want to waste time on. I mean lets face it, as a plugin developer you are actually making something that benefits Steinberg…a plugin that enhances Cubase. Why would they sue you? In fact if they did there would be plenty of room to counter-sue based on anti-trust law.
I think they are more likely to sue if some new host developer comes out that makes a DAW with VST2 hosting and no license…and that DAW competes with Cubase and causes financial losses to Steinberg. They might try to sue then. Of course that DAW developer would counter-sue with anti-trust stuff…so it would be interesting and it would be a legitimate and warranted fight on both sides.
But Steinberg has absolutely no financial interest to go after plugin developers that are still trying to release VST2 plugins that work inside Cubase and enhance Cubase. Its an interesting hypothetical discussion and perhaps you will sleep better at night knowing you are in a position where they can’t even try, but the practical side of it is, they are probably not going to sue any small time developers.
In any case, do not under any circumstances publish the actual header files through any means whatsoever, because they could assert all manner of damages to themselves that way and sue for millions if they really wanted to.
If you are going to publish your plugin as open source I would publish all of the code except for the headers, with instructions about how to use the headers. Leave it up to the user to find the headers and compile it.
2 Likes
Well… almost
@Dewdman42 Man you write long posts
Its what I do. You’re not obliged to read them all the way though
Another long post...
Regarding Legal, please let us know what your attorney says, but I would expect him to say is that if it went to court, its not clear cut, but you’d have to fight it and it would cost money to fight it, and probably you would cave in anyway and settle at some point. There is a lot of shaky ground here, but that doesn’t mean Steinberg doesn’t have decent grounds to sue for the courts to allow the lawsuit to proceed based on the merits… And they might win, or they might not. It would cost you lots of money to fight Steinberg…right or wrong…win or lose…and probably you would settle anyway if that happens. You are just rolling the dice really and hoping Steinberg is not going to hunt down everyone and try to sue them for basically making plugins that improve the Cubase experience.
Just to put things into perspective. Last week I sent email to Steinberg asking them to check their records because I vaguely recall signing the SDk agreement over 10 years ago. They are looking and responded to me once that since it was more than 10 years ago its taking them a little longer to look into it.
But moral of the story is, it’s not like they have a quick and easy database sitting there showing them who all the signed licensee’s are. They would have to suspect you and demand that you produce the signed agreement which may have been signed literally decades ago, and then if you can’t produce it, then they might sue. Are they going to do that to all the thousands of people out there making or distributing VST2 plugins today? I seriously doubt it. There are people that made their VST2’s ages ago, still distributing them, may or may not have a signed agreement and Steinberg has to dig deep into old records to even find out. Will they actually try to hunt down thousands of people that way? I doubt it.
Well then the next question is can you do your plugin with VST3 after all. I’m trying to find a way to just do that and live with the limitations. It may mean I won’t be using JUCE though.
1 Like
another interesting observation. In October 2018 when they announced no more VST2 licenses, I noticed now in looking back, quite a number of people on the forums scrambling to get a signed license in time. Some of them had been distributing their VST2 plugin for years before that already…and apparently had never gotten a signed license. Steinberg never came after them or really pursued anything like that at all in the past even though legally they had a case to, but why would they?
The only thing they have done really is put out a big scare about it, and they have attempted to hunt down all the vst2 headers on the internet and get them shut down based on copyright.
Its actually not in Steinberg’s financial interest to stop people from distributing their VST2 plugins. They just really really really want to get developers to start using VST3 more. Fair enough. I personally am not worried about it. But I agree…its scary to take a chance.
2 Likes
True.
I agree. I would be very surprised if anyone ever went to court over this.
Just thinking out loud here, pondering what I’ve read in this discussion over the last few days.
If I’m understanding correctly, a problem with using FST is that you have to make your source code public under GPL - do I have that right?
What if you wrote a plugin (VST3) that could host (wrap) a single VST2 plugin, using FST headers?
You could conceivably write this within JUCE, using FST headers (assuming they work as well as Steinberg’s) so that this plugin could scan for all VST2 plugins, and select one to load, making it easy for the user.
You could then publish the source code for this wrapper under GPL to comply with FST license.
Could you then use and distribute this plugin with your host, without releasing the rest of your source code?
I have considered that solution but I believe your VST3 wrapper would be considered a derivative work under the GPL if you distribute the two components together
Nope, the GPL is “viral”. In general - if you distribute GPL components with your app, your app must also be GPL.
Audacity gets around this with their MP3 encoder by merely providing a link to where you can download it yourself.
GPL is a cult
This is a two years old thread, but still relevant (unfortunately), so I hope no one will get offended if I post a reply here instead of creating a new thread. I already posted a similar thread, but I think this one is more suited for this.
From what I gather here are 4 possible solutions I can think of:
-
Like @dewdman42 suggests just publish VST2 versions and try not to loose a sleep about it. That is probably not as comfortable an option for host developers though…
-
Sue Steinberg over anti trust laws
-
Regroup with other developers and state the common decision of not supporting Cubase anymore in any of our plugins as long as Steinberg continues with this strategy. That would be pretty simple to do and would increase Steinberg’s bad rep in the general user base (currently limited to developers and a limited number of users aware of the situation). Strike!
-
Find a company with VST2/VST3 licenses that would accept to publish a set of very simple VST2/VST3 and VST3/VST2 wrapper plugins under its name, for free. They would benefit with good rep, and also an afflux of users on their website.
I think the Juce team would be the perfect perpetuator of option 4, as this would also benefit to the Juce framework itself, being able to build products targeting more end users.
2 Likes
My vote at this point would be for juce to get onboard with CLAP.
The CLAP team will hopefully work out some binary runtime wrappers for vst, vst3, au, aax, etc.
In the long run hopefully native CLAP hosting will also become commonplace in most of all daws and then no wrappers will be needed, but time will tell.
Sounds like bitwig and reaper are working on it already. More will come. I believe CLAP will become the defacto standard in a few years. But we’ll see
4 Likes
Oh, I had no idea such an effort was underway!
Sounds interesting, let’s hope it does not end up being yet another format.
Was there any announcement about JUCE supporting CLAP in the future?
In the short term I still think that having a set of VST2/3 wrappers (both directions) would be easy and convenient…
This is kind of a new development, but yes it has a very good chance of becoming a true open plugin standard that is not controlled by a single company like VST is, for example, or AU. Absolutely zero licensing issues. If the JUCE team doesn’t support it, I suspect there will be a JUCE fork before too long that does. My understanding is that its easy to convert a plugin or host from VST2 to CLAP…so it would likely be an easy addition to add CLAP support to JUCE, but I don’t suspect they will right away until they see it pickup momentum.
There is strong potential for this to be the format that 99% of plugin developers code to…and then all other destination formats become easy wraps around that. An awful lot of plugins out there are coded once and use wrappers to provide the various existing formats. The problem is that all the existing formats are also surrounded by licensing complexities…or some cases over-engineering complexity. CLAP is setting out to be very straightforward, people are going to like coding plugins with it, once there are wrappers for all the destination formats, it will be a no brainer to just code to CLAP and have your plugin work everywhere. I’m very excited about this future actually. I believe its going to pick up steam and JUCE will have to support it, but it may take them a while to realize it.
But that is a lot better then chasing after Steinberg’s shifting goals.
But also yes, once hosts starts to just host CLAP directly…when nobody will need wrappers anymore and there will be no license problems at all…CLAP all the way. Apple will cling to AU for a long time as will Steinberg cling to VST…they have coded their stuff that way, they aren’t going to change. Also protocols with AAX, but CLAP has the promise to be the true open standard for plugins, and some of the “right” developers are getting on board with it now…which is going to help it gain momentum.
3 Likes