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...if you staticly link, i would require the games source code to be able
> to update/modify sdl.
Or… again, see above. :^)
Quoting the GNU Library General Punlic License (LGPL), version 2, June 1991
(from my copy of the SDL_mixer library sources, if you have to know)…
"5. A program that contains no derivative of any portion of the
Library, but is designed to work with the Library by being compiled or
linked with it, is called a “work that uses the Library”. Such a
work, in isolation, is not a derivative work of the Library, and
therefore falls outside the scope of this License.
“However, linking a “work that uses the Library” with the Library
creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a “work that uses the
library”. The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables.”
IANAL, but I believe what section 5 is saying is that your application
(a game that uses SDL, for example) is not affected by the LGPL if you
simply link to it. e.g., if “supergame.exe” uses “libsdl.dll”, the LGPL
doesn’t affect Super Game in any way.
However, if you create a statically-linked “supergame.exe” that includes the
SDL library inside, your game becomes covered by the LGPL, which is probably
not what you want if you’re not interested in releasing Super Game as
Free / Open Source software. :^)
But as it says, section 6 covers this:
"6. As an exception to the Sections above, you may also compile or
link a “work that uses the Library” with the Library to produce a
work containing portions of the Library, and distribute that work
under terms of your choice, provided that the terms permit
modification of the work for the customer’s own use and reverse
engineering for debugging such modifications.
… "Also, you must do one of these things:
“a) Accompany the work with the complete corresponding
machine-readable source code for the Library including whatever
changes were used in the work (which must be distributed under
Sections 1 and 2 above); and, if the work is an executable linked
with the Library, with the complete machine-readable “work that
uses the Library”, as object code and/or source code, so that the
user can modify the Library and then relink to produce a modified
executable containing the modified Library. (It is understood
that the user who changes the contents of definitions files in the
Library will not necessarily be able to recompile the application
to use the modified definitions.)”
[6b through 6d are just other means to provide the materials
specified in 6a…]
So, again, to try and interpret… If you produce an executable that
includes the library (say, by statically linking to it… your
“supergame.exe” contains libSDL right inside, rather than loading it
as a “.dll” at runtime), you must provide:
-
The source code to the library. (Okay, easily done… just make
the SDL library source available.)
-
Provide the object code AND/OR the source code to your executable
(the “work that uses the Library”), so people can re-link to a
modified version of the library. (Say SDL 1.3 fixes a horrendous bug.
Users of “supergame.exe” should be able to use SDL 1.3, even though
you released it with SDL 1.2. If you didn’t dynamically link against
SDL, this means the users need to relink themselves to produce a
new statically-linked version of “supergame.exe”)
Notice it says “object code and/or source code.” If you don’t want your
game’s source out there, just provide the compiled object version.
(You already are, in a sense, by providing an EXE that statically-links
against libSDL. It’s just that the average user would never do anything
with the “.o” object files, unless they decided to take advantage of the
freedom that section 6 of the LGPL is giving them.)
WHEW!
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
When in doubt, though, read the license… consult a lawyer.
I’m still at that lazy/naiive state where I don’t have a lawyer,
but still produce and deliver software for the public (my GPL’d open source).
If I were releasing games that were not OSS, I would probably want a lawyer
handy, REGARDLESS as to whether I was using LGPL’d libraries like SDL,
or non-Open-Source libraries with commercial licenses…
Whew Anyway. Just wanted to correct that bit, and quote the LGPL a little.
Sorry for the noise. Has this been dealt with sufficiently in the FAQs?
In the future, it’d be nice to just throw URLs at people.
-bill!
bill at newbreedsoftware.com “Avoid missing ball for high score”
http://www.newbreedsoftware.com/
New Breed SoftwareOn Wed, Aug 11, 2004 at 10:04:17PM -0700, Alan Wolfe wrote:
