linuxaudio.org

On Mon, Jun 21, 2010 at 9:54 PM, Albert Graef  wrote:

quoted text
> Paul Davis wrote:

>> If [ ... ] ***WE BELIEVE*** they form a single program, which must be

>> treated as an extension of both the main program and the plug-ins.

>

> Well, this is a FAQ, not expert legal opinion. But according to the FSF

> the intent of the license is that if A and B are linked together in the

> same program (no matter how that happens, static or dynamic linking,

> dlopen etc.) and B is GPL'ed then the combination A+B becomes a

> "derivative work" and is thus subject to the terms of the GPL.

the FSF has consistently tried to blur the line between "dynamic

linking" and "run time linking" because they involve similar

mechanisms from an OS perspective. but i think, in fact, i ADAMANTLY

believe that run-time linking of an object module as a result of

explicit user action (i.e. not part of the predestined lifetime of the

process) is semantically distinct from dynamic linking. put another

way, if you cannot look at the executable and determine that it will

link a particular object module during its lifetime, it is very, very

hard for me to see how the plugin can be considered a derivative work

of the host (assuming the APIs are not host specific etc etc etc). if

the host will run and function normally whether or not the plugin is

present, its very hard to see how the host can be a derivative of the

plugin.
the FSF's position makes perfect sense to me when applied to dynamic

linking - that is, the set of relationships set up between the

executable file and software libraries during building the software,

but accomplished without copying object code into the executable file

as would happen during static linkage. however, it makes no sense, or

at best, is much too ambiguous and confusing, in the case of run-time

user-initiated linking of object modules.
> At least that's how I read the GPL FAQ. YMMV, but from what I've read in

quoted text
> various discussions, e.g. at license-discuss@opensource.org, I believe

> that this interpretation is right, or at least the one intended by the

> FSF.

The FSF seems to speak with more than one voice on this particular issue.
>No idea whether this would stand up in court. In any case, as a

quoted text
> vendor who wants to distribute such a combination, I would either ask

> the authors for explicit permission or seek legal advice.

>

>> i don't believe that this is really the same thing. yes, this

>> definitely the point of releasing a library under the GPL. but

>> libraries are not plugins.

>

> No, but if your plugin is provided in the form of a dynamically loadable

> module, then according to the FSF it's to be treated just like a library

> linked into your program. It doesn't matter whether the linking happens

> at compile time or at run time.

I believe that the FSF has never written a version of the GPL that

really addresses this, which is why they need to say things like "We

believe ..." in the FAQ. 10 years ago, this was a hot topic for them,

and they've utterly failed to address it with any concrete changes to

the GPL. This may be their intent, but its certainly not mine, and its

not the intent of quite a few other people who develop under the GPL

either. The idea that because a particular host can load my plugin, my

plugin becomes a derivate work of that host is frankly just absurd.

Which license would a VST plugin fall under, given that it can be

loaded into Ardour, Cubase, Sonar or Samplitude? Which host is it a

derivative of? If I write a GPL'ed VST plugin (they do exist), at what

point does the run time linkage change the licensing of either the

plugin or a host that loads it?
> Otherwise a commercial vendor could just turn GPL'ed libraries into

quoted text
> "plugins" and happily sell its non-free programs using those. That's

> surely not the intent of the GPL.

The only way that "my view" of the GPL and plugins could permit this

would be for the commercial vendor to:
   a) define an API that was independent of their "host" application

   b) make the host support that API

   c) port the libraries so that the only calls made by the host were

part of the API (i.e. the actual library API

           could not be used)
and even if they did this, if their host was the only application that

used the API, the burden of guilt would fall heavily upon them in any

court (legal or public opinion).

_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev