Re: Fwd: [fluid-dev] Fluidsynth changes

[Paul Millar]

Hi Ken,

Of course IANAL, but naturally happy to share my opinion.

When talking about libLO, the website states:
"if you have a specific requirement for liblo in a close-source system then 
mail me and I may relicense it on an individual basis."

Would the libLO people be prepared to relicense liblo under LGPL specifically 
for use with fluidsynth?

On Tuesday 08 May 2007 03:40, Ken Restivo wrote:
> I can't imagine the license being a problem. Doesn't everyone love the GPL?
> :-)

Naturally, everyone loves the GPL ;-)

> Besides, lots of LPGL programs link with GPL programs.

Hmmm, after searching I've found one; but I wasn't aware this was common 
practise.

If an LGPL library (as LGPL-licensed code tends to be) links against 
GPL-licensed code then there is a risk the binaries would be considered 
a "derived work" of the GPL-licensed code.

The "risk" is because (to my knowledge) the concept of "derived work" when 
applied to software has never been tested in any court of law of any country.  
Until that happens, the best anyone can give you is a guess.

The opinions I've seen range from:

a.  all linking is mere aggregation, never forming derived works.
b.  statically linking creates a derived work, but dynamically linking does 
not.
c.  statically and dynamically linking creates derived works, but separate 
processes that communicate via IPCs do not.
d.  statically and dynamically linking creates derived works; "simple" 
intra-process IPC does not create derived works, but complex data-sharing 
IPCs may.

I've seen options a. and b. expressed, but don't give them much credence.  I 
believe c. is the most widely held opinion; except FSF who (I believe) 
anticipate that suitably complex IPC may result in a derived work (option d. 
above).

GPL licensed code requires that binaries of derived works be distributed under 
certain conditions.  If you adopt option c. or d. above, then fluidsynth 
linking against GPL licensed code will require the resulting libfluidsynth to 
be distributed under the GPL terms.

Moreover, as libfluidsynth would be governed by the GPL license, any programs 
that link against libfluidsynth would then have to abide by GPL terms too.


> IIRC, the typical approach is to make it optional at build time via a
> "./configure --disable-osc" flag, so that people who wanted to distribute
> fluidsynth without any GPL code (i.e. as part of some kind of proprietary
> product) could disable the liblo GPL linking. But IANAL, etc etc.


If code to link against GPL libraries is added to fluidsynth, then adding 
an --disable-osc flag will work.  But it should be properly documented; 
e.g. "by enabling OSC support, fluidsynth is GPL licensed".

Another possibility is to add a flag "--enable-gpl" to include *all* support 
that requires linking against GPL components.  The 
corresponding "--disable-gpl" would remove all GPL-licensed components.

HTH,

Paul.

pgpaB4rdtC_N9.pgp
Description: PGP signature