Re: [LAD] GPL and plugins

On Mon, Jun 21, 2010 at 9:54 PM, Albert Graef <Dr.Graef@email-addr-hidden-online.de> wrote:
> 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
> various discussions, e.g. at license-discuss@email-addr-hidden, 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
> 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
> "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@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Jun 22 08:15:02 2010