John Garrison wrote:
Note: I’ll use the term “non-free” to designate “proprietary”.
Which is the same for SDL. Statically linking LGPLed Hermes into a
LGPLed SDL shared library is okay, as the SDL shared library has to come
with sources. To statically link a proprietary program against both
Hermes and SDL is another thing completely, which can also be done in
the way you did with the various Loki ports.
So one could staticly link Hermes (and the other libs SDL requires)
into an SDL binary, then distribute that one library in a commercial
product?
Yes. The LGPL says that you can link non-free source code with the LGPL
code provided that there is a way for the user to modify the LGPL and
make the non-free source code use the modified LGPLed code.
You got that? Thus, LGPL code in a shared library is always safe to
link non-free code against (of course, modifications to the LGPL code
itself must be made public). There are a few ways to statically link
non-free code against LGPL code:
-
Make the .o for the non-free code available, enabling the user
to relink the application himself. The advantage is that it gives the
choice to the user of shared or static linking. The disadvantage is
that is makes reverse-engineering easier.
-
Make an alternative non-static binary of the non-free code. This is
what
Loki does to avoid the whole “requires this and that libraries”. The
problem would be when you have to be static to work (what cases?).
Note that the second way is nice, because it allows for making a package
that works right off the bat (thats why we want static-linking in the
first place for things like games), but also allows people who knows
enough about libraries to reduce the memory usage of the game (by using
the common shared libraries).
This is something I have been wondering because so many libraries depend
on other little libraries like libjpeg, etc. I’ve always wandered how
companies like Loki managed to not depend on those.
You can easily depend on LGPL libraries and even static link, as long as
you provide a way for the user to modify or replace the LGPL code.
Linking with GPL code is a whole other story.
And nowadays a lib like SDL can be built with or without support for some
things so just having SDL doesn’t mean you can run an SDL app. How do the
commercial companies out there make sure that the libs they include don’t
replace newer libs, but that the newer lib as all the features needed.
By statically linking, you’re avoiding a bunch of headaches to the
packager and the user, because the binary is self-contained (exception
could be made of things like configuration files, like Svgalib’s
libvga.config). You know that your game works with the exact library you
linked with, so statically linking brings that very same library to the
user.
Providing a dynamically linked binary allows the user to use updated
version of libraries and/or modify those libraries, to counter bugs in
them for example.
Quake 3 I think it is has a lib (mesa?) in it’s directory. Do they just
dynamically load their own shipped version of a full featured lib that has
had it’s dependants statically linked? If so will ld automatically load
the lib from the directory instead of from /usr/lib?
The Mesa library that comes with Quake 3 is dynamically linked itself,
but the library is dynamically loaded (with dlopen instead of at link
time) with quake3.bin, but this is to provide a feature, not to satisfy
licensing.
I think dlopen uses /etc/ld.so.conf (hence /usr/lib) to find its
libraries, but specifying a path will make it look there instead, which
is what the quake3 script does.
Sorry for all these newbie-esque questions. I’ve just always dealt with
dynamic libs and never really worried much about dependancies until now.
I hope to offer binaries of my PowerPak lib sometime soon (escpecially
with BeOS becoming free sometime in this Quarter) and would like to
statically link the required libs so PowerPak users don’t need to
download lots of stuff. (with dynamic linked versions available as well
of course for those that have the libs and want to save space) PowerPak
being LPGL’d though brings issues though if someone were to release a
non-free project that links with only the statically built PowerPak
library. I just want to be sure to know all the aspects of the license
I am releasing my work under.
That’s okay (for the newbie-esque questions)! 
If PowerPak is LGPL and doesn’t use GPL libraries, you can safely
statically link dependent libraries into the shared library. Being a
LGPL code, the user already has a way to make PowerPak use modified
versions of the dependent libraries, by downloading the source and
recompiling!
The only time the licensing comes into play is when you introduce
proprietary code into the equation, and that’s the problem of the owner
of that proprietary code.
Also, the GPL is allergic to anything proprietary, period. Did you know
that you cannot distribute a binary of a GPL game that is linked against
proprietary OpenGL libraries (for example, the SGI or Windows OpenGL)?
I’m not completely sure, but the license is so obtuse that it is
possible that this could even stop you from releasing source code that
has to deal with WGL!!!
You can only distribute GPL source code in complete, working order, and
it can only depend on either libraries with licenses compatible with the
GPL (http://www.gnu.org/philosophy/license-list.html, very short list!).
Conclusion:
LGPL -> practical
GPL -> ethical–
Pierre Phaneuf
Ludus Design, http://ludusdesign.com/