SDL_Sound license

Hi there, thanks to everyone on the list, I’ve learned a lot from reading.

Myself and some friends are working on a 2D scroller game using SDL, and
currently trying to decide what to use for sound. SDL_Sound seems the obvious
choice, and we’d like to use it, but we’re not too sure what the GPL Lesser
license entails.

I made the best sense I could of it, and I think we’d fall under subsection 6,
where our game would have SDL_Sound compiled into the executables. Does this
mean that we have to make our game code available open source, or just that we
have to make sure the end user is notified and has access to the SDL_Sound
libraries? If it were possible to just use an SDL_Sound dll to keep it
totally separate we would opt for this in an effort to fall under subsection
5, but I wasn’t able to find anything on a dll (I’m not too familiar with
dll’s in the first place, so maybe I’m missing something obvious).

Thank you.

-Patrick Tuckey

Myself and some friends are working on a 2D scroller game using SDL, and
currently trying to decide what to use for sound. SDL_Sound seems the obvious
choice, and we’d like to use it, but we’re not too sure what the GPL Lesser
license entails.

SDL_sound falls under the same license as SDL. I’m not sure why one is a
concern for you when the other isn’t.

–ryan.

I made the best sense I could of it, and I think we’d fall under subsection 6,
where our game would have SDL_Sound compiled into the executables. Does this
mean that we have to make our game code available open source, or just that we
have to make sure the end user is notified and has access to the SDL_Sound
libraries? If it were possible to just use an SDL_Sound dll to keep it
totally separate we would opt for this in an effort to fall under subsection
5, but I wasn’t able to find anything on a dll (I’m not too familiar with
dll’s in the first place, so maybe I’m missing something obvious).

To answer the question, build SDL_sound as a DLL (only source is
distributed, but you can compile it or find someone else who has done
so), and put it in the same folder as your game. Link your game against
that, proceed as normal.

If you make any changes to SDL_sound itself, send them to me for
inclusion in the main codebase. You don’t have to open source your
software if you do these things (but you are certainly welcome to, of
course).

Bottom line: don’t statically link SDL_sound, and don’t take snippets of
code from it to put into your closed source program…everything else is
basically okay.

SDL itself falls under these same guidelines. The license seems
daunting, but it’s pretty simple, overall.

–ryan.

Okay, of course. Obvious.
Thanks Ryan.>===== Original Message From “Ryan C. Gordon”

Myself and some friends are working on a 2D scroller game using SDL, and
currently trying to decide what to use for sound. SDL_Sound seems the
obvious

choice, and we’d like to use it, but we’re not too sure what the GPL Lesser
license entails.

SDL_sound falls under the same license as SDL. I’m not sure why one is a
concern for you when the other isn’t.

–ryan.


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Ah, right, I knew there was a reason I was thinking SDL_Sound was different
than SDL, but I couldn’t think of it when you replied to my first message.
This clears it up for me, thanks again.>

To answer the question, build SDL_sound as a DLL (only source is
distributed, but you can compile it or find someone else who has done
so), and put it in the same folder as your game. Link your game against
that, proceed as normal.

If you make any changes to SDL_sound itself, send them to me for
inclusion in the main codebase. You don’t have to open source your
software if you do these things (but you are certainly welcome to, of
course).

Bottom line: don’t statically link SDL_sound, and don’t take snippets of
code from it to put into your closed source program…everything else is
basically okay.

SDL itself falls under these same guidelines. The license seems
daunting, but it’s pretty simple, overall.

–ryan.


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

No! Using SDL_Sound is not different from SDL: they both use the
LGPL, and thus neither can be statically linked (“compiled in”) to a
program without a compatible license.

-MicahOn Wed, Oct 15, 2003 at 09:47:39AM -0700, Patrick Tuckey wrote:

Ah, right, I knew there was a reason I was thinking SDL_Sound was different
than SDL, but I couldn’t think of it when you replied to my first message.
This clears it up for me, thanks again.

To answer the question, build SDL_sound as a DLL (only source is
distributed, but you can compile it or find someone else who has done
so), and put it in the same folder as your game. Link your game against
that, proceed as normal.

If you make any changes to SDL_sound itself, send them to me for
inclusion in the main codebase. You don’t have to open source your
software if you do these things (but you are certainly welcome to, of
course).

Bottom line: don’t statically link SDL_sound, and don’t take snippets of
code from it to put into your closed source program…everything else is
basically okay.

SDL itself falls under these same guidelines. The license seems
daunting, but it’s pretty simple, overall.

–ryan.

I made the best sense I could of it, and I think we’d fall under subsection 6,
where our game would have SDL_Sound compiled into the executables. Does this
mean that we have to make our game code available open source, or just that we
have to make sure the end user is notified and has access to the SDL_Sound
libraries? If it were possible to just use an SDL_Sound dll to keep it
totally separate we would opt for this in an effort to fall under subsection
5, but I wasn’t able to find anything on a dll (I’m not too familiar with
dll’s in the first place, so maybe I’m missing something obvious).

To answer the question, build SDL_sound as a DLL (only source is
distributed, but you can compile it or find someone else who has done
so), and put it in the same folder as your game. Link your game against
that, proceed as normal.

If you make any changes to SDL_sound itself, send them to me for
inclusion in the main codebase. You don’t have to open source your
software if you do these things (but you are certainly welcome to, of
course).

Bottom line: don’t statically link SDL_sound, and don’t take snippets of
code from it to put into your closed source program…everything else is
basically okay.

As I understand the LGPL you can statically link the code so long as
you provide object files so that the end user can also statically link
the code. The idea is that the end use has to have the same rights that
you have.

	Bob PendletonOn Wed, 2003-10-15 at 11:39, Ryan C. Gordon wrote:

SDL itself falls under these same guidelines. The license seems
daunting, but it’s pretty simple, overall.

–ryan.


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

±----------------------------------+

Bob,
Please forgive my ignorance, but what does ‘object file’ correspond to in
the Windows world?
Do you mean that if I statically compile SDL into my program, in addition to
the program, I need to toss the SDL.dll somewhere for them to use if they
want?
Thanks,
Jason.> ----- Original Message -----

From: sdl-admin@libsdl.org [mailto:sdl-admin at libsdl.org]On Behalf Of Bob
Pendleton
Sent: Wednesday, October 15, 2003 11:49 AM
To: SDL Mailing List
Subject: Re: [SDL] SDL_Sound license

On Wed, 2003-10-15 at 11:39, Ryan C. Gordon wrote:

I made the best sense I could of it, and I think we’d fall under
subsection 6,

where our game would have SDL_Sound compiled into the executables. Does
this

mean that we have to make our game code available open source, or just
that we

have to make sure the end user is notified and has access to the
SDL_Sound

libraries? If it were possible to just use an SDL_Sound dll to keep it
totally separate we would opt for this in an effort to fall under
subsection

5, but I wasn’t able to find anything on a dll (I’m not too familiar
with

dll’s in the first place, so maybe I’m missing something obvious).

To answer the question, build SDL_sound as a DLL (only source is
distributed, but you can compile it or find someone else who has done
so), and put it in the same folder as your game. Link your game against
that, proceed as normal.

If you make any changes to SDL_sound itself, send them to me for
inclusion in the main codebase. You don’t have to open source your
software if you do these things (but you are certainly welcome to, of
course).

Bottom line: don’t statically link SDL_sound, and don’t take snippets of
code from it to put into your closed source program…everything else is
basically okay.

As I understand the LGPL you can statically link the code so long as
you provide object files so that the end user can also statically link
the code. The idea is that the end use has to have the same rights that
you have.

  Bob Pendleton

SDL itself falls under these same guidelines. The license seems
daunting, but it’s pretty simple, overall.

–ryan.


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

±----------------------------------+


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Okay, so…I think I’ve got this now, but I want to make sure. If I create a
.dll or use a .dll that someone else made from SDL_Sound, and then my program
requires the .dll to run but does not use any of the code itself, I am not
under any obligations? (apart from crediting the use of the library). I
thought that this was how SDL itself works (I am using the .dll for SDL).

I think it’s likely that we’ll make the source available, but we haven’t made
any decisions yet, so we’re still trying to educate ourselves on the different
options.

Thanks again :slight_smile:

p.s. I know this seems like a ridiculous question, but would someone be so
kind as to tell me what my subject line should read if I wish this email to
show up as a sub-thread? I tried putting “RE:” in front of the [SDL] in the
past, but I don’t think it worked. Merci.>===== Original Message From “Micah J. Cowan” =====

No! Using SDL_Sound is not different from SDL: they both use the
LGPL, and thus neither can be statically linked (“compiled in”) to a
program without a compatible license.

-Micah

On Wed, Oct 15, 2003 at 09:47:39AM -0700, Patrick Tuckey wrote:

Ah, right, I knew there was a reason I was thinking SDL_Sound was different
than SDL, but I couldn’t think of it when you replied to my first message.
This clears it up for me, thanks again.

To answer the question, build SDL_sound as a DLL (only source is
distributed, but you can compile it or find someone else who has done
so), and put it in the same folder as your game. Link your game against
that, proceed as normal.

If you make any changes to SDL_sound itself, send them to me for
inclusion in the main codebase. You don’t have to open source your
software if you do these things (but you are certainly welcome to, of
course).

Bottom line: don’t statically link SDL_sound, and don’t take snippets of
code from it to put into your closed source program…everything else is
basically okay.

SDL itself falls under these same guidelines. The license seems
daunting, but it’s pretty simple, overall.

–ryan.


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

At 12:14 PM 15/10/2003 -0700, you wrote:

Bob,
Please forgive my ignorance, but what does ‘object file’ correspond to in
the Windows world?
Do you mean that if I statically compile SDL into my program, in addition to
the program, I need to toss the SDL.dll somewhere for them to use if they
want?

In MSVC a static library would be SDL.lib or under mingw it would be
SDL.a. I think basically you cant just compile the SDL code direct into
your executable (unless you are using for your final program the GPL, and
maybe the same for LGPL as well), you have to compile SDL into its own
static/dynamic library and provide that object file with it. Though IIRC,
providing a link to the SDL website (which has such files on it and the
original source) might satisfy the terms.

Neil.

Usually mail clients throw headers like these in:

In-Reply-To:
Message-ID: <20031015214611.8848484 at blah.blah.blah>
References:

…which other mailers (like Mutt, which threads) and mailing list archivers
use to figure out threads.

-bill!On Wed, Oct 15, 2003 at 12:10:38PM -0700, Patrick Tuckey wrote:

p.s. I know this seems like a ridiculous question, but would someone be so
kind as to tell me what my subject line should read if I wish this email to
show up as a sub-thread? I tried putting “RE:” in front of the [SDL] in the
past, but I don’t think it worked. Merci.

A rule of thumb I always think of when it comes to the LGPL is:

If a new version of the SDL library comes out, will the user be able to
use it with my binary application. If the answer is no, then you’re not
abiding by the rules of LGPL.

Possibly solutions to this are as follows:

  1. Make the dependency on SDL be dynamic. So if the user replaces the
    provided SDL.dll with their own, your binary application will continue to
    function and use the new features in the updated library (assuming of
    course that the new dll is binary compatible with the old dll).

  2. Make the dependency on SDL be static, and provide object files that
    can be used to recreate the application.

So the main thing to remember is that the user MUST be able to use a new
version of the libraries with your binary application.

Note that while this may not be a sufficient to satisfy LGPL, it is
definitely necessary.

SteveOn Wednesday 15 October 2003 05:13 pm, Neil Brown wrote:

At 12:14 PM 15/10/2003 -0700, you wrote:

Bob,
Please forgive my ignorance, but what does ‘object file’ correspond to
in the Windows world?
Do you mean that if I statically compile SDL into my program, in
addition to the program, I need to toss the SDL.dll somewhere for
them to use if they want?

In MSVC a static library would be SDL.lib or under mingw it would be
SDL.a. I think basically you cant just compile the SDL code direct
into your executable (unless you are using for your final program the
GPL, and maybe the same for LGPL as well), you have to compile SDL into
its own static/dynamic library and provide that object file with it.
Though IIRC, providing a link to the SDL website (which has such files
on it and the original source) might satisfy the terms.

Bob,
Please forgive my ignorance, but what does ‘object file’ correspond to in
the Windows world?

The output of the compiler that you link together to form a program.
What is that called in the Windows world now days? It was called an
object file under DOS and under Windows when I did Windows work.

Do you mean that if I statically compile SDL into my program, in addition to
the program, I need to toss the SDL.dll somewhere for them to use if they
want?

No, if you use a .dll then you are not statically linking, right? What I
said only applies if you don’t use a .dll.

	Bob PendletonOn Wed, 2003-10-15 at 14:14, Jason Clark wrote:

Thanks,
Jason.

-----Original Message-----
From: sdl-admin at libsdl.org [mailto:sdl-admin at libsdl.org]On Behalf Of Bob
Pendleton
Sent: Wednesday, October 15, 2003 11:49 AM
To: SDL Mailing List
Subject: Re: [SDL] SDL_Sound license

On Wed, 2003-10-15 at 11:39, Ryan C. Gordon wrote:

I made the best sense I could of it, and I think we’d fall under
subsection 6,

where our game would have SDL_Sound compiled into the executables. Does
this

mean that we have to make our game code available open source, or just
that we

have to make sure the end user is notified and has access to the
SDL_Sound

libraries? If it were possible to just use an SDL_Sound dll to keep it
totally separate we would opt for this in an effort to fall under
subsection

5, but I wasn’t able to find anything on a dll (I’m not too familiar
with

dll’s in the first place, so maybe I’m missing something obvious).

To answer the question, build SDL_sound as a DLL (only source is
distributed, but you can compile it or find someone else who has done
so), and put it in the same folder as your game. Link your game against
that, proceed as normal.

If you make any changes to SDL_sound itself, send them to me for
inclusion in the main codebase. You don’t have to open source your
software if you do these things (but you are certainly welcome to, of
course).

Bottom line: don’t statically link SDL_sound, and don’t take snippets of
code from it to put into your closed source program…everything else is
basically okay.

As I understand the LGPL you can statically link the code so long as
you provide object files so that the end user can also statically link
the code. The idea is that the end use has to have the same rights that
you have.

  Bob Pendleton

SDL itself falls under these same guidelines. The license seems
daunting, but it’s pretty simple, overall.

–ryan.


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

±----------------------------------+


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

±----------------------------------+

A rule of thumb I always think of when it comes to the LGPL is:

If a new version of the SDL library comes out, will the user be able to
use it with my binary application. If the answer is no, then you’re not
abiding by the rules of LGPL.

This is a REALLY good way to put it, BTW. :slight_smile:

Possibly solutions to this are as follows:

  1. Make the dependency on SDL be dynamic. So if the user replaces the
    provided SDL.dll with their own, your binary application will continue to
    function and use the new features in the updated library (assuming of
    course that the new dll is binary compatible with the old dll).
  1. Make the dependency on SDL be static, and provide object files that
    can be used to recreate the application.

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

Please forgive my ignorance, but what does ‘object file’ correspond to
in the Windows world?
Do you mean that if I statically compile SDL into my program, in
addition to the program, I need to toss the SDL.dll somewhere for
them to use if they want?

It means you need to toss your applications object files. Not the SDL
library. The idea is the user has to be able to drop in a replacement
for SDL and your program still works. This is an absolute requirement of
the LGPL.

If your program is open source, you don’t need to care because the user
can recompile everything anyways.

If your program is closed source, you have two options:

a) Dynamically link against SDL, so the enduser can simply replace
SDL.dll (or whatever on other platforms). This is the best solution and
usually recommanded.

b) Statically link against SDL and distribute your object files, so
the user can relink your object files with SDL and recreate your binary.
Object files usually have a .o or .obj suffix, depends on the compiler.
If you use Visual C++, you find your .obj files in the Release folder
together with the .exe. You do not need to distribute the SDL object
files, the user can compile them himself.

However, this second solution is hardly necassary, as statically linking
against SDL doesn’t really provide much of an advantage. On Windows just
drop the SDL[_XXX].dll files into your applications installation folder
and you are set. On Linux I usually tell the enduser to install the SDL
libs from his distro or, if the specific SDL lib is somewhat exotic (not
SDL, SDL_mixer, SDL_image), bundle the shared lib with my application -
basically same procedure as on Windows except one can try to avoid
cluttering the users system with dozens of shared SDL libs.

Additionally you need to distribute the SDL sourcecode with your closed
source application or provide a way the user can get it. Common
practice is to offer a download link if you want to avoid bundling the
sources in your installer (it’s not interesting for the average enduser,
so you might try not to bloat your installer). Refer to the LGPL text
for details on how exactly you need to make the SDL sourcecode
available. Most distributors have some link on their webpage like
"Download library XXX sourcecode here" and do not bundle the code into
the app installer.

I am not a lawyer, so please take the above with care. :slight_smile:

Peter

Thank you, that was much more clear.
Jason.> ----- Original Message -----

From: sdl-admin@libsdl.org [mailto:sdl-admin at libsdl.org]On Behalf Of
Peter Strempel
Sent: Wednesday, October 15, 2003 2:15 PM
To: sdl at libsdl.org
Subject: Re: [SDL] SDL_Sound license

Please forgive my ignorance, but what does ‘object file’ correspond to
in the Windows world?
Do you mean that if I statically compile SDL into my program, in
addition to the program, I need to toss the SDL.dll somewhere for
them to use if they want?

It means you need to toss your applications object files. Not the SDL
library. The idea is the user has to be able to drop in a replacement
for SDL and your program still works. This is an absolute requirement of
the LGPL.

If your program is open source, you don’t need to care because the user
can recompile everything anyways.

If your program is closed source, you have two options:

a) Dynamically link against SDL, so the enduser can simply replace
SDL.dll (or whatever on other platforms). This is the best solution and
usually recommanded.

b) Statically link against SDL and distribute your object files, so
the user can relink your object files with SDL and recreate your binary.
Object files usually have a .o or .obj suffix, depends on the compiler.
If you use Visual C++, you find your .obj files in the Release folder
together with the .exe. You do not need to distribute the SDL object
files, the user can compile them himself.

However, this second solution is hardly necassary, as statically linking
against SDL doesn’t really provide much of an advantage. On Windows just
drop the SDL[_XXX].dll files into your applications installation folder
and you are set. On Linux I usually tell the enduser to install the SDL
libs from his distro or, if the specific SDL lib is somewhat exotic (not
SDL, SDL_mixer, SDL_image), bundle the shared lib with my application -
basically same procedure as on Windows except one can try to avoid
cluttering the users system with dozens of shared SDL libs.

Additionally you need to distribute the SDL sourcecode with your closed
source application or provide a way the user can get it. Common
practice is to offer a download link if you want to avoid bundling the
sources in your installer (it’s not interesting for the average enduser,
so you might try not to bloat your installer). Refer to the LGPL text
for details on how exactly you need to make the SDL sourcecode
available. Most distributors have some link on their webpage like
"Download library XXX sourcecode here" and do not bundle the code into
the app installer.

I am not a lawyer, so please take the above with care. :slight_smile:

Peter


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

As I understand the LGPL you can statically link the code so long as
you provide object files so that the end user can also statically link
the code. The idea is that the end use has to have the same rights that
you have.

Yeah, but in this modern age, it’s easier to just tell people to ship it
as a DLL, since it comes to the same result.

–ryan.

Thanks Bill!

===== Original Message From Bill Kendrick =====

p.s. I know this seems like a ridiculous question, but would someone be so
kind as to tell me what my subject line should read if I wish this email to
show up as a sub-thread? I tried putting “RE:” in front of the [SDL] in
the>On Wed, Oct 15, 2003 at 12:10:38PM -0700, Patrick Tuckey wrote:

past, but I don’t think it worked. Merci.

Usually mail clients throw headers like these in:

In-Reply-To:
Message-ID: <20031015214611.8848484 at blah.blah.blah>
References:

…which other mailers (like Mutt, which threads) and mailing list archivers
use to figure out threads.

-bill!


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl