Announcement for programmers...

[valley]

damn you! now I'lll have no choice but to crack open my dusty c++ books...

I'll probably write a pascal wrapper for it, so you may not have to.

[valley]

So no non-open source libraries can be used with it. Have the VST libraries been open-sourced then? I know VSTGUI has, but if the VST SDK hasnt been, no-one can actually use this to make VST plugins...

AFAIUI that is correct, yes.

[valley]

it's GPL - that means I can charge companies who want to use it for a commercial product. Similar kind of deal to libraries like Qt.

You can with LGPL as well.

[kuniklo]

jules quoth
it's GPL - that means I can charge companies who want to use it for a commercial product. Similar kind of deal to libraries like Qt.

So no non-open source libraries can be used with it. Have the VST libraries been open-sourced then? I know VSTGUI has, but if the VST SDK hasnt been, no-one can actually use this to make VST plugins...

It's perfectly legal for GPL code to load proprietary libraries (witness the linux kernel & nvidia drivers, for instance). It's not legal for proprietary code to link to GPL code though.

Dynamic linking of Juce-based instruments into VST hosts should be ok though.

Jules can also license Juce as a dual-license library, the commercial branch of which allows any use as long as the fees are paid (it sounds like that's exactly what he's doing now).

[valley]

Dynamic linking of Juce-based instruments into VST hosts should be ok though.

No, because the VST plugin needs to use Steinberg's VST SDK, which is not GPL, and cannot therefore without Steinberg's consent be used in GPL projects.

If you release code as LGPL, I cannot include it in a GPL application, because I am applying the GPL license to it.

You cannot even link to GPL libraries if the link is considered to be core to your application's functionality without bringing your own code under the GPL.

[NiallM]

Licensing issues notwithstanding, this is very cool , thanks! I'm going to have to spend some time getting to know it .

I'm not sure that it'll replace wxWidgets for me yet though...

- Niall.

[optilude]

No, because the VST plugin needs to use Steinberg's VST SDK, which is not GPL, and cannot therefore without Steinberg's consent be used in GPL projects.

I think we all need to read the GPL very carefully, myself included. I'd read it again if I had time right now, but I thought it worked like this:

o GPL'd code means that if you modify and distribute it, you have to release your modifications under the GPL. It's like that so that someone can't take a great GPL app and build upon it and then release an improved version under a more restrictive license, so that the whole community benefits. You have free access to the source code, and the only restriction is that you must grant the same free access to the source of "derived programs".

o The term "derived programs" is what causes confusion with libraries. The LGPL is intended primarily for libraries. AFAIK, if you make modifications inside the library yourself, you have to release these as you would with a GPL application. However, with LGPL, you can link a program to a library and use its external interfaces without having to release the linking program under the (L)GPL. GPL'd libraries are different - here you must release the source code you write which is derived from the library (i.e. which uses the library). That means that only GPL'd applications can link to GPL'd libraries.

o However, there's nothing stopping you linking a GPL'd application a non-GPL'd, closed-source library. You have to release the code which makes the call to the closed-source library, but since you didn't write this and it is a separate entitiy (loaded via a DLL in windows) which was developed for a purpose other than your application, you're not responsible for making it open source.

As someone said, the Linux kernel links to non-GPL'd code all the time. The same is true for an application like mplayer in Linux, which links to closed-source codec libraries in order to play back movie files.

So as far as I know, we could develop VSTs using JUCE, and it would have to be GPL'd, but we could link to the Steinway VST SDK without violating the license. We would have to make the source code to the VSTs so that it would be accessible to anyone who also had access to the JUCE library, but apart from that, there should be no problem.

If you release code as LGPL, I cannot include it in a GPL application, because I am applying the GPL license to it.

If I'm readin that correctly, you're plain wrong. There are hundreds of GPL apps who link to LGPL libraries. They're both endorsed by the same organisation as alternative licenses for different needs, for crying out loud!

You cannot even link to GPL libraries if the link is considered to be core to your application's functionality without bringing your own code under the GPL.

This is correct, and it's the main difference between the LGPL and GPL as far as I know. But as you put it, the VST SDK is not your own code!

Martin

[valley]

o However, there's nothing stopping you linking a GPL'd application a non-GPL'd, closed-source library. You have to release the code which makes the call to the closed-source library, but since you didn't write this and it is a separate entitiy (loaded via a DLL in windows) which was developed for a purpose other than your application, you're not responsible for making it open source.

Correct.

So as far as I know, we could develop VSTs using JUCE, and it would have to be GPL'd, but we could link to the Steinway VST SDK without violating the license. We would have to make the source code to the VSTs so that it would be accessible to anyone who also had access to the JUCE library, but apart from that, there should be no problem.

Incorrect, and indeed Steinberg have stated this a number of times.

With the VST SDK, you are not linking to a library, you are including someone elses (Steinberg's) code inside your own. See below:

If you release code as LGPL, I cannot include it in a GPL application, because I am applying the GPL license to it.

If I'm readin that correctly, you're plain wrong. There are hundreds of GPL apps who link to LGPL libraries. They're both endorsed by the same organisation as alternative licenses for different needs, for crying out loud!

I didn't say anything about linking libraries, I was talking about including code. If I release a chunk of source code, you cannot use it in a GPL project because that source code becomes part of your source and thus is included under the GPL, which I never gave you the right to do. Read the GPL FAQ as it pertains to "compatible licenses".

Anyway, some quotes from the GNU site:

If a library is released under the GPL (not the LGPL), does that mean that any program which uses it has to be under the GPL?
Yes, because the program as it is actually run includes the library.

If a program released under the GPL uses plug-ins, what are the requirements for the licenses of a plug-in.
It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them.

If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, so plug-ins must be treated as extensions to the main program. This means they must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed.

If the program dynamically links plug-ins, but the communication between them is limited to invoking the `main' function of the plug-in with some options and waiting for it to return, that is a borderline case.

Oh, and BTW talk of OSes is a little fuzzy because the GPL makes explicit exceptions for linking with core or kernel components.

[kuniklo]

Incorrect, and indeed Steinberg have stated this a number of times.

With the VST SDK, you are not linking to a library, you are including someone elses (Steinberg's) code inside your own.

There's nothing wrong with linking to a proprietary library from a GPL application. Directly including code is, as you correctly state, a violation of the GPL. I haven't built any VSTs myself, so I don't know - when compiling a vst do you simply link to a vst.dll or something or do you actually link VST code into your own dll?

[valley]

There's nothing wrong with linking to a proprietary library from a GPL application.

No, and I didn't actually say there was; I think wires were getting crossed a litt

Directly including code is, as you correctly state, a violation of the GPL. I haven't built any VSTs myself, so I don't know - when compiling a vst do you simply link to a vst.dll or something or do you actually link VST code into your own dll?

The SDK is a collection of headers, and virtual classes that you directly include into your own code.

[kuniklo]

The SDK is a collection of headers, and virtual classes that you directly include into your own code.

That's a problem then.

[Mr. Slater's Parrot]

How hard to you think it would be to integrate bindings for a scripting language like Python or Ruby into this framework?

I would love to see a Python binding -- whoa, that would be cool!

[Angus_FX]

It's quite possible to build a working VSTi without including any Steinberg headers (although you would have to either use ideas derived from reading those headers, or reverse engineer a VST host and plug to figure out the interface).

VST is essentially nothing more than a protocol, a set of rules by which two pieces of code can talk to each other. Can such a thing be copyrighted? If in doubt, ask a lawyer

[Robert Randolph]

Im fairly sure as long as you do not use steinberg's SDK there is problem... and it's entirely possible to go without....

[optilude]

Valley, I take your point. I was mistaken about what the VST SDK did.

Jules, can we have an official word on this? I'd be a great shame if we couldn't develop VSTs with this, as it would seem to be one of the most natural and sensible uses for it, in the short term at least.

I guess worst case, you could offer a dual license for freeware tools, or even a royalty (as e.g. a percentage of sale price) scheme for a commercial license that's also available for currently-free-of-charge applications?

Martin