[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [fluid-dev] Role of glib
From: |
josh |
Subject: |
Re: [fluid-dev] Role of glib |
Date: |
Fri, 28 Aug 2009 10:47:35 -0700 |
User-agent: |
Internet Messaging Program (IMP) H3 (4.1.6) |
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
Re: [fluid-dev] Role of glib, S. Christian Collins, 2009/08/26