Releasing VST plugin under GPL

[dj_rejo]

Hi there,

In some topics I read that you can't publish a VST plugin under GPL (or LGPL), or at least that's what I understood of it. I read the license agreement, but I can't find anything implying that. So now I'm not sure whether or not you can publish a VST plugin under GPL. Does anyone know?

Regards,
DJ ReJo

[Music Engineer]

GPL requires to include all of the required source code which implies to include ('re-distribute') the VST-SDK which the VST license not allows...something along these lines, i assume.

[Chris Walton]

Pretty much what Robin said.

If you intend to go the open source route, i recommend the BSD license for pretty much everything.

[dj_rejo]

Ah, so you can't release just your own source code under GPL and refer to the VST SDK for the rest?

Edit: can you with BSD?

[rl]

Ah, so you can't release just your own source code under GPL and refer to the VST SDK for the rest?

My understanding is, that it is possible. It's only that the Steinberg license is not compliant. So anyone who wants to do a build has to download the VST SDK seperately. There have been exhaustive discussions on the VST mailing list.

[laserbeak]

yeah,
in order to get vst support on some GPL linux apps i've used, i'd have to download the sdk and build with that.

[Rock Hardbuns]

As the first author of the software, you can actually just release your source, and have the users get the SDK them selves. As the first authour, you can do what ever you want.

The problem is that this basically makes the GPL pointless since the recipients can't redistribute the software in turn. It also means you can't rely on any gpl:ed libs and such.

So essentially, you are only pushing the problem on to your users.

[hill_matthew]

An example of how some people handle it using BSD: http://code.google.com/p/wormhole2/

[dj_rejo]

Thanx everyone. I decided to make my own license which is mainly based on BSD, but with a few modifications. I guess that works fine for me.

[Akel]

Hello!

I'm sorry for resurrecting such an old thread, but I can't find any answers on either the GPL FAQ, nor around these forums... Most seem to cover GPL, but forget about the Lesser/Library GPL.

Let's say I want to release my plugin under the LGPL as a dynamic library.

1. Can I write and distribute a non-GPL "wrapper" that uses the VST SDK and dynamically links to my plugin, providing it the window handle (so it can draw) and events (so it can do stuff)?

2. Furthermore, could I put that non-GPL wrapper and the LGPL library into a single package, and distribute that as non-GPL (while providing source code for the LGPL part)?

Thanks in advance,
Akel

[aciddose]

if you own all the code (you didn't take other gpl code from somewhere else) you can do ANYTHING you want.

two solutions to the vstsdk problem:

- distribute a closed wrapper for your own plugin format and release your source using that format, not vst

- implement the interface structure yourself and don't use any of the "sdk" files directly, or through modification. if you implement the same interface without using the copyrighted code, even if you are looking at the copyrighted code while doing it - it doesn't apply to you. only the unique elements of the code are copyright protected, such as non-descriptive function and variable names and those sorts of things.

also, the "license" only applies to you if you get something in return. if you're not using the copyrighted files, there is no license. if you break the license terms, you simply no longer have the ability to use the copyrighted files.

for example, the gpl says you are granted the right to redistribute source and binary made from the copyrighted materials under the condition that you pass on the same rights to anyone you distribute to.

just implement this:

Code: Select all

#if defined(WIN32)
#define vstc_IFP __cdecl
#else//if defined(__linux__)
#define vstc_IFP
#endif
#define vstc_HEAD *((long *)"PtsV")

struct vstcore
{
 long head;
 long (vstc_IFP*dispatch)(vstcore*, long, long, long, void*, float);
 blah blah...
};

likewise for the classes. it's exactly like in music: you can hear a dnb track and then get inspired to make your own dnb track using the same beats, progressions and sections of vocals, effects and whatever else. in order to fit into the dnb genre, it must sound similar in all those respects - however your implementation is fundamentally different and built from the ground up without taking anything from the track that inspired you. if you read the lord of the rings and decide to write a book about elves in some forest it's also no problem - just don't name your elves or forests the same as tolkien did. "elves in forests" have become a widely known and general piece of imagery.

while it is possible to claim absolutely anything in tort, it will be very difficult for anyone to convince a judge you've violated any copyright by writing unique and original code that implements a well known and widely used interface. indeed, the interface is general purpose enough that you could use it for other purposes (not vst plugins) and have no problem. in addition, you can claim the interface MUST be used to enter into the market dominated by this interface.

just implement the minimum parts of the interface required for your code to work, like:

Code: Select all

#define clientOpen 0
#define clientClose 1
#define clientSetProgram 2
...

#define hostAutomate 0
#define hostVersion 1
...

[jwatte]

What's wrong with plain "public domain"?

[aciddose]

vstsdk isn't public domain either, same set of problems.

the problem with using gpl'd library code (code you took from somebody else under gpl) is you must release 100% of your source if you distribute the results. you can't mix licenses like gpl with vstsdk.

there is no problem releasing your code without including vstsdk if you don't use anyone else's code while releasing binaries using that code.

[Akel]

That clears up a few things. Thanks for the reply!

It raises another interesting question, though: Why is the VST SDK still used, and not a public domain SDK "inspired" from VST and fully compatible with it?

[aciddose]

because the vstsdk is already there and managing a seperate "inspired" interface wouldn't yield any advantage. lots of open source software implements the vst interface without using any "sdk".