SDL License Change: wxWindows LGPL cont

This is a continuation of my earlier message in regards to a suggested
license change of SDL to a license similar to the wxWindows
(www.wxwindows.org) form of LGPL.

First of all, I apologize for misspelling LGPL in my earlier post and would
like to clarify the distinction between a BSD style license and an LGPL
license with a static object code / embedded use exception. The significant
difference here is that the end developer is still bound by the LGPL. Unlike
BSD, this means that: the end user must still acknowledge using SDL and offer
the SDL source used to compile the software.

Furthermore, I would like to point out that a static linkage exception for
SDL would not stifle the development of SDL, it may in fact prove to have the
opposite effect. There are several good open source game development packages
that currently allow static linkage. These include: CDX (www.cdxlib.com) and
Allegro (http://www.talula.demon.co.uk/allegro/). Both of these game SDKs
have a healthy user group and an excellent set of 3rd party open source
extensions. I personally have written extensions for CDX. I have not
however, and do not intend to produce addons to SDL under its current
licensing agreement. I may be alone in this mindset, but I do not believe so.

I respect the argument that was made for allowing the end user to
reconfigure or update the SDL portion of an application for updated system
compatibility, but the risk I pointed out may be too great. By including 3rd
party data into your system / game, the developer assumes certain
responsibilities to protect that data from all but the most dedicated of
hackers. By choosing to link a program with an SDL open source DLL, the
developer has provided a rather obvious back door to otherwise protected 3rd
party data. Furthermore any court ruling in this matter may not favor the
developer because they chose to use an open source library. The keyword here,
being: chose.

This is not the same as choosing to link with a DirectX dll for instance,
because DirectX cannot be easily recompiled by the end user. The courts would
have to rule wether the developer has taken reasonable encryption precautions
and I think the answer would clearly be: no. The SDL backend is rather
obvious. Any programmer could defeat any encryption the developer offered in
little more than a couple hours. While DirectX / DirectSound hacks exist,
they are certainly less obvious and enough large scale developers use DirectX
that any claims of this sort would likely be thrown out of court. As it was
pointed out, a small developer’s primary interest is providing as few
opportunities to be sued as possible as legal defenses are somewhat
unreasonable.

With the exception of Loki, few commercial game developers bother to
develop for Linux and other “alternative” OSes. SDL provides an opportunuty
to radically change this, but only if it becomes as easy or easier to use as
DirectX without the dynamic linkage issues. As the licensing currently
stands, SDL isn’t worth the time of most large developers. I do not expect
that this issue will be resolved anytime soon but it at least needs to be
addressed. In the mean time, I will continue to develop with CDX and
Allegro. Thankyou for your input.

First of all, I apologize for misspelling LGPL in my earlier post and would
like to clarify the distinction between a BSD style license and an LGPL
license with a static object code / embedded use exception. The significant
difference here is that the end developer is still bound by the LGPL. Unlike
BSD, this means that: the end user must still acknowledge using SDL and offer
the SDL source used to compile the software.

That’s unclear from this:

“Most files are distributed under the GNU Library General Public
License, version 2, with the special exception that you may create and
distribute object code versions built from the source code or modified
versions of it (even if these modified versions include code under a
different licence), and distribute such binaries under your own
terms.”

The intent seems to be to exempt away the LGPL’s requirements in section 6,
so people can distribute programs that statically link to the library
without having to distribute object files or dynamically link.

However, this actually seems to exempt away the requirements in section
4 (making source to the actual library available).

It should probably say something like “… with the special exception
that you may create and distribute works that use the library according
to section 6 of the LGPL without following one of section 6a through
6e”. (Retaining the other requirements of section 6.) IANAL.

It should probably also mention something to the effect of “derived
works of the library may also extend this exemption, but are not
obligated to do so”. That is, make it clear that people are free to
remove the exemption and revert the library back to the clean LGPL.
This makes it clear that there’s no implicit restriction that you can’t
remove the exemption, because such a restriction would render the
library LGPL-incompatible (that is, it would make it impossible to use
SDL code in other LGPL libraries.)

Furthermore, I would like to point out that a static linkage exception for
SDL would not stifle the development of SDL, it may in fact prove to have the
opposite effect. There are several good open source game development packages
that currently allow static linkage. These include: CDX (www.cdxlib.com) and

I personally don’t think a library’s license should make a “dynamically
link or distribute .o’s” requirement. Since it boils down to saying “use
dynamic linking or deal with this large annoyance”, it’s essentially a
requirement to use dynamic linking, and that doesn’t belong in a software
license.

I can live without that requirement in my libraries. Using dynamic
linking is generally a good idea when possible, but it isn’t something
that should be enforced in a license. People with common sense will
still link dynamically when possible, and I’ll still be able to reuse
old binaries later on. If they statically link when they should have
dynamically linked, then their software will be less useful down the
road, not my library; it’s their right to write less useful programs,
after all.

I respect the argument that was made for allowing the end user to
reconfigure or update the SDL portion of an application for updated system
compatibility, but the risk I pointed out may be too great. By including 3rd
party data into your system / game, the developer assumes certain
responsibilities to protect that data from all but the most dedicated of
hackers. By choosing to link a program with an SDL open source DLL, the
developer has provided a rather obvious back door to otherwise protected 3rd
party data. Furthermore any court ruling in this matter may not favor the
developer because they chose to use an open source library. The keyword here,
being: chose.

Hint: you’re not going to convince open source programmers that making
it harder for end users to do things is a good idea. Our principles get
in the way. :slight_smile:

However, you might convince them that giving library users the ability to
statically link without distributing object files (possibly having the
above effect in some cases) is an acceptable tradeoff to encourage the
use of their libraries in embedded environments. I’d focus on that.On Wed, Jan 08, 2003 at 03:19:04PM -0800, mkee at gonzaga.edu wrote:


Glenn Maynard

mkee at gonzaga.edu wrote:

Furthermore, I would like to point out that a static linkage
exception for SDL would not stifle the development of SDL, it may in
fact prove to have the opposite effect. There are several good open
source game development packages that currently allow static linkage.

The LGPL already seems to allow static linkage as long as you provide
the appropriate object and source files so that the user is able to
statically link it with a new version of the library. This is perhaps
because your quote from wxWindows said “GNU -Library- General Public
License” and SDL uses the newer “GNU -Lesser- General Public License”,
which may well have been updated to reflect this type of issue. Open
Source gurus, is this (anything like) right? I do suggest that you check
the differences between the licenses though, just in case there has been
a significant change that renders this discussion obsolete…

In all fairness though, what you have is an ill-thought out law on one
hand that seeks to remove your rights, and a licensing agreement that
seeks to preserve people’s rights on the other hand… it’s not the
licensing agreement that’s the problem, it’s choosing to use media that
is covered by unworkable legislation.

I respect the argument that was made for allowing the end user to
reconfigure or update the SDL portion of an application for updated
system compatibility, but the risk I pointed out may be too great.

If enough people challenge these risks, it makes it easier for such
legislation to be overturned.

By including 3rd party data into your system / game, the developer
assumes certain responsibilities to protect that data from all but
the most dedicated of hackers.

To paraphrase something you said, the key here is that the developer
chose to include that data. You would do better to use content supplied
by people with an ounce of sense, who will already know that no amount
of developer trickery is going to hide those resources adequately.–
Kylotan
http://pages.eidosnet.co.uk/kylotan

[…]

In all fairness though, what you have is an ill-thought out law on one
hand that seeks to remove your rights, and a licensing agreement that
seeks to preserve people’s rights on the other hand… it’s not the
licensing agreement that’s the problem, it’s choosing to use media that
is covered by unworkable legislation.

True. But it’s really tricky to get some kind of OpenSource media. I’m working
as programmer/artist for the WorldForge project, and I can tell you from our
experience that it’s really tricky to a) get media people to get the spirit
of free content and b) find an appropriate license for the media that is
(L)GPL compatible.

[…]

By including 3rd party data into your system / game, the developer
assumes certain responsibilities to protect that data from all but
the most dedicated of hackers.

To paraphrase something you said, the key here is that the developer
chose to include that data. You would do better to use content supplied
by people with an ounce of sense, who will already know that no amount
of developer trickery is going to hide those resources adequately.

Agreed. We’re using a GPL/GFDL dual license model for most of our artwork
right now, but it’s not easy to fulfill requirements. eg. GFDL requires that
the source file is in a “transparent” format, the exact definition of that is
somewhat vague. As far as I can tell it should be a format that is open, so
anybody can have a viewer for it. wav or ogg make this possible for soundfx
and music, but most 3d people work with programs like 3dsmax that have their
own proprietary data formats. and not all standard formats are transparent.
jpeg loses quality, and won’t save image layers, so it’s not transparent.
What I want to say with this somewhat lenghty explanation is: It’s damn hard
to find content with a license that has ‘an ounce of sense’. :slight_smile:

Oh, actually for music and sound, I’d suggest getting stuff that’s covered by
the green openmusic license. It’s GPL-compatible (at least in spirit, didn’t
really hear an official FSF statement about it) and really fit for it’s job.

Cheers, KaiOn Thursday 09 January 2003 01:44, Kylotan wrote:

Kai Blin Linux system administrator Tel: Ring-86592
Allgemeine Chirurgie Universitaetsklinikum Tuebingen

Alas, I am dying beyond my means.
– Oscar Wilde [as he sipped champagne on his deathbed]

xcf (gimp’s native format) is open, except not many viewers support it. It also isnt hard to
make a reader for it. Also, in respect to 3D, 3DS may be proprietary, but there is a library out
there (lib3ds) that can load 3ds files into a format you can dump right into opengl and display
right away. (This doesnt include .max, 3dsmax’s native format) also iirc crystal space has a
loader for lwo, so two common 3D formats are supported. Also, 3dsmax and lightwave both can
do stuff like the “standard” text format (Im not sure how good it is, though) and stuff like id’s
mdl/md2/md3 model mesh formats.

Btw, in a media context, what does GFDL add to just GPLing it?On 10-Jan-2003, Kai Blin wrote:

Agreed. We’re using a GPL/GFDL dual license model for most of our artwork
right now, but it’s not easy to fulfill requirements. eg. GFDL requires that
the source file is in a “transparent” format, the exact definition of that is
somewhat vague. As far as I can tell it should be a format that is open, so
anybody can have a viewer for it. wav or ogg make this possible for soundfx
and music, but most 3d people work with programs like 3dsmax that have their
own proprietary data formats. and not all standard formats are transparent.
jpeg loses quality, and won’t save image layers, so it’s not transparent.
What I want to say with this somewhat lenghty explanation is: It’s damn hard
to find content with a license that has ‘an ounce of sense’. :slight_smile:


Patrick “Diablo-D3” McFarland || unknown at panax.com
"Computer games don’t affect kids; I mean if Pac-Man affected us as kids, we’d
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." – Kristian Wilson, Nintendo, Inc, 1989
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20030111/d3639914/attachment.pgp

xcf (gimp’s native format) is open, except not many viewers support it. It
also isnt hard to make a reader for it. Also, in respect to 3D, 3DS may be

Sure, but I don’t know if there’s a photoshop plugin for xcf out there. Good
thing to start looking for, though. :slight_smile:

proprietary, but there is a library out there (lib3ds) that can load 3ds
files into a format you can dump right into opengl and display right away.
(This doesnt include .max, 3dsmax’s native format) also iirc crystal space
has a loader for lwo, so two common 3D formats are supported. Also, 3dsmax
and lightwave both can do stuff like the “standard” text format (Im not
sure how good it is, though) and stuff like id’s mdl/md2/md3 model mesh
formats.

Yeah, I just don’t know if that counts as transparent…

Btw, in a media context, what does GFDL add to just GPLing it?

It makes the media a set, iirc. So if you use one part of it, you have to
release all of the art. That’s usefull for bundeling models and meshes, etc
:slight_smile: (or so I’ve been told)

Cheers, KaiOn Sunday 12 January 2003 02:19, Patrick McFarland wrote:


Kai Blin Linux system administrator Tel: Ring-86592
Allgemeine Chirurgie Universitaetsklinikum Tuebingen

Don’t put off for tomorrow what you can do today because if you enjoy it
today,
you can do it again tomorrow.

xcf (gimp’s native format) is open, except not many viewers support it. It
also isnt hard to make a reader for it. Also, in respect to 3D, 3DS may be

Sure, but I don’t know if there’s a photoshop plugin for xcf out there. Good
thing to start looking for, though. :slight_smile:

There isnt, and no one knowledgable wants to make one

Btw, in a media context, what does GFDL add to just GPLing it?

It makes the media a set, iirc. So if you use one part of it, you have to
release all of the art. That’s usefull for bundeling models and meshes, etc
:slight_smile: (or so I’ve been told)

You mean the mesh and image maps of a model, right?On 13-Jan-2003, Kai Blin wrote:

On Sunday 12 January 2003 02:19, Patrick McFarland wrote:


Patrick “Diablo-D3” McFarland || unknown at panax.com
"Computer games don’t affect kids; I mean if Pac-Man affected us as kids, we’d
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." – Kristian Wilson, Nintendo, Inc, 1989
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20030113/68d936bd/attachment.pgp