The plugin is just a Free software plugin, that is GPL, distributed in
binary form and source code etc. It is written as a plugin, so it can
be used by any host of the same API. The host will load this plugin
instead of the proprietary non-free plugin that it replaces. The
plugin is made available separately, but is also bundled with the
host, which loads it automatically.
My reasons for asking this are that I was asked to write such a plugin
and i) I don't normally do proprietary software; ii) I don't like to
reinvent the wheel. If I can't provide a free solution, I may as well
not take the job.
Victor
On 21 Jun 2010, at 20:34, Chris Cannam wrote:
On Mon, Jun 21, 2010 at 7:22 PM, Victor Lazzarini
<[email protected]> wrote:
I think this is the closest to the scenario I am envisaging. There
is a
host, which is non-Free and commercial, currently using a non-Free
plugin,
which is packaged with it. This non-Free plugin gets substituted by
a Free
plugin, which is free because, amongst other things, it links to a
GPL
dynamic library. Is this breaking the original GPL license of the
dynamic
lib the plugin links to?
That doesn't seem like enough information for anyone to attempt an
answer.
What do you mean by "gets substituted by"? Do the distributors of the
application swap in the GPL plugin, or does the user who received it?
If the latter, how? Was the GPL plugin written specifically to
replace the proprietary one? Can it be used in other hosts?
My inclination is that the answer to your question is probably no,
this wouldn't violate the licence. But the fact that you're asking at
all makes me wonder whether this is a situation in which the plugin
has been designed specifically to interact with a single proprietary
application, or a situation in which the host is distributed with a
plugin that is treated differently from others. If that's so, then
it's possible a court might think that the plugin containing API code
was a derivative work of the host that implemented the API.
I'm not aware of any case in which this has actually been tested
either way.
Chris
_______________________________________________
Linux-audio-dev mailing list
[email protected]
http://lists.linuxaudio.org/listinfo/linux-audio-dev
