More VST3 shenanigans.
Ask Steinberg "Can we create VST3 implementations for other languages and license that under the original VST3 SDK license?"
Summarizing their response:
"Oh, yeah, we didn't think of that, let's explicitly prohibit porting to different languages even though we can't legally prevent you from doing so."
What a nice way to deal with a plugin **standard**. 🐒 🐒 🐒
@falktx Amazing.I guess I was right to not trust Steinberg and VST3 after what they've done with VST2.
The question is - who wants to risk getting into a legal battle with a corporation over this, seemingly unloosable case...
And if it's just better to give them the finger and use LV2 instead?
If the implementation is from the spec or clean room reverse engineering then they legally can't do shit unless they have patents.
@colinsmatt11 APIs are not copyrightable, that is enough to handle this whole thing. They still act like they are though.
Also the API copyrightability is non in US and EU, not sure about others
@colinsmatt11 a pure reimplementation that would just convert the existing C++ code into something else would for sure be problematic, but Steinberg doesn't even want clean-from-scratch implementations.
As far as I am aware, but obviously not a lawyer and all that, implementing something from scratch that targets an existing API is quite okay. No copyrighted code ends up being used.
Also from what I understand you are trying to say that implementation of backend with similar API to Steinberg's implementation, is that correct?
@colinsmatt11 right yes, which is kinda what rust developers are doing. A lot of C++ concepts do not apply to rust, so a pure conversion is not ideal.
I did something similar myself for DPF where I went with a custom API-incompatible implementation.
On both cases the final binary is ABI-compatible with regular VST3. As far as users are concerned, all approaches result in valid VST3 plugins
@falktx my solution to this is to ignore stenberg's unenforceable and vaguely illegal license