Hi, i’m kinda new to the LGPL and i’d like to know if I can sell a game i would
make with SDL. As always, the game would be distribued as a .exe & the sdl.dll,
so it’s dynamicaly linked. However, they say on the license page I need to
provide the full source code of my application/game… which pretty much
disables games from getting any money… however i’m seeing some people making
commercial games with it, how do they do it?
Sorry if i’m posting something answered millions times before,
and thanks for your help.
Hi, i’m kinda new to the LGPL and i’d like to know if I can sell a game i
would make with SDL.
you can sell anything, even if you release the source code
As always, the game would be distribued as a .exe &
the sdl.dll, so it’s dynamicaly linked.
this is what you’ll have to do in order to keep from releasing the source code
to your game
However, they say on the license
page I need to provide the full source code of my application/game…
no it doesnt … you have to release the source code if you statically link
against the library, which you already stated you wont be doing
-mikeOn Tuesday 04 October 2005 11:35 pm, Pascal Gu?rin wrote:
you have to release the source code if you statically link against the
library, which you already stated you wont be doing
no, even if you link statically it is sufficient to provide object
files. the enduser must be able to relink your binaries with a later
(maybe enhanced or bugfixed, but still binary compatible version of any
used LGPL code.)
Actually, I believe this is incorrect. You can release statically-linked
applications against LGPL libraries (like SDL), if you also supply an
object file which the end user may then link against a newer version of
the LGPL libraries, if they choose to do so (e.g., if a security update to
the library is released).
Releasing with dynamic libraries is typically easier on both the developer
and the end user, though, I think.
I just wanted to point out that you DON’T need to release code if you
statically link. (However, [L]GPL being what they are, and FSF being who
they are, they obviously encourage it. ;^) )On Wed, Oct 05, 2005 at 01:24:50PM -0400, Mike Frysinger wrote:
However, they say on the license
page I need to provide the full source code of my application/game…
no it doesnt … you have to release the source code if you statically link
against the library, which you already stated you wont be doing
no, even if you link statically it is sufficient to provide object
files. the enduser must be able to relink your binaries with a later
(maybe enhanced or bugfixed, but still binary compatible version of any
used LGPL code.)
so if you link dynamically, you don’t need to provide object files,
obviously right, because dynamic linking means you don’t have to
worry about such things in the first place …–
However, perhaps the FAQ shouldn’t simply state: “just dynamically
link with SDL and you’re fine”, but rather also try to explain the
requirements of statically linking with SDL.
Also maybe mention that GPL and LGPL stuff can be (and is) sold, while
still remaining Free and Open Source software. :^)On Wed, Oct 05, 2005 at 03:35:39AM +0000, Pascal Gu?rin wrote:
Sorry if i’m posting something answered millions times before,
and thanks for your help.
If that’s a question, then the answer: Yes, correct.
-bill!On Wed, Oct 05, 2005 at 08:02:02PM +0200, Jay Vaughan wrote:
so if you link dynamically, you don’t need to provide object files,
obviously right, because dynamic linking means you don’t have to
worry about such things in the first place …
however i’m seeing some people making commercial games with it, how do they do it?
We do, and as many others correctly replied, the easiest way is to
provide SDL as .DLL/.so and you’re fine.
Just wanted to clarify why all this makes sense and it’s not as
arbitrary as it sounds. The idea behind the LGPL is that the user should
be able to run your program with a modified version of the LGPL’d
library. This is why statically linking but providing the source;
statically linking but providing the object files; and dynamically
linking are all valid options - they all allow the user to run a
modified SDL.
Hmm this gives me an idea: wouldn’t it be nice to see a game on your
favorite shop’s shelf including the “feature”:
Source code included!
I would surely love it! I guess there are quite I few
young-aspiring-game-developers just buying the game even if it is
crap! hehe
cya
/OlofOn 10/5/05, Gabriel wrote:
however i’m seeing some people making commercial games with it, how do they do it?
We do, and as many others correctly replied, the easiest way is to
provide SDL as .DLL/.so and you’re fine.
Just wanted to clarify why all this makes sense and it’s not as
arbitrary as it sounds. The idea behind the LGPL is that the user should
be able to run your program with a modified version of the LGPL’d
library. This is why statically linking but providing the source;
statically linking but providing the object files; and dynamically
linking are all valid options - they all allow the user to run a
modified SDL.
However, perhaps the FAQ shouldn’t simply state: “just dynamically
link with SDL and you’re fine”, but rather also try to explain the
requirements of statically linking with SDL.
indeed … how about this:
Q: Can I use SDL in a commercial application?
The easiest way to use SDL in a commercial product is to dynamically link with
SDL. Then all you need to release is the final compiled product.
If you want to statically link with SDL, then you will need to also release
the object code in addition to the final compiled product so that end users
can relink the final product.
In either of these cases, you are not required to include the source code to
your application, although you certainly may. The intent of the license is
to allow end users to drop in a new or modified version of the SDL library .
Thanks all for your help. It’s been really long since I wanted to clarify
that (english’s not my main language, and i’m no lawyer
And yea my first sdl projects would probably be free with source code,
it’s just that I might consider making a commercial game/application
with SDL in the future.
Does it allow me to compile and link sdl, sdl_mixer, sdl_image,
libpng, jpeglib, zlib and anything related into a single DLL ?
Should I provide something else?
Furthermore, is there way to insulate the licence ? I mean,
making a DLL(using SDL) agree with LGPL, but the DLL it self
providers a less licence.
Thanks.
“Pascal Gu??rin” > Thanks all for your help. It’s been really long since I wanted to clarify
that (english’s not my main language, and i’m no lawyer
Does it allow me to compile and link sdl, sdl_mixer, sdl_image,
libpng, jpeglib, zlib and anything related into a single DLL ?
you can compile anything you want into one file as long as their license
agrees … and afaik, all of these should be compatible with LGPL which means
you can link everything listed here into one DLL
Furthermore, is there way to insulate the licence ? I mean,
making a DLL(using SDL) agree with LGPL, but the DLL it self
providers a less licence.
really have no idea what you mean by ‘insulate’ and ‘a less license’
-mikeOn Wednesday 05 October 2005 10:09 pm, RocWood wrote:
However, perhaps the FAQ shouldn’t simply state: “just dynamically
link with SDL and you’re fine”, but rather also try to explain the
requirements of statically linking with SDL.
indeed … how about this:
Q: Can I use SDL in a commercial application?
A: Of course you can.
If you don’t like to ship object code (since it’s not that useful
without makefiles, compilation instructions, etc) it’s correct also to
supply the product with two executable versions (One statically linked
and one dinamically linked)?
This make sense in linux where dinamically linking an app for an end
user is tipically a MESS, since every distribution has it’s own version
of the libraries often incompatibile with past versions… Just think
about the mess of libstdc++ abi changes or xfree/xorg…
I mean, an advanced user can probably solve those problems, but a newbie
cannot for sure (and newbie linux users are growing fast)
If you don’t like to ship object code (since it’s not that useful
without makefiles, compilation instructions, etc) it’s correct also to
supply the product with two executable versions (One statically linked
and one dinamically linked)?
Since neither violates the LGPL alone, I don’t see why they’d violate it
together. Probably safe.
This make sense in linux where dinamically linking an app for an end
user is tipically a MESS, since every distribution has it’s own version
of the libraries often incompatibile with past versions… Just think
about the mess of libstdc++ abi changes or xfree/xorg…
I have not once experienced any dynamic linking problems with SDL under many
linux-es. Not once. At all. Ever. Being pure C helps a lot – every
new gcc version breaks C++ linking with older libraries, but C linking hasn’t
changed much in 20 years. Also SDL, SDL_image, SDL_net, SDL_ttf, and
SDL_mixer have changed very little externally by design, it prevents linking
problems like these.
If anything, statically linking will produce it’s own mess of problems…
what if your target has totally different video drivers available than you
assumed when you hardwired SDL into your app?On October 6, 2005 03:47 am, Gabriele Greco wrote:
if you mean all of the source code for the SDL library, that wouldnt make you
compliant with the license in the least … unless you modified the SDL
library code somehow and were distributing the compiled library, in which
case you’d be obligated to make those changes available too
-mikeOn Thursday 06 October 2005 11:44 am, peter wrote:
