21 Jun
2010
21 Jun
'10
1:11 p.m.
A simple question: can GPL plugins be loaded into non-free hosts?
This may appear a stupid question, but given the fact that non-free
code can't link to GPL binaries, what is the story with dynamic modules?
Thanks
Victor
21 Jun
21 Jun
1:19 p.m.
Hello Victor1
I'm no guru, when it comes to licenses. But I don't really see a problem. As
long as the non-free host can somehow manage to legally include the SDK to
load the modules, then it's no problem. It's on the user's side of things, to
load a plugin or not load it.
I'd think the problem could be to include modules with the non-free
software. But if the user downloads them herself, that should be OK. The
license of those plugins should be clear.
Best wishes
Julien
--------
Music was my first love and it will be my last (John Miles)
======== FIND MY WEB-PROJECT AT: ========
http://ltsb.sourceforge.net
the Linux TextBased Studio guide
======= AND MY PERSONAL PAGES AT: =======
http://www.juliencoder.de
1:23 p.m.
On Mon, Jun 21, 2010 at 12:13 PM, Victor Lazzarini
<Victor.Lazzarini(a)nuim.ie> wrote:
A simple question: can GPL plugins be loaded into
non-free hosts?
First off -- you can _do_ anything you like with a GPL plugin, the
question is whether you could legally redistribute it. Beyond that, I
don't think there is a single answer to this -- I think in practice it
would depend on whether the one thing (plugin or host) would be seen
by the reasonable person to be a derivative work of the other. If the
plugin only worked with a single host, or the plugin was necessary in
order to use the host, then it might be. If it used a well-defined
API supported by multiple hosts, perhaps predating either of the host
or plugin in question, then it probably wouldn't.
As a concrete example I think a GPL VST plugin would be perfectly
fine, provided of course that it used none of Steinberg's SDK code.
There are GPL'd VST hosts out there, so clearly the plugin does not
depend on a non-free host and can be happily distributed under the
GPL. What you choose to do with it once you've received it is up to
you -- the GPL only covers distribution -- so yes, I would think you
could indeed make, distribute, and use such a plugin.
Chris
1:34 p.m.
On Mon, Jun 21, 2010 at 1:23 PM, Chris Cannam
<cannam(a)all-day-breakfast.com> wrote:
On Mon, Jun 21, 2010 at 12:13 PM, Victor Lazzarini
<Victor.Lazzarini(a)nuim.ie> wrote:
Hello,
Wikipedia has interesting information about this topic, with the
differents opinions available on this particular topic. The main thing
it explains is that there's nothing sure about this :-/
http://en.wikipedia.org/wiki/GNU_General_Public_License#Linking_and_derived…
--
Lta.
A simple question: can GPL plugins be loaded into
non-free hosts?
First off -- you can _do_ anything you like with a GPL plugin, the
question is whether you could legally redistribute it. Beyond that, I
don't think there is a single answer to this -- I think in practice it
would depend on whether the one thing (plugin or host) would be seen
by the reasonable person to be a derivative work of the other. If the
plugin only worked with a single host, or the plugin was necessary in
order to use the host, then it might be. If it used a well-defined
API supported by multiple hosts, perhaps predating either of the host
or plugin in question, then it probably wouldn't.
As a concrete example I think a GPL VST plugin would be perfectly
fine, provided of course that it used none of Steinberg's SDK code.
There are GPL'd VST hosts out there, so clearly the plugin does not
depend on a non-free host and can be happily distributed under the
GPL. What you choose to do with it once you've received it is up to
you -- the GPL only covers distribution -- so yes, I would think you
could indeed make, distribute, and use such a plugin.
Chris
_______________________________________________ 
1:44 p.m.
On Mon, Jun 21, 2010 at 7:34 AM, Julien 'Lta' BALLET
<elthariel(a)gmail.com> wrote:
note that none of the discussions cited really covers the case that
matters for plugins. the key distinction is that plugin APIs generally
have a definition that is indepedent of any particular host. there are
exceptions for a few hosts that provide their own plugin API. but in
general, something like VST or LADSPA or AudioUnit or LV2 cannot be
said to be related to any host or plugin in particular.
This means that the host or plugin is undoubtedly a derived work of
the plugin **API**, but its very hard to argue that the host or plugin
is a derived work of the other, at least not when they are distributed
independently and the host shows no reliance of any kind on the
plugin. If you can load a plugin into Ardour and you can load the same
plugin into Logic, its pretty hard to argue that the plugin is a
derived work of Ardour or Logic. The most hosts a plugin can be loaded
into, the more clearly this lack of derivation becomes clear.
On the other hand, if you could only use a particular host if you have
a particular plugin available, and the host is distributed in a way so
as to automatically load that plugin, then I think that even if the
relationship between them is based on a 3rd party plugin API, one
could quite easily argue that the host is a derived work of the
plugin, in the FSF/GPL sense.
--p
1:34 p.m.
On Mon, Jun 21, 2010 at 7:13 AM, Victor Lazzarini
<Victor.Lazzarini(a)nuim.ie> wrote:
A simple question: can GPL plugins be loaded into
non-free hosts?
This may appear a stupid question, but given the fact that non-free code
can't link to GPL binaries, what is the story with dynamic modules?
RMS and others within the FSF would appear to like this to be a
complex question. It was always a gray area of GPL2, and originally
GPL3 was going to clear it up before Tivoization became the main focus
of GPL3.
Your question is often asked in reverse - can a GPL'ed host load
non-GPL'ed plugins, and I think that the answer here is extremely
straightforward: yes, if the plugin uses an API which is independent
of any particular host and only interacts with the host via that API.
But I think that in the direction that you asked it then I think its a
little more restrictive, with the same proviso that Chris offered: you
as a user of a GPL'ed plugin can do whatever you want with it,
including load it into a non-GPL host. However, I don't believe that
the developers and/or distributors of the host can arrange for this
happen in any "automatic" way, and would even be skirting a thin line
by packaging their host with GPL'd plugins that would be discovered
automatically.
--p
8:20 p.m.
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?
I see for instance that in the case of LinuxSampler, this would
clearly be a breach of license, because of the extra condition
attached relating to commercial software. But what about plain GPL?
Victor
On 21 Jun 2010, at 12:34, Paul Davis wrote:
But I think that in the direction that you asked it
then I think its a
little more restrictive, with the same proviso that Chris offered: you
as a user of a GPL'ed plugin can do whatever you want with it,
including load it into a non-GPL host. However, I don't believe that
the developers and/or distributors of the host can arrange for this
happen in any "automatic" way, and would even be skirting a thin line
by packaging their host with GPL'd plugins that would be discovered
automatically.
9:34 p.m.
On Mon, Jun 21, 2010 at 7:22 PM, Victor Lazzarini
<Victor.Lazzarini(a)nuim.ie> 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
10:10 p.m.
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
<Victor.Lazzarini(a)nuim.ie> 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
10:31 p.m.
On Mon, Jun 21, 2010 at 9:12 PM, Victor Lazzarini
<Victor.Lazzarini(a)nuim.ie> wrote:
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.
I would be uneasy about that last bit -- the fact that the host treats
this plugin differently from others. I think we're deep within a
genuine grey area here (an area that is both completely untested and
in which people's opinions differ) but I could well imagine an
argument being made on the basis of the interdependence of plugin and
host.
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.
If I were in this position, I think I would not feel comfortable
providing a GPL plugin.
That's probably about all I can say though, and one person's
ill-supported opinion probably isn't of much use.
Chris
22 Jun
22 Jun
3:08 a.m.
On Mon, Jun 21, 2010 at 10:12 PM, Victor Lazzarini
<Victor.Lazzarini(a)nuim.ie> wrote:
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.
Ok, again this is my personal, legally unqualified opinion, but it
would seem then that the LGPL might be perhaps the solution for your
case. Your plugin is still free software, open source, but the
licensee is allowed to link proprietary code to it and distribute it.
If you don't want anyone else than your clients to distribute your
plugin along proprietary code you can license it to them under the
LGPL and to the rest of the world under the GPL, as it is your right
as the copyright holder.
L
4:02 a.m.
Luis Garrido wrote:
Ok, again this is my personal, legally unqualified
opinion, but it
would seem then that the LGPL might be perhaps the solution for your
case.
Yes, but if Victor uses a GPL'd library for his plugin then the
combination of the plugin and the library would still be GPL'd. So that
doesn't make a difference in this case. Unless he can find an LGPL'd
replacement for the library, too.
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
21 Jun
21 Jun
9:47 p.m.
I don't think many of the list subscribers are lawyers. This is a
developer list, after all, so perhaps this is not the most reliable
place to get legal advice.
But I think what Paul is saying is the sensible thing: if the GPL
plugin is integral to the host functionality and loaded automatically,
any developer advising a jury will concur that the situation is in no
significant way different to dynamic linking at compile time. The host
is indeed a derivative work and thus should not be _distributed_
without providing its source code. You can use it in the machine you
have developed it, though, or in any other one as long as you copy
both the plugin and the host source code to it.
I guess if the host authors are bent on not contributing to the OSS
community with their source code, they could always try to contact the
plugin authors and get from them a proprietary license, which they are
entitled to provide as their copyright holders.
For instance, let's say someone writes an automatic accompaniment
generator and uses internally a GPL sampler to play it and render a
WAV version. I'd say that's derivative, since those features
contribute significantly to the product usefulness, and thus its
marketability. IANAL, but if I was asked by a jury that would be my
opinion.
L
10:16 p.m.
I am not expecting legal advice. I am a developer too, working
exclusively with Free software; I was never in a situation where I had
to check closely the GPL license, but I expect that someone here might
have had previous experience.
Victor
On 21 Jun 2010, at 20:47, Luis Garrido wrote:
I don't think many of the list subscribers are
lawyers. This is a
developer list, after all, so perhaps this is not the most reliable
place to get legal advice.
10:28 p.m.
On Mon, Jun 21, 2010 at 4:19 PM, Victor Lazzarini
<Victor.Lazzarini(a)nuim.ie> wrote:
I am not expecting legal advice. I am a developer too,
working exclusively
with Free software; I was never in a situation where I had to check closely
the GPL license, but I expect that someone here might have had previous
experience.
victor, i think that the real issue here is the extent to which the
host is completely usable without either version of the plugin. the
fact that there is a nonfree version of the plugin definitely
complicates matters though.
10:43 p.m.
That's easy to answer: it's usable producing a file as output. It
won't have means to play this file, for which it uses the plugin.
It could potentially use different plugins of the same architecture to
do the same thing. In fact, that's what is being done:
the non-free plugin gets the boot and a free one is used instead.
I guess this is not a decision for me. I can say what I will do,
explain the caveats and provide the software, if the customer agrees
to have it like that.
I think I have enough information now to pass on to whoever needs to
decide.
Thanks everyone for your responses.
Victor
On 21 Jun 2010, at 21:28, Paul Davis wrote:
On Mon, Jun 21, 2010 at 4:19 PM, Victor Lazzarini
<Victor.Lazzarini(a)nuim.ie> wrote:
I am not expecting legal advice. I am a developer
too, working
exclusively
with Free software; I was never in a situation where I had to check
closely
the GPL license, but I expect that someone here might have had
previous
experience.
victor, i think that the real issue here is the extent to which the
host is completely usable without either version of the plugin. the
fact that there is a nonfree version of the plugin definitely
complicates matters though.
22 Jun
22 Jun
2:21 a.m.
Victor Lazzarini 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?
Yes. IANAL and all that, but the GPL is very clear on that, see e.g.:
http://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF
In fact, library authors decidedly use the GPL (rather than the LGPL
which allows linking against proprietary software) to prevent
unsolicited use of their libraries in commercial software.
Of course, the vendor can always ask you and the author(s) of the 3rd
party library for a commercial license which allows it to distribute the
plugin with its commercial program. You can also put an exception into
your plugin license which specifically allows linking against the
commercial program, but you'd still have to ask the author(s) of the
GPL'd library for the same kind of permission.
HTH,
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
2:27 a.m.
On Mon, Jun 21, 2010 at 8:21 PM, Albert Graef <Dr.Graef(a)t-online.de> wrote:
Yes. IANAL and all that, but the GPL is very clear on
that, see e.g.:
http://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF
i would hardly call this "very clear"
-----------------------------------------------------------------------------------------------------
Can I release a non-free program that's designed to load a GPL-covered plug-in?
If [ ... ] ***WE BELIEVE*** they form a single program, which must be
treated as an extension of both the main program and the plug-ins. In
order to use the GPL-covered plug-ins, the main program must be
released under the GPL or a GPL-compatible free software license, and
that the terms of the GPL must be followed when the main program is
distributed for use with these plug-ins.
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***.
-------------------------------------------------------------------------------------------------
(emphasis added)
In fact, library authors decidedly use the GPL (rather
than the LGPL
which allows linking against proprietary software) to prevent
unsolicited use of their libraries in commercial software.
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. They do not supply an API, they use one.
plugins are derivatives of a plugin API (which may also be a library),
just as hosts might be. that doesn't make hosts derivatives of the
plugins, which is quite different to the situation where a program
(even a host) uses a library in a more traditional way.
maybe the mathematical formulation is: is derivation distributive? or
have i even forgotten that much of my high school math?
3:54 a.m.
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.
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(a)opensource.org, I believe
that this interpretation is right, or at least the one intended by the
FSF. 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.
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.
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
4:10 a.m.
On Mon, Jun 21, 2010 at 9:54 PM, Albert Graef <Dr.Graef(a)t-online.de> wrote:
Paul Davis wrote:
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.
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. 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(a)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
vendor who wants to distribute such a combination, I would either ask
the authors for explicit permission or seek legal advice.
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?
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. 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).
10:22 a.m.
Then there is the situation where you write a plugin using VST (and
its non-free license) and GPL. GPL should 'contaminate' the plugin
making it Free, but then Steinberg will come back at you for breaking
its license. Surely if you use GPL code, then you need to publish your
header files too.
Sorry, I did not mean to make this discussion longer than it needs to
be, but...
Victor
On 22 Jun 2010, at 03:10, Paul Davis wrote:
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?
10:32 a.m.
On Tue, Jun 22, 2010 at 9:24 AM, Victor Lazzarini
<Victor.Lazzarini(a)nuim.ie> wrote:
Then there is the situation where you write a plugin
using VST (and its
non-free license) and GPL. GPL should 'contaminate' the plugin making it
Free, but then Steinberg will come back at you for breaking its license.
Surely if you use GPL code, then you need to publish your header files too.
Sorry, I did not mean to make this discussion longer than it needs to be,
but...
I think that situation is simpler, and is just as you surmise -- you
can't redistribute a plugin that claims to be under the GPL if it uses
the VST SDK headers.
There _are_ some VST plugins out there that use the SDK but claim to
be under the GPL, and I think that is really borne of frustration with
the current impossibility of "doing it properly" because of the
restrictive license for the SDK headers (most painfully, the SDK
license's reverse-engineering clause effectively forbids publishing
source for a plugin that _doesn't_ use the SDK, if you have already
accepted the SDK license).
So I expect the view is that, so long as nobody with a stake in the
software objects to it, then at least the license has described what
the plugin's author would like to happen in an ideal world. It's a
grey-market situation. You wouldn't be able to include such a plugin
in a typical Linux distribution.
Chris
10:24 a.m.
On Tue, Jun 22, 2010 at 3:10 AM, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
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).
Exactly my view as well.
Chris
3:48 p.m.
On Monday 21 June 2010 22:10:23 Paul Davis wrote:
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).
Just fund the development of a simple app that used the api and gpl the thing.
drew
21 Jun
21 Jun
1:40 p.m.
On Mon, 21 Jun 2010, Victor Lazzarini wrote:
A simple question: can GPL plugins be loaded into
non-free hosts?
This may appear a stupid question, but given the fact that non-free code
can't link to GPL binaries, what is the story with dynamic modules?
This was discussed last year on this list, so it would be
worthwhile searching the archives. (Yes, I know that
searching LAD takes perseverence. :-))
According to the FSF,[1] the answer is no because it's
dynamic linking. BTW, I'm pretty sure their answer is
more black-and-white today than it was last year.
However, isn't this the whole point of using plugins?? To
allow this sort of thing? So, I think the FSF's opinion is
still up for debate. In addition, I doubt most plugin
authors will get upset with someone doing this.
Things get less cloudy if the plugin author(s) give special
permission for this (see, for example [2]).
Chris is also right: This is not an end-user issue. This
is a host author, plugin author, and software distributor
issue.
-gabriel
[1] http://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins
[2] http://gstreamer.freedesktop.org/documentation/licensing.html
Down toward the end where it mentions Totem's exception
for hosts, and again waaaay at the end where it mentions
the FSF.
1:50 p.m.
On Mon, 2010-06-21 at 06:40 -0500, Gabriel M. Beddingfield wrote:
On Mon, 21 Jun 2010, Victor Lazzarini wrote:
Subject: Re: [LAD] GPL Violation Alert! - update
X-OriginalArrivalTime: 05 Aug 2009 09:24:19.0886 (UTC)
FILETIME=[82F1D4E0:01CA15AE]
http://www.google.de/#hl=de&source=hp&q=Re%3A+[LAD]+GPL+Violation+A…on+Alert!
+-+update&aq=f&aqi=&aql=&oq=&gs_rfai=&fp=605bfc997273a220
A simple question: can GPL plugins be loaded into
non-free hosts?
This may appear a stupid question, but given the fact that non-free code
can't link to GPL binaries, what is the story with dynamic modules?
This was discussed last year on this list, so it would be
worthwhile searching the archives. (Yes, I know that
searching LAD takes perseverence. :-)) According to the FSF,[1] the answer is no because
it's
dynamic linking. BTW, I'm pretty sure their answer is
more black-and-white today than it was last year.
However, isn't this the whole point of using plugins?? To
allow this sort of thing? So, I think the FSF's opinion is
still up for debate. In addition, I doubt most plugin
authors will get upset with someone doing this.
Things get less cloudy if the plugin author(s) give special
permission for this (see, for example [2]).
Chris is also right: This is not an end-user issue. This
is a host author, plugin author, and software distributor
issue.
-gabriel
[1] http://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins
[2] http://gstreamer.freedesktop.org/documentation/licensing.html
Down toward the end where it mentions Totem's exception
for hosts, and again waaaay at the end where it mentions
the FSF.
3:44 p.m.
Hello,
in Denemo, which is GPL, (http://www.denemo.org) we had a similar problem. Our plugins are
scripted scheme code and scheme is just a language. So what about user scripts? Are they
just programs and the author can decide or are they GPL, too?
Since we are GNU we could ask the "bosses" directly :)
In our case Denemo exports special Scheme commands from C so you have to use them which
makes the scripts a derived work under GPL, which is nice because we don't need the
authors permission to include it in our website or integrate it in our
"mainline" command set.
The key here is that our plugins can only be run with one host, Denemo.
So this is an example the other way around, that the GPL (intends to/) covers plugins if
they are derived in a way that they are only runnable for a single host software.
Nils
On Mon, 21 Jun 2010 12:13:33 +0100
Victor Lazzarini <Victor.Lazzarini(a)nuim.ie> wrote:
A simple question: can GPL plugins be loaded into
non-free hosts?
This may appear a stupid question, but given the fact that non-free
code can't link to GPL binaries, what is the story with dynamic modules?
Thanks
Victor
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
5068
days inactive
5069
days old
linux-audio-dev@lists.linuxaudio.org
27 comments
11 participants
participants (11)
-
Albert Graef -
Chris Cannam -
drew Roberts -
Gabriel M. Beddingfield -
Julien 'Lta' BALLET -
Julien Claassen -
Luis Garrido -
Nils Hammerfest -
Paul Davis -
Ralf Mardorf -
Victor Lazzarini