Going forward SDL 1.3 will be under licensing terms that are compatible with
open source and commercial projects, the zlib license:
http://zlib.net/zlib_license.html
Galaxy Gameworks will no longer be selling licenses to SDL, but will
continue to support our existing customers.
SDL development will continue, but will largely be community driven and Ryan
and I will continue to coordinate patch integration and SDL releases. We
will be working to make it easier to contribute in a variety of ways, and
are looking for people interested in helping out.
Oh, and Google Summer of Code is on!
Cheers!
–Sam Lantinga
Hello !
Going forward SDL 1.3 will be under licensing terms that are compatible with
open source and commercial projects, the zlib license:
http://zlib.net/zlib_license.html
Does the zlib license allow to develop for restricted systems like XBOX360 and PS3 ?
CU
Yes.On Thu, Apr 7, 2011 at 12:17 PM, Torsten Giebl wrote:
Hello !
Going forward SDL 1.3 will be under licensing terms that are compatible
with
open source and commercial projects, the zlib license:
http://zlib.net/zlib_license.html
Does the zlib license allow to develop for restricted systems like XBOX360
and PS3 ?
CU
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Woo! No more LGPL-shaped anchor around my neck when I develop custom features!
I always did feel a bit nervous about that. (I will, of course, continue to
submit new feature patches for review and possible inclusion in the "official"
SDL anyway.)
Thanks!
BTW does this also cover related libraries such as SDL_Image, SDL_Mixer, etc?________________________________
From: slouken@libsdl.org (slouken)
Subject: [SDL] SDL 1.3 licensing terms
Going forward SDL 1.3 will be under licensing terms that are compatible with
open source and commercial projects, the zlib license:
http://zlib.net/zlib_license.html
Galaxy Gameworks will no longer be selling licenses to SDL, but will continue to
support our existing customers.
SDL development will continue, but will largely be community driven and Ryan and
I will continue to coordinate patch integration and SDL releases. We will be
working to make it easier to contribute in a variety of ways, and are looking
for people interested in helping out.
Oh, and Google Summer of Code is on!
Cheers!
–Sam Lantinga
Does the zlib license allow to develop for restricted systems like XBOX360 and PS3 ?
Yes (although you would still need developer agreements with Sony or
Microsoft to develop for those platforms, but that has nothing to do
with SDL itself).
The more immediate benefit: you can statically link SDL, and you can
ship it on iOS.
The zlib license basically says this:
- Do what you want (but don’t take our names off the source code).
- Don’t sue us (no warranty).
- Mention us in the documentation if you like, but you don’t have to.
It’s a “BSD-like” license, but it’s less restrictive than the BSD
license, believe it or not (BSD requires you to mention the license in
your documentation). It’s WAY less restrictive than the LGPL (at the
risk of a holy war: the LGPL enforces freedom. The zlib license just
appreciates it. Frankly, that fits my personality better, but YMMV).
The zlib license is compatible with closed-source software and the GPL,
too. You can use zlib-licensed software in either type of project. For
most people using or developing SDL, nothing has changed: keep using SDL
as you have been.
But for those noticing changes, they should be positive changes.
–ryan.
Yes, it will cover SDL related libraries that I maintain: SDL_image,
SDL_mixer, SDL_ttf, SDL_rtf, SDL_net
For other libraries, you’ll have to discuss it with the authors. Remember
that for libraries that are LGPL the author has to contact all prior
contributors to get their permission to use a different license, which is
why SDL 1.2 will remain LGPL.
See ya!On Thu, Apr 7, 2011 at 12:25 PM, Mason Wheeler wrote:
Woo! No more LGPL-shaped anchor around my neck when I develop custom
features! I always did feel a bit nervous about that. (I will, of course,
continue to submit new feature patches for review and possible inclusion in
the “official” SDL anyway.)
Thanks!
BTW does this also cover related libraries such as SDL_Image, SDL_Mixer,
etc?
From: Sam Lantinga
**Subject: [SDL] SDL 1.3 licensing terms
Going forward SDL 1.3 will be under licensing terms that are compatible
with open source and commercial projects, the zlib license:
http://zlib.net/zlib_license.html
Galaxy Gameworks will no longer be selling licenses to SDL, but will
continue to support our existing customers.
SDL development will continue, but will largely be community driven and
Ryan and I will continue to coordinate patch integration and SDL releases.
We will be working to make it easier to contribute in a variety of ways, and
are looking for people interested in helping out.
Oh, and Google Summer of Code is on!
Cheers!
–Sam Lantinga
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Hello !
Does the zlib license allow to develop for restricted systems like XBOX360 and PS3 ?
Yes (although you would still need developer agreements with Sony or Microsoft to develop for those platforms, but that has nothing to do with SDL itself).
The more immediate benefit: you can statically link SDL, and you can ship it on iOS.
The zlib license basically says this:
- Do what you want (but don’t take our names off the source code).
- Don’t sue us (no warranty).
- Mention us in the documentation if you like, but you don’t have to.
It’s a “BSD-like” license, but it’s less restrictive than the BSD license, believe it or not (BSD requires you to mention the license in your documentation). It’s WAY less restrictive than the LGPL (at the risk of a holy war: the LGPL enforces freedom. The zlib license just appreciates it. Frankly, that fits my personality better, but YMMV).
The zlib license is compatible with closed-source software and the GPL, too. You can use zlib-licensed software in either type of project. For most people using or developing SDL, nothing has changed: keep using SDL as you have been.
But for those noticing changes, they should be positive changes.
Thanks Ryan, that sounds great !
CU
Hi,
Going forward SDL 1.3 will be under licensing terms that are compatible
with open source and commercial projects, the zlib license:
http://zlib.net/zlib_license.html
When I was asking for a BSD-ish license today I was not seriously
expecting a change in license anytime soon if at all. This is amazing
news to be honest.
Major props for making this move.
We will be working to make it easier to contribute in a variety of ways,
and are looking for people interested in helping out.
I guess am going to propose something completely insane (and biased as
I’m one of the guys behind the Sphinx documentation tool) but what are
the odds of converting the currently moin based documentation into a
Sphinx[1] based documentation? I am already writing a bunch of articles
about my adventures with SDL currently and I would not mind too much
updating the SDL documentation along the way.
The reason I am asking is that right now the documentation is not
necessarily bad, but it could be greatly improved and I think Sphinx
provides a pretty good basis for writing documentation. The main
motivation here is that in combination with bitbucket/github pull
requests it’s quite easy to integrate documentation fixes easily and you
can view the documentation offline easily and also convert them into a PDF.
Revamping the documentation and cleaning up might make a good GSOC
project as well.
Regards,
Armin
[1]: http://sphinx.pocoo.org/On 4/7/11 9:11 PM, Sam Lantinga wrote:
Having offline/PDF documentation is something that I’ve been interested in
for a while. However there’s the hurdle of converting a huge amount of
existing documentation.
Do you have an easy way to mass convert a moin wiki to Sphinx?On Thu, Apr 7, 2011 at 1:52 PM, Armin Ronacher <armin.ronacher at active-4.com>wrote:
Hi,
On 4/7/11 9:11 PM, Sam Lantinga wrote:
Going forward SDL 1.3 will be under licensing terms that are compatible
with open source and commercial projects, the zlib license:
http://zlib.net/zlib_license.html
When I was asking for a BSD-ish license today I was not seriously
expecting a change in license anytime soon if at all. This is amazing
news to be honest.
Major props for making this move.
We will be working to make it easier to contribute in a variety of ways,
and are looking for people interested in helping out.
I guess am going to propose something completely insane (and biased as
I’m one of the guys behind the Sphinx documentation tool) but what are
the odds of converting the currently moin based documentation into a
Sphinx1 based documentation? I am already writing a bunch of articles
about my adventures with SDL currently and I would not mind too much
updating the SDL documentation along the way.
The reason I am asking is that right now the documentation is not
necessarily bad, but it could be greatly improved and I think Sphinx
provides a pretty good basis for writing documentation. The main
motivation here is that in combination with bitbucket/github pull
requests it’s quite easy to integrate documentation fixes easily and you
can view the documentation offline easily and also convert them into a PDF.
Revamping the documentation and cleaning up might make a good GSOC
project as well.
Regards,
Armin
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Hi,On 2011-04-08 12:35 AM, Sam Lantinga wrote:
Do you have an easy way to mass convert a moin wiki to Sphinx?
When the Python documentation was converted from LaTeX to Sphinx Georg
wrote a tool that converts a node tree into .rst files. The code is
still around albeit hidden1. Modern version of the MoinMoin wiki
internally parse into some kind of DOM inspired tree, so it should be
possible to convert that one into a docutils one and then pass it over
to the old restwriter from the converter.
Assuming you could provide me with the text files for the latest
revisions of the MoinMoin documentation I could try to write a small
script together that does that.
Regards,
Armin
As a start, how about adding Doxygen markup to the functions and adding
the content in the existing documentation to it via some /include hooks.
Doxygen does create nice LaTeX, PDF and PS files (see
http://www.doxygen.nl/output.html). Not sure what it would take to
export the wiki existing documentation automatically into a doxygen
consumable and parser-friendly format though and mark up the functions -
but nothing a little perl script couldn’t handle. 
Would make a nice
GSOC project too.
–AndreasOn 4/7/11 3:35 PM, Sam Lantinga wrote:
Having offline/PDF documentation is something that I’ve been
interested in for a while. However there’s the hurdle of converting a
huge amount of existing documentation.
Do you have an easy way to mass convert a moin wiki to Sphinx?
On Thu, Apr 7, 2011 at 1:52 PM, Armin Ronacher <armin.ronacher at active-4.com <mailto:armin.ronacher at active-4.com>> wrote:
Hi,
On 4/7/11 9:11 PM, Sam Lantinga wrote:
> Going forward SDL 1.3 will be under licensing terms that are
compatible
> with open source and commercial projects, the zlib license:
> http://zlib.net/zlib_license.html
When I was asking for a BSD-ish license today I was not seriously
expecting a change in license anytime soon if at all. This is amazing
news to be honest.
Major props for making this move.
> We will be working to make it easier to contribute in a variety
of ways,
> and are looking for people interested in helping out.
I guess am going to propose something completely insane (and biased as
I'm one of the guys behind the Sphinx documentation tool) but what are
the odds of converting the currently moin based documentation into a
Sphinx[1] based documentation? I am already writing a bunch of
articles
about my adventures with SDL currently and I would not mind too much
updating the SDL documentation along the way.
The reason I am asking is that right now the documentation is not
necessarily bad, but it could be greatly improved and I think Sphinx
provides a pretty good basis for writing documentation. The main
motivation here is that in combination with bitbucket/github pull
requests it's quite easy to integrate documentation fixes easily
and you
can view the documentation offline easily and also convert them
into a PDF.
Revamping the documentation and cleaning up might make a good GSOC
project as well.
Regards,
Armin
[1]: http://sphinx.pocoo.org/
_______________________________________________
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Hi,On 4/8/11 5:01 AM, Andreas Schiffler wrote:
As a start, how about adding Doxygen markup to the functions and adding
the content in the existing documentation to it via some /include hooks.
Doxygen does create nice LaTeX, PDF and PS files (see
I absolute despite doxygen based documentation. First of all, pulling
in documentation from comments means that people that want to write
documentation have to find the place of implementation in the file and
also their diffs for documentation will most likely clash with diffs for
implementation.
Secondly doxygen based documentation looks user unfriendly and is not
very helpful for a library like SDL which does not have a terrible high
number of functions.
I strongly prefer documentation structured into ‘tutorial’, ‘prosaic
documentation’, ‘api documentation’.
Regarding documentation I strongly recommend listening to the talk of
Jacob Kaplan Moss about writing great documentation1.
Regards,
Armin
The latest snapshot is now under the zlib license.
http://www.libsdl.org/tmp/SDL-1.3.zip
Cheers! :)On Thu, Apr 7, 2011 at 12:11 PM, Sam Lantinga wrote:
Going forward SDL 1.3 will be under licensing terms that are compatible
with open source and commercial projects, the zlib license:
http://zlib.net/zlib_license.html
Galaxy Gameworks will no longer be selling licenses to SDL, but will
continue to support our existing customers.
SDL development will continue, but will largely be community driven and
Ryan and I will continue to coordinate patch integration and SDL releases.
We will be working to make it easier to contribute in a variety of ways, and
are looking for people interested in helping out.
Oh, and Google Summer of Code is on!
Cheers!
–Sam Lantinga
Secondly doxygen based documentation looks user unfriendly and is not
very helpful for a library like SDL which does not have a terrible high
number of functions.
I strongly prefer documentation structured into ‘tutorial’, ‘prosaic
documentation’, ‘api documentation’.
Take it for what it is. Doxygen is documentation to the code and functions
so that general relationships and short descriptions will help people browse
through the code, i.e. mostly meant for developers. It is not a replacement
for any of the above. All things considered, this is an improvement.
Secondly doxygen based documentation looks user unfriendly and is not
very helpful for a library like SDL which does not have a terrible high
number of functions.
I strongly prefer documentation structured into ‘tutorial’, ‘prosaic
documentation’, ‘api documentation’.
Take it for what it is. Doxygen is documentation to the code and functions
so that general relationships and short descriptions will help people browse
through the code, i.e. mostly meant for developers. It is not a replacement
for any of the above. All things considered, this is an improvement.
SDL is already fairly thoroughly documented with doxygen. The
documentation it produces is HUGE though, so it’s not really hosted
anywhere and you have to generate it yourself.On 8 April 2011 18:18, Patrick Baggett <baggett.patrick at gmail.com> wrote:
Take it for what it is. Doxygen is documentation to the code and functions
so that general relationships and short descriptions will help people browse
through the code, i.e. mostly meant for developers. It is not a replacement
for any of the above. All things considered, this is an improvement.
I love you guys. Really, I do.
Now we just need a C/C++ interpreter for C# to make a port to XBLA…------------------------
EM3 Nathaniel Fries, U.S. Navy
http://natefries.net/
The latest snapshot is now under the zlib license.
http://www.libsdl.org/tmp/SDL-1.3.zip
Cheers! 
COPYING uses the Zlib licence yet README and README-SDL.txt (others may
also) still refer to the library as under LGPL.
LiamOn 8 April 2011 21:32, Sam Lantinga wrote:
Hi,On 4/11/11 2:15 AM, Nathaniel J Fries wrote:
I love you guys. Really, I do.
Now we just need a C/C++ interpreter for C# to make a port to XBLA…
In case unsafe code is allowed there, the .NET version of C++ should do
the trick with a little bit of work.
Regards,
Armin
First of all I want to pass my thanks to Sam for releasing SDL 1.3 under Zlib license, which is really great gift to the community.
Let me put my 2? in Doxygen…
Secondly doxygen based documentation looks user unfriendly and is not
very helpful for a library like SDL which does not have a terrible high
number of functions.
Ruby and Perl are great examples where writing documentation along with the source code can produce good looking readable and clear output.
Moreover describing the code along with the modification is more natural than writing documentation separately from source code, where you are out of the context and which can lead to outdated or irrelevant documentation.
I strongly prefer documentation structured into ‘tutorial’, ‘prosaic
documentation’, ‘api documentation’.
I think you mix an idea of having a tutorial and API reference. The tutorial anyway should be some kind of separate well written document, while API reference intended for daily use should IMHO should stay as it is within the source code - versioned inside HG.
Take it for what it is. Doxygen is documentation to the code and functions so that general relationships and short descriptions will help people browse through the code, i.e. mostly meant for developers. It is not a replacement for any of the above. All things considered, this is an improvement.
This is usually a fault of lazy person describing the code not Doxygen itself. If one is making brief comments for himself only there’s no point of using Doxygen anyway, you may stick with simple /* comments */
Regards,–
Adam Strzelecki