KVR Audio

Music Engineer · Post by **Music Engineer** » Mon Aug 31, 2009 11:50 am

is this possible? and if so, how? having always used SDKs so far, i'm not all that familiar with the lower levels of working of dlls and stuff (Win-API, whatever). the background of this request is, that i'd like to start an open-source VST-plugin project and i would like to go GPL with that (which would be incompatible with the 'no redistribution' clause of the VST license). any ideas, thoughts and comments are welcome

thanks, robin

thevinn · Post by **thevinn** » Mon Aug 31, 2009 12:07 pm

That is a good question. I believe it is possible. You would need to provide your own SDK-headers.

Steinberg doesn't own a copyright on function names or the specific data types in terms of the order and type of struct members, but they do own a copyright on the SDK files.

I think something along the lines of, look at the SDK and determine which structures and constants you need. Create your own header file and type into that header file, your own versions of these structures and constants, perhaps with your own names, or not (I don't think the names of structs and struct members can be copyrighted). Does this count as redistributing their SDK? In my opinion, no.

DISCLAIMER: I am not a lawyer, and this is not legal advice.

mistertoast · Post by **mistertoast** » Mon Aug 31, 2009 12:15 pm

I wonder what some of the other projects do. Aren't there a couple of .NET VST projects?

Rock Hardbuns · Post by **Rock Hardbuns** » Mon Aug 31, 2009 12:16 pm

There's been talk about it before, and I seem to recall the license saying that you can't legally make a compatible frame work. In other words, as soon as you click that "agree" button on the download page you become "tainted".

There was some project related to LMMS that attempted a clean room reverse engineering, but I don't think they ever completed it.

The question is how applicable that license is where you happen to live, and if Steinberg would actually go after you.

Otherwise, to do the clean room thing, you need someone who hasn't agreed to Steinberg's license. Then you or someone else can write an abstract spec of the interface without violating any copyrights, just describing it, and have the "untainted" person implement it based on that.

deraudrl · Post by **deraudrl** » Mon Aug 31, 2009 5:16 pm

Robin from www.rs-met.com wrote:the background of this request is, that i'd like to start an open-source VST-plugin project and i would like to go GPL with that (which would be incompatible with the 'no redistribution' clause of the VST license).

You're reminding me why I dislike the GPL: its pathological quest for idealogical purity means that when it brushes up against the real world (in this case Steinberg's rather liberal licensing terms), it gets in the way of doing the very sorts of things it supposedly was set up to promote.

(A more cynical view that I occasionally give credence to is that the GPL is a rather heavy-handed attempt to create a de facto monopoly on the whole concept of 'open-source'.)

Rock Hardbuns wrote:Otherwise, to do the clean room thing, you need someone who hasn't agreed to Steinberg's license. Then you or someone else can write an abstract spec of the interface without violating any copyrights, just describing it, and have the "untainted" person implement it based on that.

IMHO, that dog won't hunt. I seriously doubt "an abstract spec of the interface without violating any copyrights" is possible without being too abstract to get the job done. E.g. "A program called a 'host' will make a call into an entry point in your DLL, but I can't tell you what that entry point is or what you have to do in response to the call to keep the host from telling your DLL to bugger off."

More to the point, in the (unlikely) event Steinberg goes after your ypothetical "untainted" person, that person would have to show how he/she derived the required information. What it will come down to is that they were provided that information through contact with a licensee.

(And obviously you can't just trace the calls/responses between a VST-compliant host and a VST-compliant DLL...unless you can find one of each that are, in your words, untainted. File that one under "ain't gonna happen".)

mistertoast · Post by **mistertoast** » Mon Aug 31, 2009 5:23 pm

Maybe a reasonable thing to do is just make the thing be standalone, with a nice, clean structure that lends itself to be easily moved into a VSTi.

Xenakios · Post by **Xenakios** » Mon Aug 31, 2009 5:38 pm

To the original poster : Could you consider some other open source license than the often extremely inconvenient GPL?

mistertoast · Post by **mistertoast** » Mon Aug 31, 2009 6:10 pm

Xenakios wrote:To the original poster : Could you consider some other open source license than the often extremely inconvenient GPL?

Would MIT work?

LOSER · Post by **LOSER** » Mon Aug 31, 2009 7:02 pm

deraudrl wrote: (A more cynical view that I occasionally give credence to is that the GPL is a rather heavy-handed attempt to create a de facto monopoly on the whole concept of 'open-source'.)

Agreed. The GPL is a viral license "infecting" every project that it comes in touch with, unless it isn't compatible...

deraudrl wrote: IMHO, that dog won't hunt. I seriously doubt "an abstract spec of the interface without violating any copyrights" is possible without being too abstract to get the job done. E.g. "A program called a 'host' will make a call into an entry point in your DLL, but I can't tell you what that entry point is or what you have to do in response to the call to keep the host from telling your DLL to bugger off."

More to the point, in the (unlikely) event Steinberg goes after your ypothetical "untainted" person, that person would have to show how he/she derived the required information. What it will come down to is that they were provided that information through contact with a licensee.

But it worked for Phoenix Tech when doing a clean room design of the IBM BIOS. They basically invented that whole thing as far as I know. Basic scheme is you need people that know the code/API/whatever then you let them write detailed specifications of those, after all striving for interoperability is still legal as far as I know and welcome (remember the AMD vs. Intel antitrust lawsuits against Intel's monopoly). Now that you got the specs you need a bunch of folks that have never ever in their life seen nor heard of the code/API/whatever and tell them to implement the specs. Now just keep the contaminated folks away from the clean people and hope that the specs are good enough to yield a compatible implementation. If not you just blew A LOT of money for nothing.
Anyway there are lots of examples for that, especially back in the 80s with BIOS code.
It even hold up in court, see Connectix with their _reverse engineered_ Playstation emulator vs Sony. They used a Chinese wall revers engineering method, where one group reverse engineers the code and writes specs and the other group implements new code according to the specs, which is somehow magically not considered a derived work any more

.
Heck you could even reverse engineer a whole OS like the guys from the ReactOS project reverse engineer Microsoft's NT kernel and Microsoft can do jack about. But it all comes at a cost, for example the ReactOS project is working on the project since Windows 95 or was it even Windows 3.1. Anyway it's not as trivial as it seems.

So while technically it could be done you'd need skilled people that _can_ and _are willing_ to write good specs for the VST SDK _and_ people that don't know anything about it to implement it, which seems unlikely because why on the planet should someone not interested in the VST SDK re-implement it from some specs without knowing if the endeavors will ever succeed ... unless you pay him ...

So licensing under a different license might be a good idea. MIT, BSD, ISC come to mind. If it must have a non-commercial use clause in it maybe creative commons, anyone tried that for code? With the non-commercial clause.
In case nothing appropriate can be found you can always roll your own, or maybe adapt the GPL into some sort of GPL VST license that allows having parts of it (the SDK) under a different license.

antto · Post by **antto** » Mon Aug 31, 2009 8:00 pm

LOSER wrote:..So while technically it could be done you'd need skilled people that _can_ and _are willing_ to write good specs for the VST SDK _and_ people that don't know anything about it to implement it, which seems unlikely because why on the planet should someone not interested in the VST SDK re-implement it from some specs without knowing if the endeavors will ever succeed ... unless you pay him ...

Hi ;]
i've never used VST SDK yet, and i'll probably won't use it soon, tho, i want to write VSTs (i just don't have the time to learn how to deal with another SDK)
tho, if i am to write something that'll work like a VST - i will definately be interested

EDIT: Robin, that's a pretty interesting question there!

and the thing about "someone analyzing it and another one writing new code based on the other guy's analysis" sounds nice

matt42 · Post by **matt42** » Mon Aug 31, 2009 8:04 pm

How do things like Synthedit get around it?

antto · Post by **antto** » Mon Aug 31, 2009 8:05 pm

SynthEdit is not opensource as far as i know
EDIT: and um, who said it uses the VST SDK anyway?
it just compiles a new DLL that happens to work inside VST Hosts i guess ;]

Jeff McClintock · Post by **Jeff McClintock** » Mon Aug 31, 2009 8:24 pm

matt42 wrote:How do things like SynthEdit get around it?

SynthEdit uses the real Steinberg SDK, and i remind users to obey the terms (i.e. acknowledge "VST Plugin technology by Steinberg media Technologies AG"). So no need to sidestep the law. SynthEdit SEM plugins are BSD license... which is open source with no Viral clauses or anti-capitalist rhetoric.

mystran · Post by **mystran** » Mon Aug 31, 2009 10:07 pm

There's couple of loopholes though...

Namely, GPL allows you to combine GPL code with platform libraries, where the platform libraries need not be GPL (or compatible). Read the license about the details, but if you manage to convince yourself that VST is part of the platform, then you could release the rest of the source as GPL. The reason for this loophole ofcourse is to allow you to compile GPL on systems like Windows, OSX or Solaris, where neither the runtime libraries or system headers are GPL compatible.

The second possibility is kinda related: you are under no obligation to use GPL tools to compile the source code under GPL. This is to allow one to use MSVC or Sun Studio or whatever to compile their GPL code if they so wish. Hence, you could write a tool which compiles your plugin, and make VST SDK part of the tool.

The third possibility is to simply add an exception to the license. Since you are the copyright owner for your own projects, you can always license your code with a modified GPL (though there can be some controversy about this, since FSF owns the copyright for GPL itself); same as the standard except specifically allowing combination with VST SDK. For full GPL compatibility you can also allow it to be combined with regular GPL such that the exception gets dropped, though then you could end up with GPL derivates from which you can't port stuff back into the VST version (except privately; GPL says you can do whatever you want if you don't distribute the result).

Finally you could just dual license: GPL folks can do GPL things with it though they won't be able to use VST SDK with it (unless they convince themselves that VST is the platform), with rest of the world can use it for what they want.

Personally though, I think GPL is overrated. Whatever opensource stuff I might release in the future will use the MIT license just to get rid of this and a couple of similar problems... or if I get particularly evil, I might take the MIT license and add a clause that specifically (and literally) prevent it from being combined with code licenses under the GNU General Public License.

obiwanjacobi · Post by **obiwanjacobi** » Mon Aug 31, 2009 10:18 pm

VST.NET just uses the header files in the interface folder of the installed SDK. These header files define the core callback related identifiers and structures (such AEffect). I don't re-engineer or reverse engineer anything. I just don't use that butt ugly SDK class

If you forget the C++ classes you get with the SDK: The VST interface is nothing more than a couple (5 I think) of function pointers that are passed from the plugin to the host and one function pointer passed from the host to the plugin. Thats it. This information is communicated using the AEffect structure that also holds the plugin name, version, the number of channels etc.

There are two plugin callbacks for getting and setting plugin parameter values. There are two plugin callbacks for processReplacing (32/64 bit) asuming you dont use process anymore. And there is one dispatch callback. This last one carries the bulk of the functionality for a VST plugin.

I wrote C++ intercepting code in my VST.NET (Interop) library that implements these callback functions and passes these call onto the .NET plugin. My Dispacth callback function impl. is just one big switch statement. Not the nicest thing to see, but the simplest way to implement it.

Anyway, I have a fair amount of experience with interfacing a plugin in this manner, so ask away

Hope it helps.

writing a VST plugin without the VST-SDK