On Mon, Apr 19, 2004 at 05:29:00PM -0400, Dave Robillard wrote: My understanding was that they would do it, except that the SDK doesn't work in g++. GMPI will (maybe) obsolete that all, one day. Until then, a free VST is a great answer.

Thanks. We are still looking into some outstanding issues with it. Come learn all about it at ZKM :) This is an error on my part. I forgot that libwinelib.c was covered by an LGPL from the mono crew. The license is a bit complex: fst/fst/vstwin.c: GPL (written by torbenh and myself) fst/fst/<others>.c: LGPL (written by mono but drastically hacked by us) I will correct that in a new release. Our hope is that most of what is in <others.c> can go back into Wine itself in the not too distance future, which would leave us with just a GPL'ed tiny library containing only code that Torben or I wrote. We do not want commercial companies to use this code under an LPGL-like arrangement. There are already 2 companies selling products that use Linux to run VST plugins, and we see no point contributing this particular code to efforts like those. I imagine that Torben and I could be persuaded otherwise. There is no SDK. There is no library, no source files, etc. etc. What is required is a pair of header files. You do not require any VST files to run things based on libfst, only to compile them. My reading of the GPL doesn't suggest to me that this is incompatible with the GPL. Do you see it otherwise? Almost correct. Only the copyright holders of "any other code" can work around that, since they are not bound by the GPL as it applies to their own work. Even then, its a gray area. Its an absurd situation. Unless you (or anyone else) has any suggestions, it can't be fixed until Steinberg changes their approach. So guess who you should be writing to? :)) I will take this up on vst-plugins again. --p

I believe we can work around this by adding an exception to the license associated with FST. Imagine there is a GPL'ed (or LGPL'ed) library that my app uses but its not part of the system. I do not have to distribute the source to that library as part of my application. I can simply point you at the distribution for the library itself. I can tell you "to compile this application, you will need libfoo" - this is common practice for all GPL'ed applications. In this case, the lack of an actual library notwithstanding (:), what we actually have is an external (3rd party) library that is not distributed under the GPL, although it is freely available. I think it should be OK to release FST with a license that says "you will need these files from Steinberg". The tricky part of this is that "these files" are not GPL'ed, so you then have the problem of whether its acceptable to use them in a GPL'ed application. There are two cases I can see: the copyright holder decides to use them, or a licensee decides to add them to a program that does not currently use them. The copyright holder can do whatever they want. The licensee cannot, and so this is where the special clause is required. But AFAICT, its not required of FST. It *would* be required in the following hypothetical situation: I take Rosegarden, and add VST-with-FST support to it. The current GPL license for Rosegarden *I think* prevents me from doing this, because I am aggregating your work with a non-GPL'ed work to which I cannot provide the source. You would have to add a clause to the license of Rosegarden noting that linkage/aggregation with non-GPL'ed code for the purpose of running VST plugins blah blah blah. In practice, this is not likely to be a problem. Most linux audio apps that are likely to acquire VST support will get it from the work of their copyright holders, who are free to include whatever they damn well want :) Put another way: if I write a program that requires libNotGPLed.so, I can still choose to release my program under the GPL. I think. However, you can't take my GPL'ed program and make it require libNotGPLed yourself unless I allow you to do that. Thats my view on it for now.