Re: [LAD] GPL Violation Alert! - Sorry if this is a duplicate

On Tue, Aug 4, 2009 at 11:37 AM, David Robillard<dave@email-addr-hidden> wrote:
> On Tue, 2009-08-04 at 10:10 +0200, Fons Adriaensen wrote:
>> On Tue, Aug 04, 2009 at 08:33:22AM +0100, Nick Bailey wrote:
>>
>> > Well, calling it your own is out of order, but as long as they release their
>> > source code as required by the GPL, then selling it is a Good Thing (TM). I
>> > hope the LADs agree with me. I would certainly be delighted if my GPL'd stuff
>> > (which isn't directly related to LAD) got sold. It would mean more GPL'd
>> > applications.
>>
>> Two question arise:
>>
>> - Is a program that loads LADSPA plugins (at run time) a
>>   'derived work' ? Note that anyone can create a 'clean'
>>   version of ladpsa.h, as some people did with the VST
>>   headers.
>
> GPL crosses the plugin barrier if they live in the same address space
> and call each other / share data, etc:
>
> http://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF

The FSF writes there:

"If the program dynamically links plug-ins, and they make function
calls to each other and share data structures, we believe they form a
single program, which must be treated as an extension of both the main
program and the plug-ins. "

Unfortunately, this merely continues the gray area.

   * LADSPA does not define any mechanism for the plugin make function
calls back to the host
   * Dynamic linking in almost all FSF writing seems to refer to
something that is contrasted with static linking. This does
          not usefully or meaningfully describe the use of dl_open().
   * The FSF is on crack if they believe that you can possibly call a
LADSPA host a derivative work of any number of LADSPA
          plugins unless the host automatically loads and uses those
plugins to provide non-optional functionality to the user.

I am still deeply disappointed that this issue, which has been around
for more than a decade, was not resolved in GPL v3. Its absurd that we
should still be debating this in 2009. The FSF needs to:

   (1) describe the differences between static linkage, dynamic
linkage and run-time linkage
   (2) cover the case where the "controlled interface" between
run-time linked code and the host is an API that is implemented by
several different applications, released under different licenses.
With their loosely worded claims, a plugin using the API is a
derivative of several different independent works. To claim that a VST
plugin is a derivative work of both Ardour, Cubase and Reaper is
clearly absurd. To claim that distributing said plugin with any of the
said hosts forms a single work is almost as absurd.

Their existing proposed "interface exception" is clearly written to
cover dynamic linkage. It also contains an assertion that is nothing
but an assertion at this time when applied to run time linkage:

"Linking ABC statically or dynamically with other modules is making a
combined work based on ABC"

FSF: define the lines! Its 2009, not 1989....

--p
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Wed Aug 5 16:15:07 2009