Possible SDL license terms change?

I’m not 100% sure that this is the right place to ask about this. If
not, someone please point me in the right direction.

I was just wondering if there was any chance at all of changing the
terms under which SDL is licensed to allow for static linking. For
example, the OCaml libraries are distributed under the LGPL with the
following statement added:

"As a special exception to the GNU Library General Public License, you
may link, statically or dynamically, a “work that uses the Library"
with a publicly distributed version of the Library to produce an
executable file containing portions of the Library, and distribute
that executable file under terms of your choice, without any of the
additional requirements listed in clause 6 of the GNU Library General
Public License. By “a publicly distributed version of the Library”,
we mean either the unmodified Library as distributed by INRIA, or a
modified version of the Library that is distributed under the
conditions defined in clause 3 of the GNU Library General Public
License. This exception does not however invalidate any other reasons
why the executable file might be covered by the GNU Library General
Public License.”

The wxWidgets GUI library and other works are distributed under similar
terms.

The logic is that the purpose of distributing a work under the LGPL is
to fulfill two goals:

  1. Keep the original work itself and versions of it free
  2. Allow other works to link with the original work and be distributed
    under other terms

Prohibiting static linking does not help goal #1 and hinders goal #2.

So, is there any chance whatsoever of a similar clause being added to
SDL’s licensing terms?

Thanks,
Mike Benfield

Quoth Michael Benfield , on 2004-08-06 23:58:16 -0400:

The logic is that the purpose of distributing a work under the LGPL is
to fulfill two goals:

  1. Keep the original work itself and versions of it free
  2. Allow other works to link with the original work and be distributed
    under other terms

I can’t speak for the original author(s), of course, but you may have
missed one:

  1. Permit all users of said other works to replace the library component
    only, in a reasonable manner

which is not compatible with permitting statically-linked-only
distribution. Distributing statically-linked binaries along with
dynamically-linked ones seems like it should be okay, though; I’m not
sure about that.

So, is there any chance whatsoever of a similar clause being added to
SDL’s licensing terms?

As a practical matter, there have, IINM, been many contributors to
SDL. All of them would have to agree to any change in license, so it
may be a bit late to change the terms now.

IANAL and IANTO. Take this post with a pile of salt.

—> Drake Wilson
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20040807/341c6952/attachment.pgp

The big issue that’s been brought up lately (I think in regards to
Symbian OS, or something?) is that in some environments, applications
must be statically linked, and the channel by which the software is
installed makes it impossible for the end user to upgrade the libraries,
regardless as to whether the app is statically or dynamically linked.

Through my new job, I’m familiar with Qualcomm’s BREW setup. It’s an API
(libraries for doing junk like drawing, playing MIDI and MP3, setting
timers, and doing menus and input; much like SDL or, I imagine, Qt/GTK+/etc.)

It’s also a distribution channel. It goes like this:

  1. Company produces game
  2. Qualcomm tests & (hopefully) approves
  3. Wireless providers (like Verizon) (hopefully) accept game
  4. Consumers on that carrier notice the game in their “Get It Now!” menu
    and (hopefully) decide to purchase
  5. Game is downloaded over the air
  6. User is billed automatically in their next statement (or something)

Now, if one were to use an LGPL’d library (like SDL) within the app,
since the only way to produce the app is by statically linking [*],
one would need to provide the “object” version, in case the users
(“consumers” in steps 4 and 6, above) want to upgrade their library.

But, uh… how do they upgrade? How do they relink? They won’t have
the proprietary tools needed to build/link the app in the first place,
let alone any MEANS to getting the app ONTO the phone! :^(

Sucks, but that’s how it works, some times.

Now, I’m not arguing that “SDL should just change its license”,
since obviously I understand all of the copyright holders involved
would need to agree. However, it is definitely an issue (or can be),
and I want to help to make sure everyone out there (most of whom are
no doubt coming from the Linux/Windows/Mac worlds) understand.

I should go check the Lua license. I know it was used in “Defender” on the
PlayStation 2, and obviously there’s no way for me to upgrade my copy of
Lua and burn a new disc. ;^)

Have I used enough parenthesis? (I think so ;^) )

-bill!

[*] At least, so far as I know of, in BREW. Perhaps there’s something
like “ldopen()”, but I doubt it. And even so, I can imagine something
like this happening elsewhere, even if my BREW example isn’t 100%
accurate :^)On Sat, Aug 07, 2004 at 01:00:25AM -0400, Drake Wilson wrote:

  1. Permit all users of said other works to replace the library component
    only, in a reasonable manner

which is not compatible with permitting statically-linked-only
distribution. Distributing statically-linked binaries along with
dynamically-linked ones seems like it should be okay, though; I’m not
sure about that.

I should go check the Lua license. I know it was used in “Defender” on the
PlayStation 2, and obviously there’s no way for me to upgrade my copy of
Lua and burn a new disc. ;^)

Lua is under the permissive MIT license; it’s essentially “do whatever you
want, just don’t remove this license”. It’s the license I prefer to use for
my own work. (That’s one major reason I like Lua, Ogg, libpng, libjpeg–they
have no-nonsense, no-time-wasted licenses.)

  1. Company produces game
  2. Qualcomm tests & (hopefully) approves
  3. Wireless providers (like Verizon) (hopefully) accept game
  4. Consumers on that carrier notice the game in their “Get It Now!” menu
    and (hopefully) decide to purchase
  5. Game is downloaded over the air
  6. User is billed automatically in their next statement (or something)

[*] At least, so far as I know of, in BREW. Perhaps there’s something
like “ldopen()”, but I doubt it. And even so, I can imagine something
like this happening elsewhere, even if my BREW example isn’t 100%
accurate :^)

Most commercial gaming consoles have this problem. They’re all heavily
controlled by their respective massive company–it’s usually #2 or #3
above that’s going to be a showstopper, before you even get to the fact
that end users usually don’t have access to SDKs, development hardware, etc.

As I said earlier, I’m not really out to lobby for a license change, since
Sam has made it pretty clear that it’s not going to happen. I just want to
make sure people spending time making a game are aware that, if they have
the opportunity to sell their game, the LGPL may be a hurdle causing some
boring and time-wasting code rewrites down the road.On Fri, Aug 06, 2004 at 10:38:02PM -0700, Bill Kendrick wrote:


Glenn Maynard

We just had a similar thread on this regarding embedded OSes. It’s
probably in the archive if you have any interest reading all of it, but
here’s a summary:----

Sam's notice saying he doesn't care about static linking does not 

exempt static linking from violating the license.

Because of the number of contributors to SDL, it is not easy or may 

not even be possible to add an exemption to the SDL to allow it to be
compatible with static linking and/or systems that use a separate dev
and runtime environment.


As a result, I suggested that a SDL compatible library be created
which is targeted to embedded devices (emSDL) and under a more
embedded-friendly license. There were a few others on the list that had
some interest in this idea.

I’ve sent Sam an email explaining what would be created with the goal
of getting his support for the project. I’ve also started to adapt
some software I wrote for another project to create a generic link
configuration GUI.

If Sam supports the project, I’ll set up a public development area
and a mailing list for interested parties to discuss design. Sam
supporting the project will also allow for the project to use a Logo
derived from the SDL logo.

If Sam doesn't support the project... we'll, I haven't thought that 

far yet. Hopefully he does.

-Pat

Michael Benfield wrote:

I’m not 100% sure that this is the right place to ask about this. If
not, someone please point me in the right direction.

I was just wondering if there was any chance at all of changing the
terms under which SDL is licensed to allow for static linking. For
example, the OCaml libraries are distributed under the LGPL with the
following statement added:

"As a special exception to the GNU Library General Public License, you
may link, statically or dynamically, a “work that uses the Library"
with a publicly distributed version of the Library to produce an
executable file containing portions of the Library, and distribute
that executable file under terms of your choice, without any of the
additional requirements listed in clause 6 of the GNU Library General
Public License. By “a publicly distributed version of the Library”,
we mean either the unmodified Library as distributed by INRIA, or a
modified version of the Library that is distributed under the
conditions defined in clause 3 of the GNU Library General Public
License. This exception does not however invalidate any other reasons
why the executable file might be covered by the GNU Library General
Public License.”

The wxWidgets GUI library and other works are distributed under similar
terms.

The logic is that the purpose of distributing a work under the LGPL is
to fulfill two goals:

  1. Keep the original work itself and versions of it free
  2. Allow other works to link with the original work and be distributed
    under other terms

Prohibiting static linking does not help goal #1 and hinders goal #2.

So, is there any chance whatsoever of a similar clause being added to
SDL’s licensing terms?

Thanks,
Mike Benfield


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

Glenn Maynard <g_sdl at zewt.org> wrote:

Most commercial gaming consoles have this problem. They’re all
heavily controlled by their respective massive company–it’s usually
#2 or #3
above that’s going to be a showstopper, before you even get to the
fact that end users usually don’t have access to SDKs, development
hardware, etc.

As I said earlier, I’m not really out to lobby for a license change,
since Sam has made it pretty clear that it’s not going to happen. I
just want to make sure people spending time making a game are aware
that, if they have the opportunity to sell their game, the LGPL may be
a hurdle causing some boring and time-wasting code rewrites down the
road.

yes, but lets remember what the purpose of GPL and LGPL is in the
first place. the GPL makes sure software, using it, is free for all
time. the LGPL has been invented to get things going, when the free
software movement wasn’t that popular. it’s some kind compromise between
supporting the LGPLed software and endorsing proprietary programms.

adding exceptions to the LGPL leads to even more “unfree” software. what
is not our intention, is it? :wink:

best regards …
clemens

yes, but lets remember what the purpose of GPL and LGPL is in the
first place. the GPL makes sure software, using it, is free for all
time. the LGPL has been invented to get things going, when the free
software movement wasn’t that popular. it’s some kind compromise
between
supporting the LGPLed software and endorsing proprietary programms.

adding exceptions to the LGPL leads to even more “unfree” software.
what
is not our intention, is it? :wink:

This is certainly the attitude of Richard Stallman and the GNU people.
But quite frankly I don’t believe that this is the attitude of the
large majority of free software developers. Most free software
developers are NOT against proprietary commercial software. They may
hate Microsoft or whatever else, but they do not believe that it should
be impossible to distribute software without source code and under
restrictive licensing terms and make a profit. It’s certainly not the
attitude of Sam Lantinga, because he himself used SDL to work on
proprietary software, and in fact is making proprietary software right
now! So I don’t think the primary author of SDL has a problem with SDL
being used in more unfree software.

I think most people who use the LGPL don’t think about all the
ramifications. All they know is they want non-free or
differently-licensed software to be able to use their software, but
they want their own software to remain free.

I used to be a big GNU fan and loved the GPL. Since then, experience
has shown me on several occasions what a HUGE PAIN the GNU licenses can
be for everyone involved.

Mike Benfield

I understand this, but in some cases, the architecture on which we wish
to take advantage of OSS (e.g., libSDL) restricts us in ways not accounted-for
in the LGPL, sadly. :^/

Such is life in the cellphone game industry, I guess. :wink:

-bill!
bill at newbreedsoftware.com "Avoid missing ball for high score"
http://www.newbreedsoftware.com/
New Breed SoftwareOn Sat, Aug 07, 2004 at 06:19:10PM +0200, Clemens Kirchgatterer wrote:

adding exceptions to the LGPL leads to even more “unfree” software. what
is not our intention, is it? :wink:

Well, thanks everyone for your help.

I guess there’s not much chance of this happening.

If anyone’s interested in my specific issue, I’m looking to develop a
multi-platform commercial game in OCaml that will be distributed over
the internet. I will be quitting my job and depending on this game to
make a living. And I really feel like the more hurdles you make the
average, non-programmer, non-especially technically competent end user
go through, the less likely he is to try your product. ie, for every
little thing, like an extra download, or a larger download, or
whatever, you potentially lose a crapload of customers.

SDL being under the LGPL is actually not the end of the world. I could
distribute SDL in the same download as my game and it wouldn’t cause
the user any great pain (except a slightly larger download, as if it
were statically linked it would include only the parts of SDL I need to
be included). But there is an OCaml binding for SDL already that is
under the LGPL. But the OCaml native code compiler can only statically
link with OCaml code! So unless they will change their license (I’ve
already contacted them), their library is for all intents and purposes
under the GPL, not the LGPL.

It seems to me that the LGPL always (and the GPL sometimes) has
ramifications and restrictions that prevent stuff that the copyright
holder would actually like to allow.

Mike Benfield

I tend to release under the GPL or LGPL but suggest that proprietary
developers contact me if they want/need different terms.

Chris E.
-------------- next part --------------
A non-text attachment was scrubbed…
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20040807/f7b3387c/attachment.pgp

Err, does this also mean that when you distribute a game for Linux/i386
that you have to make sure the recipient also gets gcc? No, I don’t
think so.

Isn’t it enough to just distribute the object files and let the users
take the burden of getting the extra libs and compilers and hardware to
upload the app to the phone? Where does it say it has to be you who has
to make sure they can do it?On Sat, 2004-08-07 at 08:38, Bill Kendrick wrote:

Now, if one were to use an LGPL’d library (like SDL) within the app,
since the only way to produce the app is by statically linking [*],
one would need to provide the “object” version, in case the users
(“consumers” in steps 4 and 6, above) want to upgrade their library.

But, uh… how do they upgrade? How do they relink? They won’t have
the proprietary tools needed to build/link the app in the first place,
let alone any MEANS to getting the app ONTO the phone! :^(

Sucks, but that’s how it works, some times.


Petri Latvala

take the burden of getting the extra libs and compilers and hardware to
upload the app to the phone? Where does it say it has to be you who has
to make sure they can do it?

From section 6 of the LGPL:

" For an executable, the required form of the “work that uses the
Library” must include any data and utility programs needed for
reproducing the executable from it…

It may happen that this requirement contradicts the license
restrictions of other proprietary libraries that do not normally
accompany the operating system. Such a contradiction means you cannot
use both them and the Library together in an executable that you
distribute."

-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: text/enriched
Size: 838 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20040807/90ddf29a/attachment.bin

Err, does this also mean that when you distribute a game for Linux/i386
that you have to make sure the recipient also gets gcc? No, I don’t
think so.

by the way, the reason you don’t have to make sure the recipient gets
gcc is because of the exception in the LGPL that I skipped over.
Namely, that if the necessary tools are normally distributed as part of
the OS, you don’t need to bother distributing them yourself. That’s
clearly not the case in the environment the previous person was talking
about though.

Mike Benfield

Okay, so it really means you have to distribute gcc with the app, and
make/scons/jam/whatever. And it also means LGPL isn’t as free as the
majority thinks.On Sat, 2004-08-07 at 22:11, Michael Benfield wrote:

" For an executable,the required form of the “work that uses the
Library” must include anydata and utility programs needed for
reproducing the executable fromit…

It may happen thatthis requirement contradicts the license
restrictions of otherproprietary libraries that do not normally
accompany the operatingsystem. Such a contradiction means you cannot
use both them and theLibrary together in an executable that you
distribute."


Petri Latvala

Damn me for replying in a haste. Please disregard the other reply.On Sat, 2004-08-07 at 22:14, Michael Benfield wrote:

by the way, the reason you don’t have to make sure the recipient gets
gcc is because of the exception in the LGPL that I skipped over.
Namely, that if the necessary tools are normally distributed as part of
the OS, you don’t need to bother distributing them yourself. That’s
clearly not the case in the environment the previous person was talking
about though.


Petri Latvala

I was just wondering if there was any chance at all of changing the
terms under which SDL is licensed to allow for static linking. For
example, the OCaml libraries are distributed under the LGPL with the
following statement added:

God, not this discussion again! This is like the third time this week.

SDL is so emcumbered by third party contributors that we could never
weed out, let alone track down, every single one of them.

This means:

  1. We spend several months hunting people down, posting their names on a
    public website as a “bounty” and Googling for them. Mozilla did this
    when switching licenses and it took a long time. This presumes we have
    clear logs as to exactly what was contributed by who.

  2. We start over and reimplement SDL from scratch. Rewriting code just
    because the perfectly fine open source code doesn’t have the perfect
    license is a total waste of time in my opinion. Even if #1 was wildly
    successful, we’d still end up doing at least a little of this.

I did this for PhysicsFS, which only had a handful of external
contributors, all of which were well-documented and eager to switch from
LGPL to the zlib license…and it still sucked to get it all in order.
I imagine doing the same for SDL would take a full time administrative
position several months or more to sort it out and decide what code can
stay and what needs to be rewritten.

Sam doesn’t seem to care if you statically link SDL in an embedded
system, but it’s not entirely his call. You probably won’t have
problems, but no legal department would give you the go-ahead to use it
in a commercial product in this manner.

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.

–ryan.

user any great pain (except a slightly larger download, as if it were
statically linked it would include only the parts of SDL I need to be
included).

Please note that the vast majority of SDL can be chopped out at
configure time…i.e. - if you don’t want the DirectFB driver, or, say,
the entire audio subsystem, you can make sure they aren’t in the library
in the first place.

It seems to me that the LGPL always (and the GPL sometimes) has
ramifications and restrictions that prevent stuff that the copyright
holder would actually like to allow.

This is probably exactly why the Free Software Foundation won’t accept
patches from you unless you sign over your copyright. :slight_smile:

–ryan.

Er: http://www.gnu.org/licenses/why-assign.htmlOn Mon, Aug 09, 2004 at 12:28:54AM -0400, Ryan C. Gordon wrote:

This is probably exactly why the Free Software Foundation won’t accept
patches from you unless you sign over your copyright. :slight_smile:


Glenn Maynard

God, not this discussion again! This is like the third time this week.

Sorry. It had occurred to me this may have been discussed before but I
had to ask.

Rewriting code just because the perfectly fine open source code
doesn’t have the perfect license is a total waste of time in my
opinion.

But sometimes it’s not just a matter of convenience, sometimes the
license terms are simply not acceptable.

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.

Or for OCaml, which I want to use, or for who knows how many other
environments that nobody thought of yet. This is why I don’t think the
LGPL is ever appropriate for anything. For people who want their code
to remain GPL, they can use the GPL. For people who want their code to
be able to be used by nonGPL code, there’s the BSD or MIT licenses or
the like. Then there’s the LGPL, which tries to be an in between option
but really just overly complicates things for no real benefit to
anyone.

Anyway, I see that nothing can be done. I’ll look elsewhere.

Thanks.

Mike BenfieldOn Aug 9, 2004, at 12:22 AM, Ryan C. Gordon wrote:

adding exceptions to the LGPL leads to even more “unfree” software. what
is not our intention, is it? :wink:

I understand this, but in some cases, the architecture on which we wish
to take advantage of OSS (e.g., libSDL) restricts us in ways not
accounted-for in the LGPL, sadly. :^/

Such is life in the cellphone game industry, I guess. :wink:

There is a back door in the GPL at least (I’m not quite sure if it’s in the
LGPL, too): The FSF may produce a newer version of the license text, to which
the licensee may upgrade without explicit permission from the copyright
holder.

There is a commentary statement somewhere in the license saying that this
mechanism is intended for the case that new technical situations (e.g. the
cell phone thingie) require an adjustment of the licensing rules.

Maybe you should talk to the FSF and persuade them to considere a new version
of the GPL/LGPL, because SDL is not the only library that’s potentially
hindered.

-bill!
bill at newbreedsoftware.com "Avoid missing ball for high score"
http://www.newbreedsoftware.com/
New Breed Software

GregorOn Saturday 07 August 2004 18:50, Bill Kendrick wrote:

On Sat, Aug 07, 2004 at 06:19:10PM +0200, Clemens Kirchgatterer wrote: