SDL & license issues

a lot of the Loki titles statically linked SDL, and provided a 
separate dynamically linked version to satisfy the LGPL...in my 
experience, this actually proved to not be necessary with SDL, since the 
API has stayed stable and binary compatible. Rather than support two 
binaries on things like UT2004, I just shipped the one dynamically 
linked version (with a "blessed" SDL included).

There's one big gotcha if you do this, though:  RPATH.  If you include  
libraries with rpath set, your included libraries will be *ignored* and  
the system-installed library is used instead.  Many libraries (including  
SDL!) compile with rpath set to /usr/lib by default, and it's not always  
straightforward to disable this.  Be prepared for some libtool and  
Makefile editing.

Once you've got some usable libraries included with your game, that still  
requires the game to be run through a wrapper script, though.  Currently  
the DROD wrapper script sets LD_LIBRARY_PATH, but some time ago I  
discovered that it's possible to set RPATH for executables as well as  
libraries, which removes the need for setting LD_LIBRARY_PATH at all.   
It's possible to set relative executable rpaths, but these are relative to  
the *current* directory, not the executable directory .. so you end up  
needing that wrapper script anyway, unless you restrict installing to one  
location (bad idea) or link at install time (requires object or  
partially-linked files and a compatible linker).  Might as well just use  
LD_LIBRARY_PATH, then (which would also let people who really know what  
they're doing be able to edit it, which could be both a pro and a con ..).

There is another way, though: dlopen.  If you don't mind having function  
pointers for everything, you could make your executable search for the  
libraries in stead, and load them dynamically at runtime from wherever you  
stashed them.

One thing I've been thinking about occasionally is that it could even be  
possible to statically link one version of SDL into your game and,  
depending on configuration options, optionally override the statically  
linked SDL with a dynamically loaded one, by setting those function  
pointers accordingly.  I've never actually done this, but I don't see any  
reason why it wouldn't work, and I think it'd even be in compliance with  
the LGPL without giving away any object files (since it allows relinking)  
.. although I admit this sounds like a "having your cake and eating it  
too" scheme, and I don't know what Sam would think of this what with the  
new commercial licensing and all.  


Sam Lantinga :

SDL's use of the LGPL is twofold:
1. Allow end users to use custom versions of the library, to support bug
   fixes and improved hardware support and other enhancements.
2. Allow any improvements made to the library for one project to benefit the
   community as a whole.

The redistribution of SDL applications falls under section 6 of the LGPL
(quoted below.)  If you read it, you'll notice that you can either link
with the library as a shared object, or provide object or source code for
your application along with any non-standard utilities required to relink
your application.  You'll also notice that you have to provide these upon
request, but do not have to distribute them with your application.

In embedded environments, I interpret this to mean that you must provide
all of the pieces necessary for someone to relink your application with
a custom version of the SDL library, assuming they have a standard development
kit for the platform.  This includes any custom tools required by the build
process, and source or object code to both your application and the SDL
library.

You'll notice that there really isn't any special distinction between
embedded and non-embedded environments.  In both cases, if you link with
a shared object you're fine.  If you link with a static object you must
provide any custom tools and machine readable object or source code needed
for someone who has a standard development environment to link with a
custom version of the library.



It's worth noting that several companies use SDL in closed source 
solutions: Loki statically linked it and supplied an unsupported 
dynamically linked version too. Epic just dynamically links it for 
Unreal and ships the shared library with the game as the sole 
configuration, so this is really only a question for embedded things 
like SymbianOS.



Is this a case where you can comply with the letter of the LGPL even
though you know you can not comply with the spirit? As long as you
provide the ability to relink and object files needed to relink, aren't
you in compliance even though the end user is unlikely to be able to
burn a new ROM?

Remember that many commercial products including most of the Linksys
routers and now cell phone are all based on the Linux kernel (GPL) and
use many libraries (LGPL) and utilities (GPL) and yet they are still
considered to comply so long as the end user can relink and burn a new
ROM should they chose to do so.


From what ive gathered if you link staticly to sdl (ie compile sdl into your exe) you have to make your code open sourced. Or provide libraries to which one can re-statically-link your app
against new libraries (like SDL).


So, your choices when using SDL and other LGPL'd libraries in your app:

  * Dynamically-link against the LGPL'd library

  * Statically-link, but also provide object files,
    so users can re-link against newer versions of the LGPL'd library

  * Statically-link, but also rovide source code,
    so users can re-link against newer versions of the LGPL'd library
	

If I'm using some DLL's which are not compiled by
myself can I package (zip) them with my software (with
all information about the source), or I have to tell
the users to download them from the official site?


You may package it.

 From the SDL webpage:
------------------------------------
Embedded Use:
Personally, I don't have a problem with anybody statically linking SDL 
for use with embedded environments that don't already have an open 
development environment. (i.e. the users can't relink programs anyway) 
However, this does technically violate the LGPL, so be cautioned.
-------------------------------------

   What do you think the chances of getting the SDL copyright holder to 
make this an official exception in the SDL's LGPL license (like eCos has 
its its GPL)?
    As it stands, the SDL stock LGPL renders at least the Symbian 
version academic, as there is no way to comply with the license other 
than to only give out the source, and require end-users compile their 
own binary.



There are lots of copyright holders, and each would have to be contacted.
I doubt it'd be possible.  (Given Sam's blunt "no" responses to this type
of thing in the past, I'm sure he isn't going to try, but he can speak
for himself).

This is a major reason I'm dropping SDL, myself; "you can probably get
away with it" really isn't good enough.  (For example, a hostile company
could buy out the copyright stake of any substantial SDL contributor and
sue five years down the line--and that's not far-fetched at all.)

That statement is false. Code under the GPL/LGPL/BSD/[probably others] license remains under that license for ever. People owning the copyright on a part of the code have the right to relicense that part of the code as they wish, but that changes nothing for the project this code is in. With SDL, the code that's in SDL remains under LGPL for ever, and people have the right to reuse it in other projects under the LGPL license.

But of course, if they wish, people having the copyright on some parts of the code are allowed to use the parts they've written under another license (even make it closed source) in another project. That's what happened to tuxracer after version 0.61 : up to 0.61, tuxracer was GPL, but after 0.61 almost all the contributors agreed on making the code closed source, and the parts written by people disagreeing with this change were removed. Tuxracer now has a closed source version, but the GPL version 0.61 still legally exists under the GPL, although it's not really maintained AFAIR. But if someone wanted to continue it, they would be allowed to under the terms of the GPL.

Do you imagine the trouble if each free software project contributor could sue each project they contributed to ?
There is another excellent incentive for Sam et. al. to visit the 
license issue.  (not going into why this is and flame-bait GPL history) 
  The GPL and LGPL do not indemnify copyright holders from each other's 
infringements, or the infringements of contributors not asserting 
copyright.  This basically means that if someone contributes code that 
infringes on, or violates a copyright or a patent, all copyright holders 
can be held accountable and sued... which would probably happen in this 
order:  Person/company most prominent balanced with least able to defend 
themselves, person/company with deepest pockets.

   So many people are contributing to SDL, that Sam et. al. would be 
wise to protect themselves from suit-happy companies so they don't get 
burned for someone else's infringement.

(as it's become netiquette not to encourage GPL/LGPL debates, I'll offer 
my private email address as an avenue if you'd like to discuss or flame 
me:  artix[at]pacbell.net)

Digging into it a bit...

   It looks like there are only 6 people asserting copyright other than 
Sam :    Carsten Griwodz, Jason Evans, Hsieh-Fu Tsai, and Greg Haerr, 
Christian Nentwich, and Jonathan Matthew.  The last two are only for the 
hermes port.

   Work contributed by others are freed from copyright controll except 
for an obsolete linux thread file that has the (c) assigned to the FSF, 
but it can probably be removed as it looks like it was needed for 
versions of gcc prior to v2.

 > This is a major reason I'm dropping SDL, myself; "you can probably get
 > away with it" really isn't good enough.  (For example, a hostile
 > company could buy out the copyright stake of any substantial SDL
 > contributor and sue five years down the line--and that's not
 > far-fetched at all.)
 >

   That's unfortunate, but I understand.  The GPL and LGPL were born at 
a time when commercial developers were at odds with freeware developers. 
  Luckily things have started changing and commercial developers are 
beginning to choose to spend their time improving open, community-based 
software so that everyone benefits, rather than creating a proprietary 
solution.

 It's not an issue of closed-source, it is a problem even with 
GPL/LGPL covered programs.

   With a number of embedded OSes, the end user is not able to compile 
or relink, and the OS doesn't dynamically link.  For example:   If you 
create a program for SymbianOS, the average user does not have the 
ability to compile and link source.  It would be nice to give them a 
working version;  otherwise, the software created is useless to the vast 
majority of users.  In order to do that, you must create a statically 
linked executable.  Because the statically linked version contains both 
  non-GPL/LGPL-compatible code from Symbian (and potentially other 
companies involved in the OS), it violates the LGPL.  More problems 
arise when the running OS differs significantly from the development OS, 
as is the case with most embedded OSes.  Even if you can dynamically 
link, it may require pre-linking with code not provided standard with 
the OS, which violates the GPL/LGPL.  (Because the GPL was created with 
Unix-ish OSes in mind, the FSF could not have reasonably predicted this 
problem, so it's not their fault.  They can take pride in that their 
software ideology has been so widely embraced beyond its original intent.)

   The Java community has been arguing something similar with the FSF. 
They've been asking the FSF to re-word part of the GPL to allow for the 
way the Java VM works.  (Something like all GPL Java violates the GPL.) 
  When the GPL was created, the FSF could not have reasonably predicted 
the problem.  However, it has been up to individual authors to create 
exclusions because, unfortunately, the FSF's official response has been 
that Sun should put Java under the GPL.


Hmm, if you distribute the .o files, you can do that alongside with the 
static binaries. See the LPGL, article 6 a) it says <>

The only trouble is, as you said, when the build environment is 
proprietary. That's really a gray area I wouldn't venture in 


Q. Can I use SDL in a commercial game?
A. Yes you can, if you link statically (include the sdl source inside your
game when you compile) you have to make your source code available to the
public.  If you link dynamically (via .dll's, .so's or using other dynamic
linking devices) then you do not need to do anything.

Q. If I use SDL commercially do I owe royalties to SDL?
A. No you do not but you can donate here

See also : the FAQ in libsdl.org



What you have to do is provide a way for people to replace the
linked SDL library.  This can be done in several ways:

* Link dynamically
* Provide both dynamic and static (but otherwise identical) executables
* Only static, but provide source code
* Only static, but provide relinkable object files
* Only static, but provide a way to override the statically linked SDL
* More (read the LGPL)