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.
pgpEOR892FJkB.pgp
Description: PGP signature
_______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
