Re: [fluid-dev] Role of glib

[josh]

Quoting David Henningsson <address@hidden>:
> > iPhone doesn't support shared libraries at all, from what I have heard.
> > So that means that FluidSynth and glib would
> > have to be copy pasted into another application, which would therefore
> > also have to be LGPL.
>
> I'm not a lawyer, but I guess that as long as you provide a way to
> update the LGPL code you would be fine.


I am also not a lawyer..

But I don't think your statement is quite right.  I've worked a bit  
with the LGPL and GPL, since for my work I do embedded systems  
projects using Linux.  It often comes up that we want to make use of  
an LGPL library.  A good portion of the LGPL is valid only when the  
work is considered publicly distributed.  So you could for example  
take LGPL code and do pretty much anything you like with it, as long  
as its just for your own use/amusement.

Some of the main points when you distribute it:
1. You need to provide an offer or way where the user can obtain the  
LGPL source code (including modifications, if any).

2. Dynamic linking is allowed between LGPL libraries and commercial  
applications (NOTE: not the case for GPL).

3. Static linking is allowed if you provide a method for the user to  
relink the commercial application with a possibly new/modified version  
of the LGPL library.  This could be accomplished by providing the  
object files for the commercial application.


Point #3 seems the most confusing to me and I wasn't really totally  
aware of it until now.  I had thought that static linking with a  
commercial application is not allowed.  It seems some libraries out  
there have added exceptions to the LGPL to clarify things and make  
static linking easier.

Perhaps we should consider adding some exceptions in the case of  
static linking, which would help in the embedded use case.  The  
question then becomes, how do we go about adding these changes?  Would  
we need to obtain permission from everyone in the AUTHORS file?  The  
copyright listed in most source files is "Peter Hanappe and others".   
Its cases like these, where it seems like it would be easiest if there  
was only 1 or a defined handful of people who owned the copyright.


> So we still have to live without lists/hashes/etc from glib inside the
> rendering engine? Or copy them from glib? I was actually thinking that
> glib could be a dependency of the rendering engine, but that does not
> solve the iPhone issue, of course.
>
> // David


I'm still somewhat undecided on this point.  I don't see a huge need  
for glib code use in the core, beyond some of the more basic data  
types, etc.  So perhaps we could try and provide fallbacks for the  
embedded FluidSynth case.  I doubt we will be maintaining 1.0.9 any  
further, so I'd like to make sure that FluidSynth continues to work on  
the same supported platforms (minus Mac OS 9).

I'm going to continue with this thinking for now.

Josh