robbert-vdh
commented
1 year ago Believe me, if this crate could be licensed under a more permissive license it would be. The problem is that it can't. This crate is derived from the VST3 SDK. When using the VST3 SDK under the GPL you can do whatever you want with it as long as you comply with the GPL's terms, which includes licensing any derivative works under the GPL as well. The alternative license option for the VST3 SDK is a proprietary license from Steinberg. To use that license option you need to sign the license agreement, send it to Steinberg, and when Steinberg sends you a signed version back you are allowed to distribute VST3 plugins under the Proprietary Steinberg VST 3 license. One of the terms of that license agreement is that while you can make modifications to the SDK, or create language bindings you are not allowed to distribute this work to be used by others. See this forum thread. Distributing something like vst3-sys under the same dual license as the VST3 SDK itself requires explicit approval from Steinberg, and at this point it's safe to conclude that Steinberg is not interested in cooperating. As such, this library can only be licensed under the GPL.
An alternative solution that would allow dual license usage would be to write a generator that generates bindings directly from the VST3 SDK, without including any VST3 code itself. This process has been made more realistic by the release of the VST3 C API (which is generated directly from the base+pluginterfaces code using a Python script), but someone still needs to do the work. And then everything that relies on vst3-sys will need a major rewrite to use that. Then you would still have the same GPL restriction by default, since a distributed version of the generated bindings can still only be licensed under the GPL, but after signing the VST3 license agreement you would be able to generate your own bindings and then use the Cargo patch mechanism to replace the GPL VST3 bindings with your own.
m-hilgendorf
techninja1008
I hope not to induce wrath with this radical proposal. I know you all worked very hard on bringing us this library and there are a lot of arguments for keeping things truly free, from linux to gnu, there is a lot to be said for enforcing FOSS and GPLv3 is exactly that.
So why a different license for this project? At the moment, the most promising candidate for easy and feature-complete plugin development seems to be @robbert-vdh nih-plug and, while it is ISC-licensed itself, it relies on vst3-sys for VST3 export. Alternatives: JUCE and the VST3SDK, but they are 1.) way harder to learn 2.) more complicated to actually use (lots of time and complicated steps spent on "doing things because the SDK requires them) 3.) not feature-complete (juce still stubbornly refuses to do sample-accurate automation) 4.) not rust. The compiler is both bouncer-wider-than-door and gentleman-buttler always providing good advice.
1.) The rust eco system for audio plugin development will be most interesting for the small audio plugin devs as: nih-plug is, comparatively, so easy to learn AND use, the dev can spend more time writing good algorithms instead of following all 30 steps it takes to make a single parameter in VST3SDK For inexperienced simpletons like myself, the compiler is a godsend since it helps ironing out stupid mistakes. 2.) I doubt the big audio companies (NI, Waves) would (miss)use the rust eco system, they already have all their tooling for C++ and their engineers are skilled enough to deal with the difficulties of programming VST3s directly. Re-tooling would be expensive. 3.) Audio plugins are, conceptually, quite niche. The kind of laser-focussed effort it takes to produce an outstandingly-great audio plugin is most likely to come from small devs. Serum took Duda over a full year to get right: https://www.youtube.com/watch?v=Cp0rtLaXBio Most open-source plugins don't match their evil proprietary counterparts beacause the stubborn morosity it takes is more likely to appear in a singular individual. Most of the really awesome plugins come from (once) small developers spending many hours out of their own pockets on crafting said plugins. Examples include TDR, Kush, Voxengo, AOM, Valhalla, Klanghelm, Cytomic, u-he and Xfer. Strict copyleft prevents plugin devs selling their plugins, which means they can't use the rust eco system if they want their investment to be able to pay off (or support them). 4.) Devs, whether small or not, are most likely to contribute to an open-source project if they can use it themselves. Lots of even the big companies invest manhours into the linux kernel because it benefits them.
Now I get that Steinbergs VST3 SDK is proprietary + GPLv3 license. If that is the reason for your choice, I think there is a distinction to make: your library is interfacing with VST3 hosts, but not reliant on / using the SDK code. In this case, maybe there is a chance talking to Yvan directly. Another option would be to take a look at how JUCE worked around this issue since that's also GPLv3 + proprietary license.
The end goal of this request is to enable the rust ecosystem to become REALLY attractive and competent for plugin development. Adding a more liberal license to enable closed-source distribution would help to accomplish this. Maybe this additional license can forbid making a similar "product" with it but allow using it as a component.