[fluid-dev] Re: Linking with GPL libraries (was: FluidSynth 1.0.9 released)

[Josh Green]

Hello David,

On Mon, 2009-04-13 at 15:21 +0200, David Henningsson wrote:
> > So not sure what that is all about.  Hmm, it just occurred to me.  It is
> > one thing to have your program link with a GPL library and its another
> > to have it in turn link with other programs, perhaps that is the
> > distinction?
> 
> The people we're messing it up for is not ourselves, it's for
> applications which links with libfluidsynth AND are not GPL-compatible
> (contains code released under MPL, a proprietary license etc). Assuming
> Debian links with readline/liblash by default, they must provide their
> own compiled version of libfluidsynth, which does not link with
> readline/liblash.
> 
> Anyway this is a "gotcha" that we should mention somewhere in the
> documentation.
> 


Ok, that makes sense.


> > Does anyone use LASH?  I would miss the readline support, that is for
> > sure.
> 
> As for readline, it could perhaps be replaced with editline, which is
> under BSD license.
> 

Just glancing at editline quickly, it seems like it could indeed be a
replacement.  I would like to resolve these issues, so using editline
seems like it could be a good task to accomplish for the next release.
I suppose another way to resolve the issue would be to not have
libfluidsynth link with libreadline, but be used only by the fluidsynth
command line shell.

> Looking it up in Debian (popcon) shows that:
> 104 people have installed lashd
> 688 people have installed liblash2
> 5790 people have installed libfluidsynth
> 


It seems like something like LASH would most benefit the community by
being LGPL or some other more open license, for the purpose it has.  I
wonder if the author can be persuaded to change it?  Otherwise, perhaps
we should just remove support for it.  It is optional though, so I can't
see particularly why it would be an issue just to leave the possibility
there, but a warning could be printed at ./configure time.


> >> Seems like a very good idea. I could also have use for some pointers to
> >> why it was decided to fork the project into an 2.x branch.
> 
> Sorry about the choice of words here, I meant branch, not fork (even
> though Wikipedia says that branching is a type of forking).
> 
> // David

I guess the distinction between branch and fork, is that a branch tends
to be something that contributes back to the original and visa versa,
where as a fork is more separate.  At least that has been my conception
of the terminology.

        Josh