[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fwd: [fluid-dev] Fluidsynth changes
From: |
Paul Millar |
Subject: |
Re: Fwd: [fluid-dev] Fluidsynth changes |
Date: |
Tue, 8 May 2007 23:34:25 +0100 |
User-agent: |
KMail/1.9.5 |
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