Hello,
By default, SDL’s configure process will enable esound support if it is
available on the host system. Esound is a GPL library. I’m confused as to
what this does to the legal status of SDL and the programs linked with
it…is it true that they are all now subject to the GPL?
This seems like a boobytrap. Perhaps esound support should be
disabled by default in configure?
Thanks,
By default, SDL’s configure process will enable esound support if it is
available on the host system. Esound is a GPL library. I’m confused as to
what this does to the legal status of SDL and the programs linked with
it…is it true that they are all now subject to the GPL?
Hi,
You sound to be a victim of some anti-GPL FUD. 
SDL is distributed under the terms of the LGPL, so it makes no problem
to link it with Esound. SDL being distributed under the terms of the
LGPL, you do NOT have the obligation to distribute programs linking to
SDL under the terms of a Free licence (although you are encouraged to do
so). What you can/can’t do with GPL/LGPL is too long to be explained in
one paragraph. Moreover I fear this is a bit offtopic here. The best
thing I can suggest you to do is to go to http://www.gnu.org and read
the terms of both licences. They are not too long, easily understandable
But to be short: GPL and LGPL have not be designed to restrict your
rights as other software licences, but on the contrary to protect them.
All you can be sure is that it doesn’t hurt to link proprietary programs
to SDL (Loki did it a thousand times anyway).
Alex.–
http://www.gnurou.org
This seems like a boobytrap. Perhaps esound support should be
disabled by default in configure?
Esound is dual-licensed under the GPL and LGPL. At least, there’s two
files: “COPYING” (with GPL text) and COPYING.LIB (with LGPL text) in the
source distribution.
No worries here, I would say.
–ryan.
Es schrieb “Ryan C. Gordon”:
This seems like a boobytrap. Perhaps esound support should be
disabled by default in configure?Esound is dual-licensed under the GPL and LGPL. At least, there’s two
files: “COPYING” (with GPL text) and COPYING.LIB (with LGPL text) in the
source distribution.No worries here, I would say.
and the real code (that one wants to be protected) is in the server
and not the client. That will well fit onto the fuzzy thing that
can be read in the GPL faq - to have a loose dependency that one
can characterize as “at arms length”…
Firstly, let me reference /usr/share/doc/libesd-alsa0/copyright on my
system:
The software in this package falls into several categories, and is
licensed under either the Gnu GPL or Gnu LGPL as appropriate:
The Enlightened Sound Daemon (esd) - GPL
The Enlightened Sound Daemon Client Library (libesd.so, libesd.a) - LGPL
The ESD-DSP wrapper script and support library (esddsp, libesddsp.so) -
LGPL
The Example programs and command line utilities - LGPL
libesd itself is LGPL. This is quite safe for you to use with SDL even if
your code is not GPL, since all it does is talk to a server over a socket.
Even if the library were GPL, SDL could still load it at runtime (which it
can do now if told to do so, actually) without harming the license on your
code. Richard Stallman would love to find a way to make this against the
GPL somehow, but the text of the GPL itself says that it only applies to
copying the program. The difference between runtime binding and dynamic
linking is the key here. One falls within the bounds of Copyright, the
other does not. The gory details of how are not appropriate for this
list, though.On Sat, Apr 27, 2002 at 11:23:48AM -0700, John Quigley wrote:
By default, SDL’s configure process will enable esound support if it is
available on the host system. Esound is a GPL library. I’m confused as to
what this does to the legal status of SDL and the programs linked with
it…is it true that they are all now subject to the GPL?This seems like a boobytrap. Perhaps esound support should be
disabled by default in configure?
–
Joseph Carter Don’t feed the sigs
that’s IT. I’m never fucking attempting to install redhat
again.
this is like the 10th fucking machine on which the installer has
imploded immediately after I went through the hell of their
package selection process.
Sammy: just use debian and never look back
timball: debian iso’s are being written at this very moment.
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020427/7083be22/attachment.pgp
You sound to be a victim of some anti-GPL FUD.
You’re a victim of not reading the EsounD license.
SDL is distributed under the terms of the LGPL, so it makes no problem
to link it with Esound. SDL being distributed under the terms of the
LGPL, you do NOT have the obligation to distribute programs linking to
SDL under the terms of a Free licence (although you are encouraged to do
so). What you can/can’t do with GPL/LGPL is too long to be explained in
one paragraph. Moreover I fear this is a bit offtopic here. The best
thing I can suggest you to do is to go to http://www.gnu.org and read
the terms of both licences. They are not too long, easily understandable
- the exact contrary of what you would expect from a software licence
Er, this almost makes sense. Your conclusion is right, but the reasoning
is a little off. SDL’s impelementation supporting numerous backends, most
of which are usable under the LGPL (if not all - I haven’t checked out the
license of everything SDL supports to be sure), there’s no potential
problem. It is theoretically possible for a platform to exist where it
can be argued that any binary of a program under a given license is legal
to use.
None exist that I know of, but if Microsoft takes their current campaign
to the next level, future versions of Windows may prohibit people to make
GPL applications for Windows. Conversely, I would be surprised if RMS
does not at some point tell us that his lawyers say a completely GPL’d
operating system (like the HURD) may outright prohibit any software which
is not compatible with the GPL. I doubt he could afford the political
backlash of such a statement right now, but if he gets a chance, he might
well take it. This makes two platforms you shouldn’t be dependant on if
you value the right to license your software as you wish, for completely
different reasons.
(Anyone who feels obligated to tell me how I’m reading either MS or FSF
totally wrong, please do so off-list. I’m citing potential examples here
which I deem feasable…)
But to be short: GPL and LGPL have not be designed to restrict your
rights as other software licences, but on the contrary to protect them.
All you can be sure is that it doesn’t hurt to link proprietary programs
to SDL (Loki did it a thousand times anyway).
They haven’t? The GPL is designed specifically to force people to release
their own code under the same license. That license may give you lots of
permission to do things “traditional” licenses don’t, but it still exists
to make sure that you only do things the person who wrote the software
wants done with it. To some extent, this applies to all licenses. In the
GPL’s case, that goal is to create as much GPL’d software as possible.
This shouldn’t be a surprise, nor necessarily a bad thing, given the FSF’s
stated belief that non-free software is unethical and must be eradicated,
and goal to do precisely that.
As for Loki, they linked SDL statically to most of their programs, which
would normally have been quite against the license. However, licenses
need not necessarily apply to everyone. I’m sure of you paid Sam enough
he might give you permission to do the same - or not pay him, as the case
of Loki seems to have turned out. =/ But that’s even FURTHER off topic!On Sat, Apr 27, 2002 at 08:41:35PM +0200, Alexandre Courbot wrote:
–
Joseph Carter Sanity is counterproductive
// Minor lesson: don’t fuck about with something you don’t fully understand
– the dosdoom source code
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020427/103c34d9/attachment.pgp
As for Loki, they linked SDL statically to most of their programs, which
would normally have been quite against the license.
It actually isn’t. If you look carefully, you’ll see that Loki distributed
two binaries, one statically linked and officially supported, and one
dynamically linked, and unsupported. This gives the best of both worlds.
You don’t have to support untested combinations of code, and the end user
can customize his version of SDL to his heart’s content, complying with the
LGPL license.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
This is clever, and preserves the spirit of the LGPL, however it seems like
the static binary does technically violate the LGPL. I’m striving for a
practical solution with no violations…maybe it doesn’t exist.
One solution I was thinking about was to distribute a dynamic binary, and
also a subdirectory containing most of the libraries it depends on. You run
the binary with a shell script that sets the library path and then runs the
dynamic binary. This works for all libraries except glibc, the end user will
have to have the right version of that installed (and I hope that future
versions will be backwards compatible).
BTW, thanks to everybody for the enlightening responses about the
enlightenment sound daemon, it seems like libesd.so is LGPL so I can relax.On Sunday 28 April 2002 09:31 am, you wrote:
As for Loki, they linked SDL statically to most of their programs, which
would normally have been quite against the license.It actually isn’t. If you look carefully, you’ll see that Loki distributed
two binaries, one statically linked and officially supported, and one
dynamically linked, and unsupported. This gives the best of both worlds.
You don’t have to support untested combinations of code, and the end user
can customize his version of SDL to his heart’s content, complying with the
LGPL license.
On linux, the fully statically linked version of my SDL-using binary crashes
when it tries to use SDL_GL_LoadLibrary on NVIDIA’s libGL.so. I think this
is a problem with glibc2.2.4 or NVIDIA’s library, not SDL, but I want to see
if anyone here had encounted the problem or knew how to fix it.
The NVIDIA readme mentions problems with the dynamic linker, but it claims
that the problems are fixed in the version I’m using (glibc 2.2.4). It
suggests setting the __GL_SINGLE_THREADED environment variable, but that
makes my program crash too. I build on redhat (7.2), but it doesn’t work on
gentoo either.
The following simple program reproduces the problem. If you save it in a
file called “linktest.c” and compile it with “gcc -o linktest linktest.c
-ldl”, it will work. If you compile it with “gcc -o linktest linktest.c
-static -ldl” it will crash.
#include <stdio.h>
#include <dlfcn.h>
int main()
{
void* dlHandle = dlopen(“libGL.so”, RTLD_NOW);
if (dlHandle != NULL)
{
printf(“opened lib\n”);
dlclose(dlHandle);
}
else
printf(“couldn’t open lib\n”);
return 0;
}
The following simple program reproduces the problem. If you save it in a
file called “linktest.c” and compile it with “gcc -o linktest linktest.c
-ldl”, it will work. If you compile it with “gcc -o linktest linktest.c
-static -ldl” it will crash.
You can’t dynamically load code in completely statically linked programs.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
So is there some trick to the way that, for example, “tribes2” was built?
ldd says that it is “not a dynamic executable”, but it must be
dynamically loading libGL.so…On Sunday 28 April 2002 12:28 pm, Sam Lantinga wrote:
The following simple program reproduces the problem. If you save it in a
file called “linktest.c” and compile it with “gcc -o linktest linktest.c
-ldl”, it will work. If you compile it with “gcc -o linktest linktest.c
-static -ldl” it will crash.You can’t dynamically load code in completely statically linked programs.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
So is there some trick to the way that, for example, “tribes2” was built?
ldd says that it is “not a dynamic executable”, but it must be
dynamically loading libGL.so…
tribes2 is a 2D game launcher shell. The 3D binary is (if I remember correctly)
tribes2.bin
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
“t2launch” is the 2d launcher, and “tribes2” is the 3d binary.
Interestingly, although ldd says it is not dynamic, file says:
“tribes2: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically
linked (uses shared libs), stripped”
Whereas file on my static executable says it is statically linked. So
tribes2 is actually a dynamic exe, it just doesn’t link against anything
dynamically. What I wouldn’t give to see the command line that built it… :)On Sunday 28 April 2002 12:48 pm, you wrote:
So is there some trick to the way that, for example, “tribes2” was built?
ldd says that it is “not a dynamic executable”, but it must be
dynamically loading libGL.so…tribes2 is a 2D game launcher shell. The 3D binary is (if I remember
correctly) tribes2.binSee ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
One solution I was thinking about was to distribute a dynamic binary, and
also a subdirectory containing most of the libraries it depends on. You run
the binary with a shell script that sets the library path and then runs the
dynamic binary. This works for all libraries except glibc, the end user will
have to have the right version of that installed (and I hope that future
versions will be backwards compatible).
If I may make a suggestion:
knghtbrd at galen:~$ unzip -l foo_0.1.0_win32.zip
Archive: foo_0.1.0_win32.zip
Length Date Time Name
0 04-28-02 15:01 foo-0.1.0/
289143 04-28-02 15:01 foo-0.1.0/foo.exe
225280 04-28-02 15:01 foo-0.1.0/SDL.dll
:
575 04-28-02 15:01 foo-0.1.0/AUTHORS.txt
17992 04-28-02 15:01 foo-0.1.0/COPYING.txt
521 04-28-02 15:01 foo-0.1.0/README-source.txt
:
This is my preferred distribution method for win32. The libs you need are
included, along with a README-source.txt, which should tell you precisely
where to get the source code for everything.
In the case of SDL (and everything else really), I suggest that the
information in README-source points to pages on your own website which
contain the exact versions of the source code used for the included
libraries, as well as a link to the upstream website where newer versions
may be found.
BTW, thanks to everybody for the enlightening responses about the
enlightenment sound daemon, it seems like libesd.so is LGPL so I can relax.
I still think your original assessment (that SDL should build without esd
support by default) is valid - but only because EsounD sucks and we all
know it. =)On Sun, Apr 28, 2002 at 11:58:14AM -0700, John Quigley wrote:
–
Joseph Carter No conceit in my family
<Culus_> We are also hoping to release a version of linux where shell is
replaced by perl to a large degree. Adding to that, there are a
few of us who would like to see a pure perl platform… PerlOS 
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020428/cbc06cde/attachment.pgp
This actually wasn’t true of every game Loki released. I’d have to find which
ones weren’t. But there were a few Loki titles released with a static linked
only binary.
-EvilTypeGuyOn Sun, Apr 28, 2002 at 09:31:04AM -0700, Sam Lantinga wrote:
As for Loki, they linked SDL statically to most of their programs, which
would normally have been quite against the license.It actually isn’t. If you look carefully, you’ll see that Loki distributed
two binaries, one statically linked and officially supported, and one
dynamically linked, and unsupported. This gives the best of both worlds.
Whereas file on my static executable says it is statically linked. So
tribes2 is actually a dynamic exe, it just doesn’t link against anything
dynamically. What I wouldn’t give to see the command line that built it…
Use readelf -a on the binaries to see what it is linked to. ldd says “not
a dynamic executable” due to the tribes2 binary being brandelf’d.
Steven FullerOn Sun, 28 Apr 2002, John Quigley wrote:
Ryan,
I have added a quicktime decoder which can play back some quicktime
formats (.mov) and also update the CodeWarrior and ProjectBuilder
projects to use mpglib. There are a few small changes for mpglib. I
originally wrote the quicktime decoder to play mp3 but I found it wasn’t
possible with this method. But it can play other formats so maybe it is
useful to some people. I tested on Mac OS 9 and mpglib seems to work
great!
http://icdweb.cc.purdue.edu/~walisser/sdl/SDL_sound.tar.gz
Cheers,
DarrellOn Saturday, April 27, 2002, at 03:51 PM, Ryan C. Gordon wrote:
This seems like a boobytrap. Perhaps esound support should be
disabled by default in configure?Esound is dual-licensed under the GPL and LGPL. At least, there’s two
files: “COPYING” (with GPL text) and COPYING.LIB (with LGPL text) in the
source distribution.No worries here, I would say.
–ryan.
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
I have added a quicktime decoder which can play back some quicktime
formats (.mov) and also update the CodeWarrior and ProjectBuilder
projects to use mpglib. There are a few small changes for mpglib. I
originally wrote the quicktime decoder to play mp3 but I found it wasn’t
possible with this method. But it can play other formats so maybe it is
useful to some people. I tested on Mac OS 9 and mpglib seems to work
great!
Darrell:
You kick massive butt! Thanks!
–ryan.
Yes, and they were later patched to include the dynamic binary.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment> On Sun, Apr 28, 2002 at 09:31:04AM -0700, Sam Lantinga wrote:
As for Loki, they linked SDL statically to most of their programs, which
would normally have been quite against the license.It actually isn’t. If you look carefully, you’ll see that Loki distributed
two binaries, one statically linked and officially supported, and one
dynamically linked, and unsupported. This gives the best of both worlds.
This actually wasn’t true of every game Loki released. I’d have to find which
ones weren’t. But there were a few Loki titles released with a static linked
only binary.
As for Loki, they linked SDL statically to most of their programs, which
would normally have been quite against the license. However, licenses
need not necessarily apply to everyone.
Actually, that was just mentioned on this list a week or so ago. Loki
also released runtime linking binaries, to satisfy the license. The
static was just for convienence and stability.
Which IMHO is a fantastic idea, and I intend to do.
I’m sure of you paid Sam enough> he might give you permission to do the same - or not pay him, as the case
of Loki seems to have turned out. =/ But that’s even FURTHER off topic!
–
Joseph Carter Sanity is counterproductive// Minor lesson: don’t fuck about with something you don’t fully understand
– the dosdoom source code
–
End of Rant.
Jimmy
Jimmy’s World (http://www.jimmysworld.org)
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: This is a digitally signed message part
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020506/b757fcfc/attachment.pgp