Steinberg sending DMCA takedown notices for the VST2 SDK
category: general [glöplog]
Hi Pouet!
Recently, I was hit (along with a whole bunch of other people and organizations) by a DMCA takedown notice from Steinberg Media Technologies GmbH targeting GitHub repositories that include the VST2 SDK. This SDK can be freely downloaded from Steinberg's website, but the accompanying license prohibits redistribution. Nevertheless, it has been routinely included in many repositories for VST plugins and hosts (and many that are not specifically for a plugin or host but just happens to contain one in some subcomponent).
This crackdown is apparently part of a push by Steinberg to phase out the VST2 API in favor of VST3. By enforcing their redistribution clause this way, and at the same time removing VST2 from their SDK distribution (which they allegedly plan to do by October 2018), they are effectively making it difficult to develop open source VST2 plugins.
So I was thinking that this information could be relevant to some people in here, and it could also be interesting to hear what the Pouet community has to say about the situation. It is my impression that VST2 is (still) the most popular audio plugin format, both in general and within the demoscene. Many plugins don't need the extra features that VST3 provides, and the VST2 API is easier to use and has a much simpler ABI.
Personally, I am not much affected going forward, since I would want to develop future plugins in Rust anyway, probably using the rust-vst crate, which is not based on the official SDK and is thus (presumably) not covered by Steinberg's copyright.
There is some further discussion among the recepients of the DMCA takedown and on the JUCE forum.
Recently, I was hit (along with a whole bunch of other people and organizations) by a DMCA takedown notice from Steinberg Media Technologies GmbH targeting GitHub repositories that include the VST2 SDK. This SDK can be freely downloaded from Steinberg's website, but the accompanying license prohibits redistribution. Nevertheless, it has been routinely included in many repositories for VST plugins and hosts (and many that are not specifically for a plugin or host but just happens to contain one in some subcomponent).
This crackdown is apparently part of a push by Steinberg to phase out the VST2 API in favor of VST3. By enforcing their redistribution clause this way, and at the same time removing VST2 from their SDK distribution (which they allegedly plan to do by October 2018), they are effectively making it difficult to develop open source VST2 plugins.
So I was thinking that this information could be relevant to some people in here, and it could also be interesting to hear what the Pouet community has to say about the situation. It is my impression that VST2 is (still) the most popular audio plugin format, both in general and within the demoscene. Many plugins don't need the extra features that VST3 provides, and the VST2 API is easier to use and has a much simpler ABI.
Personally, I am not much affected going forward, since I would want to develop future plugins in Rust anyway, probably using the rust-vst crate, which is not based on the official SDK and is thus (presumably) not covered by Steinberg's copyright.
There is some further discussion among the recepients of the DMCA takedown and on the JUCE forum.
interesting
Oh great.
The vast majority of the VST plugins I use are 32-bit VST2 plugins. I understand the desire to push developers to a newer standard, but the world of audio moves at a glacial pace and is generally full of abandonware. Many plugins will never see a re-write. Most audio developers make close to no money, and taking legal actions against open source stuff because of reasons like this will not do anything good for anyone. They could just obsolete it, and let time to its thing. This may damage both Steinberg's reputation as well as people's trust in VST and ASIO as a platform that can be trusted.
That is a bit of a dick move. From an end user perspective it's not really going to be a problem. DAWs will most likely continue to support it for ages and when it doesn't someone will build an emulator plugin like jBridge.
However, it's a bit of a PITA for us. We're nearing release phase for wavesabre which is built on vst2 presently. By the time we ship it you'll have a few months to download the SDK needed before they rip it offline. We can't distribute it so you'll end up trying to download it from some weird ass torrent site.
However, it's a bit of a PITA for us. We're nearing release phase for wavesabre which is built on vst2 presently. By the time we ship it you'll have a few months to download the SDK needed before they rip it offline. We can't distribute it so you'll end up trying to download it from some weird ass torrent site.
Totally not unexpected. Not at all.
BeRo has written a replacement header using cleanroom reverse-engineering principles, so there is little Steinberg could do against this header: https://github.com/BeRo1985/br808/blob/master/VSTi/VST/VST.pas
Time to translate it to C/C++!
BeRo has written a replacement header using cleanroom reverse-engineering principles, so there is little Steinberg could do against this header: https://github.com/BeRo1985/br808/blob/master/VSTi/VST/VST.pas
Time to translate it to C/C++!
yeah i had a colleague at work who was hit by this, even though it was a private repository (i think? will confirm that..)
hmm, if they're picky enough to have a clause disalow re-distribution it most probably also has a clause against reverse-engineering it aswell. so BeRo's header might also be illegal to use. just speculating here, didn't check Steinberg's terms. also, not sure where each countries law stands on fair use of reverse engineering, i recall there was a lot of industry lobby anti-reverse-engineering, but from some talks of hackerconferences and such i also heard there are some public interest movements putting pressure against that. would be nice to have a clarification of what applies legally in this case from someone who knows those laws better.
Better call Frank!
It's sad to read...
Will probably push people to use middleware instead of targeting this kind of SDK.
Roli's JUCE is in a fine position now for a cleaner simpler API that cross the bridge between all the proprietary ones.
Will probably push people to use middleware instead of targeting this kind of SDK.
Roli's JUCE is in a fine position now for a cleaner simpler API that cross the bridge between all the proprietary ones.
What a dick move indeed. :/
How wrong! It seems to me that they are shooting themselves in the foot and I'll consider alternatives to Steinberg in case I need to code some VSTi.
If you weren't previously interested in Steinberg's VST3 stuff, then after this you're certainly going to be very interested.
What does it mean that reverse engineering the SDK isn't allowed? It's a bunch of source files, so how do you reverse-engineer something like that? Try to infer the design principles behind it?
I have zero interest in upgrading my perfectly well working Ableton Live DAW to some supposed newer and larger and more bloated version, and I have zero interest in spending my little free time doing a code migration to useless crap I don't want.
What does it mean that reverse engineering the SDK isn't allowed? It's a bunch of source files, so how do you reverse-engineer something like that? Try to infer the design principles behind it?
I have zero interest in upgrading my perfectly well working Ableton Live DAW to some supposed newer and larger and more bloated version, and I have zero interest in spending my little free time doing a code migration to useless crap I don't want.
Quote:
added on the 2018-07-01 18:57:46 by MrsBeanbag MrsBeanbag
hmm, if they're picky enough to have a clause disalow re-distribution it most probably also has a clause against reverse-engineering it aswell.
It's not that simple. You cannot really legally forbid cleanroom reverse-engineering of a protocol.
Quote:
What does it mean that reverse engineering the SDK isn't allowed? It's a bunch of source files, so how do you reverse-engineer something like that? Try to infer the design principles behind it?
In this particular case, it means recreating all the necessary definitions. Cleanroom reverse-enginering means that it is done by two independent parties: The first party documents the behaviour (which is legal), and the second party re-implements new code based on this documentation (also legal).
How about taking the source code of an existing implementation found on the internet that has everything except bla-bla-bla.h which is missing for some unknown reason? It should work as a reasonably accurate documentation of behavior.
The license for the VST2 SDK reads:
The phrase "must not be used to re-engineer" presumably means that you (the SDK licensee) are not allowed to create your own, compatible header for writing VST2 plugins based on the information in the SDK. Terms like this are the reason people make clean-room reverse engineered headers. Whether or not such re-engineered implementations (clean-room or otherwise) are a violation of copyright as such (and in particular whether they can be taken down under the DMCA) is, as far as I understand, a bit of grey area.
Some repositories using the supposedly clean-room VeSTige header were hit by the DMCA takedown in question (possibly as a mistake from Steinberg because of the unchanged filename). At least some of these contested the takedown on the grounds that the file was not in fact copyrighted by Steinberg.
Code:
// This Software Development Kit may not be distributed in parts or its entirety
// without prior written agreement by Steinberg Media Technologies GmbH.
// This SDK must not be used to re-engineer or manipulate any technology used
// in any Steinberg or Third-party application or software module,
// unless permitted by law.
// Neither the name of the Steinberg Media Technologies nor the names of its
// contributors may be used to endorse or promote products derived from this
// software without specific prior written permission.
The phrase "must not be used to re-engineer" presumably means that you (the SDK licensee) are not allowed to create your own, compatible header for writing VST2 plugins based on the information in the SDK. Terms like this are the reason people make clean-room reverse engineered headers. Whether or not such re-engineered implementations (clean-room or otherwise) are a violation of copyright as such (and in particular whether they can be taken down under the DMCA) is, as far as I understand, a bit of grey area.
Some repositories using the supposedly clean-room VeSTige header were hit by the DMCA takedown in question (possibly as a mistake from Steinberg because of the unchanged filename). At least some of these contested the takedown on the grounds that the file was not in fact copyrighted by Steinberg.
They can send all the letters they want to the clean room guys, it doesn't mean they're right. It has to be tried in a court that rules in their favor for them to be legally right. The consequences of loosing such a trial is of course catastrophic for the individual which is why they do this. They use fear as a weapon against open source.
Also, for a clean-room design to actually hold up in court, it's probably necessary to have a lawyer involved in the reverse engineering process, to make sure everything is done and documented properly enough to count as proof.
vst2 does not support sample accurate automation. if you develop cross platform, cross interface, this often leads to either developing for the lowest common denominator, or write a lot of special case code. super old obsolete standards that refuse to die because of "good enough for me lazieness" from daw vendors as well as pligin developers is the reason why we can't have nice things.
there are more issues with vst2, like output configuration (ever encountered a plugin which comes in multiple variants for different output configs?), window management (try and make a resizable ui with vst2), and the need for the user to manually manage where all the dlls are put. then there is the fact that vst2 plugins are uniquely identified by a 4c code. i bet many free software devs don't properly register their ids. I could go on, but you probably get the idea.
Steinberg creating a bit of pressure is a good thing for moving the whole industry forward. Same goes for Cubase ditching 32bit vst support.
there are more issues with vst2, like output configuration (ever encountered a plugin which comes in multiple variants for different output configs?), window management (try and make a resizable ui with vst2), and the need for the user to manually manage where all the dlls are put. then there is the fact that vst2 plugins are uniquely identified by a 4c code. i bet many free software devs don't properly register their ids. I could go on, but you probably get the idea.
Steinberg creating a bit of pressure is a good thing for moving the whole industry forward. Same goes for Cubase ditching 32bit vst support.
@Blueberry: spot on (especially the part where you state that "the VST2 API is easier to use and has a much simpler ABI." full ack!
yep
We have all downloaded the VST2 SDK years ago, haven't we ?
(my 2c: such a widespread, general purpose plugin format should have never been placed at the mercy of one single company!)
actually, it did. check out the 'deltaFrames' field in the host event structure. I'm not saying that many plugins ever supported that, though.
that's not a problem. see UVI Falcon for example.
yep, like ASCII, and MIDI.
but yeah, they really want VST2 to die. In my opinion, newer does not necessarily equal better. Last but not least, loading a VST3 in a language other than C++ is probably a real PITA.
Quote:
That is a bit of a dick move. From an end user perspective it's not really going to be a problem. DAWs will most likely continue to support it for ages and when it doesn't someone will build an emulator plugin like jBridge.
yep
Quote:
It's not that simple. You cannot really legally forbid cleanroom reverse-engineering of a protocol.
We have all downloaded the VST2 SDK years ago, haven't we ?
(my 2c: such a widespread, general purpose plugin format should have never been placed at the mercy of one single company!)
Quote:
vst2 does not support sample accurate automation
actually, it did. check out the 'deltaFrames' field in the host event structure. I'm not saying that many plugins ever supported that, though.
Quote:
try and make a resizable ui with vst2
that's not a problem. see UVI Falcon for example.
Quote:
super old obsolete standards that refuse to die because of "good enough for me lazieness"
yep, like ASCII, and MIDI.
but yeah, they really want VST2 to die. In my opinion, newer does not necessarily equal better. Last but not least, loading a VST3 in a language other than C++ is probably a real PITA.
Quote:
yep, like ASCII
Everytime I see characters outside the ASCII range rendered as garbage, I'm reminded that as long as humanity can't get even the most basic things right, the AI singularity is probably still a way off. ;)
Those "sample accurate and resizeable UI, multiple outputs" have been done inside vst2 but are not really supported by vst2 itself am I right? (Diva, Battery)
I think it would be better to be able to extend something that's VST2 compatible, open source, and Steinberg-free.
And by "open source" I meant free and open source, like LGPL or something.
Move to BSD make some dumbass "interface" for "plugins".
