Hi @Yvan
I would like to use a VST3 plug-in created with the VST3 SDK for company business. The plug-in may be used not only by myself but also by my colleagues on the same team.
I want to use it as a tool for music production, sound design, and other content creation. We do not sell the plug-in as our own product.
Do I still need to submit a license form in the above cases?
Regards
Hi
If you use the Gplv3 license (it means that you provide the source code of your plug-in) you donāt have to sign the Steinberg license agreement, if not (just deliver the binary to your users) you have to sign it.
This might seem like a dumb question but I donāt quite understand how to sign the agreement. Do I need to print out all the pages, physically sign the last one with a pen, then scan them back into my PC and email it to you?
Also I am a solo developer hoping to make a buck or two from a VST instrument Iāve written. As a sole trader under UK law, I will trade āasā a brand name, but that isnāt a registered limited company- think āFred Smith trading as Fredās Window Replacement Servicesā. Should I fill in my as as company name?
Thanks
You could use a PDF tool to fill the agreement and included your signature. And send it back to the mentioned email.
You should enter the company name under the one you will distribute your plug-ins, if you have no company related to this plug-in developments just enter your name.
@Yvan, you donāt see a possibility of relaxing the GPLv3 OSS license to another, still compatible with GPLv3 but not as draconian and limiting the developerās options, do you? As an example of my own situation, Iām experimenting with sound processing just for the fun of it, and am using Intel One libraries, which are de facto the golden standard in high-performance computing, including DSP. They are closed-source libraries, and are incompatible with any variety of GPL, with a possible (IANAL, though) exception of LGPLv2. Certainly not with GPLv3. A large part of the OSS community has been reluctant to adopt GPLv3 because of its clear imbalance on interoperability. The most common OSS license used to-day is Apache 2.0, ācompatibleā with GPLv3, although without a legal precedent the definition of ācompatibilityā varies with the legal scholar you ask; itās fair to call it a gray legal area. Some solicitors even hold the opinion that compiling a GPLv3 source with a non-OSS toolchain, such as that which comes with Microsoft Visual Studio, is impermissible because it constitutes illegal combining GPL-licensed source with a closed-source part of the toolchain, C/C++ runtime library to produce a runnable binary.
Apache 2.0 is commonly preferred over the MIT license because it provides a strong protection against patent trolls, like GPLv3 and unlike the MIT. Both Apache 2.0 and MIT licenses are permissive, in the sense that they allow the use of OSS code in commercial applications. Naturally, such a commercial use would require the adopter of the VST3 OSS code comply with Steinberg and Intel licenses.
GPLv3 prohibits release of the final product in any form, source or binary, if it is linked with Intelās oneIPP. This is a bummer. Of course, implementing the function provided by the Intelās library is not something that I would consider even in a nightmare.
In my opinion, shared to at least a noticeable degree within the modern OSS community, the FSF philosophy and its family of GPL licenses fell behind the times and is archaic for the modern OSS. Weāre no longer living in the Bell Labs times, where engineers were hired and then given a complete freedom to work on what they find interesting and promising.
While for-profit businesses are often open to the idea of OSS, none of them in their sane mind would release code under any of the GPL varieties, for its infectiousness and incompatibility with many other libraries, be they OSS or not. The unfortunate and unexpected non-repeal of the Section 174 in December 2023 aggravates the situation manifold: the wave of bankruptcies of small software business, practical inability of starting a software business in the US, and the coming significant reduction of software engineering workforce in large businesses, all of which are the inevitable consequences of this ill-conceived law coming into effect the last year, and the current dysfunction of the US Congress leaves little in the way of a possible resolution of this new grave problem.
It must be noted that GPL licenses are acceptable in narrow niches, such as stand-alone executable programs, but itās hard to see how they pragmatically sensible to apply outside of these. The decision of the Linux kernel team not to adopt GPLv3 is telling a lot. Mac OS is based on FreeBSD chiefly because of legal impossibility to adopt the Linux kernel for it because of its GPL licence.
The bottom line is the GPL licenses pragmatically outlived themselves as the default to-go options, save for narrow circumstances. Iāve avoided touching on other reasons outside of purely rational and pragmatic ones very explicitly; in particular, folkās philosophical position that the level of software freedom enshrined by the FSF in the GPL family of licenses trumps absolutely any possible arguments, and am kindly asking the discussion participants to stay in cold mind and within the pragmatic reasoning scope strictly along the line of reasoning that I exposed above. In my 40 years in the field Iāve witnessed countless ālicense wars,ā and the one waged in this discussion would be utterly non-constructive, to say the least. On the other hand, arguments exposing possible flaws within the scope of my rational line of reasoning are welcome indeed.
Most of us are musicians and software engineers creating OSS software in our own free time, not barristers. Absolutely the most of us are wanting legal education even to determine whether releasing OSS VST3 software is permissible. GPL licenses are both notoriously voluminous and written in impassable legalese, which would require us to pay an arm and a leg for the solicitorās services, which doesnāt even add the value commensurate with the cost and the hassle, as GPLv3 is legally in a gray area, lacking, as I already mentioned, court decisions, and legal opinions on it vary. Additionally, the FSF is in fact known for prosecuting people for license non-compliance. I certainly wonāt risk grasping the wrong end of the stick to my financial ruin. To me, the choice of GPLv3 for OSS VST3 release is precluded, and Steinberg currently offers no alternative: I may sign the licensing agreement (as I once did for VST2 SDK around 2005, when this was the only option) and choose the non-GPL license option, but this also wonāt permit me release my work as OSS.
Hello All/Steinberg/Yvan,
My apologies if this is uber redundant and obvious others. But I am interested in developing my own VST3 / and possibly iOS compatible plugins. I am interested in using VS 2022/JUCE (I realize it has its own agreements)/Steinberg SDK. Would you please advise me on the semantics of whether or not I can develop my own plugins that are built and deployed as a standalone or vst3 plugin. I am not interested in sharing the C++ code that I have to write in order to build the project/plugin. So I am interested in developing the plugins and either/or selling those built plugins from my own websites or from a site such as plugin alliance etc. What are my confines in order to do so relating to licensing as I will be compiling into .dll or .exe for the outputs and am interested in understanding the limitations of such? As in what steps or processes are involved to do so as I have described in order to deploy my own audio FX? Extra many thanks in advance. I realize this is a remedial question, but there are so many striations of this discussion I am trying to pinpoint my options for being able to sell my builds for monies as it obviously takes quite a while to write the C++ code and develop the gui and implementations. Extra many thanks in advance!
check Licensing - VST 3 Developer Portal (steinbergmedia.github.io)
and
Licensing - VST 3 Developer Portal (steinbergmedia.github.io)
Hi,
thereās a debate over at KvR on the implications of the latest VST 3 License agreement (2.2.5) where it is assumed the the entitlement to developers to develop VST2 plugins is withdrawn even despite a potentially existing VST2 license agreement, see here:
Iām a little puzzled. Our situation is as follows, we have agreements for VST2 and VST3 both signed a couple of years ago.
Can you please clarify whether updating to the v3.7.10 SDK requires signing the new agreement with Steinberg and will that ultimately prohibit the development and release of VST2 plugins? Or does that only apply to new developers starting to use the SDK just now?
The Licensing FAQ says the following:
Q: I am a developer/company and I want to develop and distribute a VST 2 plug-in and/or host in binary form.
- If you have signed the VST 2 license agreement (before October 2018), you can.
- If not, you are not allowed to distribute it!*
- See here!
Does that still apply?
Thanks.
Best,
Ray
Thanks for posting this @ray3
I just went there and skimmed the last few pages; interesting - seems quite the thread.! Three important 3rd-party developers contributing to it so far - U-he, Audiority and BlueCat Audio.
The topic of VST2 based plugins presented in a VST3 wrapper, caught my eye - whether these too fall into the āno longer allowedā (to be distributed) category, under this new License Agreement (v2.5.5). Its suggested several places I saw in that thread, the wording of the Agreement could be more definedā¦
Also, I wonder, does this affect DAW host developers continuing support of (native) VST2 built plugins/instruments, whether in a VST3 wrapper or not.?
Hi @Puma0382 ,
yes, the latest SDK (v3.7.10) still includes the vst2wrapper - if thatās what youāre referring to - and weāre still using that to deploy our plugins in the VST2 format without any issues.
It wouldnāt make much sense to keep the vst2wrapper files had they intended to finally drop VST2 altogether, would it?
Anyway, I hope Luca from Audiority is misreading the current license agreement and someone from Steinberg will step in here to clear things up.
Best,
Ray
Ok - thanks @ray3; its likely I misread/understood somewhatā¦
So is the point of the vst2wrapper to enable plugins appear as VST3 to the host.? This was what Urs from U-he was talking about (I think.!). Maybe he meant that he uses (or knows of many others that use), a different or an in-house built VST3 āwrapperāā¦
Iām just a curious and interested onlookerā¦ 
Hopefully SB will comment somewhere or other, at some point.
Bob
Itās the other way around. Itāll allow a VST3 plugin implementation to be rendered to VST2. There are other wrappers for AU, IAA, AUv3 and AAX native included in the SDK, too btw.
Right. Then I must be getting this all wrong indeed.!
I thought I was reading that Urs was referring to those devs who had supplied VST3 plugins which were not built as VST3 from the ground up - but were largely VST2 based, wrapped to appear to the host as VST3. This, in order to capitalise on prior investment/time/resource spent developing the plugin in the first place without having to re-write or re-build from scratch; just so they had a VST3 edition of a particular plugin (where for example Cubendo, would otherwise immediately blacklist said VST2 version).
Forgive me, but why would anyone want to do that these days.? What would be the advantages here.? Most if not all the main DAW hosts support VST3 well, to my knowledgeā¦
Apologies Ray - Iām well out of my comfort zone now. Will leave it there.!
Iāll take time to go back and re-read that threadā¦ and maybe not overthink/make assumptions on stuff I know little about.!!
Anyway, thanks again for responding.
Wrapping from one format into another is common practice. The typical use case for wrapping VST3 to VST2 would be to support hosts which did not yet offer VST3 support (e.g. Ableton Live took some time to add VST3 support). I guess these days itās pretty much pointless as virtually every VST capable DAW offers VST3 support AFAIK.