License question

Sorry if this has been covered before, but…

From the SDL webpage:------------------------------------
Embedded Use:
Personally, I don’t have a problem with anybody statically linking SDL
for use with embedded environments that don’t already have an open
development environment. (i.e. the users can’t relink programs anyway)
However, this does technically violate the LGPL, so be cautioned.

What do you think the chances of getting the SDL copyright holder to
make this an official exception in the SDL’s LGPL license (like eCos has
its its GPL)?
As it stands, the SDL stock LGPL renders at least the Symbian
version academic, as there is no way to comply with the license other
than to only give out the source, and require end-users compile their
own binary.

Thanks,
Pat

There are lots of copyright holders, and each would have to be contacted.
I doubt it’d be possible. (Given Sam’s blunt “no” responses to this type
of thing in the past, I’m sure he isn’t going to try, but he can speak
for himself).

This is a major reason I’m dropping SDL, myself; “you can probably get
away with it” really isn’t good enough. (For example, a hostile company
could buy out the copyright stake of any substantial SDL contributor and
sue five years down the line–and that’s not far-fetched at all.)On Tue, Jul 27, 2004 at 08:15:18PM -0700, Patrick Roberts wrote:

From the SDL webpage:

Embedded Use:
Personally, I don’t have a problem with anybody statically linking SDL
for use with embedded environments that don’t already have an open
development environment. (i.e. the users can’t relink programs anyway)
However, this does technically violate the LGPL, so be cautioned.

What do you think the chances of getting the SDL copyright holder to
make this an official exception in the SDL’s LGPL license (like eCos has
its its GPL)?


Glenn Maynard

I doubt it’d be possible. (Given Sam’s blunt “no” responses to this
type of thing in the past, I’m sure he isn’t going to try, but he can
speak for himself).

There is another excellent incentive for Sam et. al. to visit the
license issue. (not going into why this is and flame-bait GPL history)
The GPL and LGPL do not indemnify copyright holders from each other’s
infringements, or the infringements of contributors not asserting
copyright. This basically means that if someone contributes code that
infringes on, or violates a copyright or a patent, all copyright holders
can be held accountable and sued… which would probably happen in this
order: Person/company most prominent balanced with least able to defend
themselves, person/company with deepest pockets.

So many people are contributing to SDL, that Sam et. al. would be
wise to protect themselves from suit-happy companies so they don’t get
burned for someone else’s infringement.

(as it’s become netiquette not to encourage GPL/LGPL debates, I’ll offer
my private email address as an avenue if you’d like to discuss or flame
me: artix[at]pacbell.net)

Digging into it a bit…

It looks like there are only 6 people asserting copyright other than
Sam : Carsten Griwodz, Jason Evans, Hsieh-Fu Tsai, and Greg Haerr,
Christian Nentwich, and Jonathan Matthew. The last two are only for the
hermes port.

Work contributed by others are freed from copyright controll except
for an obsolete linux thread file that has the © assigned to the FSF,
but it can probably be removed as it looks like it was needed for
versions of gcc prior to v2.

This is a major reason I’m dropping SDL, myself; “you can probably get
away with it” really isn’t good enough. (For example, a hostile
company could buy out the copyright stake of any substantial SDL
contributor and sue five years down the line–and that’s not
far-fetched at all.)

That’s unfortunate, but I understand. The GPL and LGPL were born at
a time when commercial developers were at odds with freeware developers.
Luckily things have started changing and commercial developers are
beginning to choose to spend their time improving open, community-based
software so that everyone benefits, rather than creating a proprietary
solution.

Glenn Maynard wrote:> On Tue, Jul 27, 2004 at 08:15:18PM -0700, Patrick Roberts wrote:

From the SDL webpage:

Embedded Use:
Personally, I don’t have a problem with anybody statically linking SDL
for use with embedded environments that don’t already have an open
development environment. (i.e. the users can’t relink programs anyway)
However, this does technically violate the LGPL, so be cautioned.

What do you think the chances of getting the SDL copyright holder to
make this an official exception in the SDL’s LGPL license (like eCos has
its its GPL)?

There are lots of copyright holders, and each would have to be contacted.
I doubt it’d be possible. (Given Sam’s blunt “no” responses to this type
of thing in the past, I’m sure he isn’t going to try, but he can speak
for himself).

(as it’s become netiquette not to encourage GPL/LGPL debates, I’ll offer
my private email address as an avenue if you’d like to discuss or flame
me: artix[at]pacbell.net)

Er, your From: header does work … :slight_smile:

(Of course, there are those brain-damaged mail archives that remove all
email addresses, but I’d hope there’s a sane archive for this list …)

It looks like there are only 6 people asserting copyright other than
Sam : Carsten Griwodz, Jason Evans, Hsieh-Fu Tsai, and Greg Haerr,
Christian Nentwich, and Jonathan Matthew. The last two are only for the
hermes port.

You don’t have to assert copyright to hold copyright; I’m pretty sure
failure to list yourself in the © does not void your copyright (though
I believe it used to). (TINLA, etc.)

Work contributed by others are freed from copyright controll except
for an obsolete linux thread file that has the © assigned to the FSF,
but it can probably be removed as it looks like it was needed for
versions of gcc prior to v2.

You’re claiming contributed work is in the public domain? IANAL, but I’m
quite sure this isn’t true. If you have real evidence for this, though,
I’d be interested in hearing it (in private–OT), since it’s not something
I’ve heard claimed before.On Tue, Jul 27, 2004 at 10:11:40PM -0700, Patrick Roberts wrote:


Glenn Maynard

(probably only last paragraph is interesting if you’re not Glenn :wink:

Glenn Maynard wrote:

You don’t have to assert copyright to hold copyright; I’m pretty sure
failure to list yourself in the © does not void your copyright (though
I believe it used to). (TINLA, etc.)

As I understand (so conjecture :stuck_out_tongue: as the GPL/LGPL has no precedents),
if you contribute work the © assignment in the file stands as the
copyright control… this is how people can submit minor enhancements
and bug-fixes to FSF-owned software and the FSF still holds copyright on
the work without an explicit reassignment of copyright. (i.e.
“Everything in this file belongs to me unless it says so otherwise at
some location” …which is part of the indemnification problem.)

If you contribute significant work in a separate (or well-defined
area of a) file, that work can be © by the contributor. However, not
having a © notice is in violation of the LGPL, which must be able to
eat the other licenses. Looking through the files, I didn’t find any
that did not have a © notice… but I didn’t manually look at each,
just a ‘find’ and some grepping.

Work contributed by others are freed from copyright controll except
for an obsolete linux thread file that has the © assigned to the FSF,
but it can probably be removed as it looks like it was needed for
versions of gcc prior to v2.

You’re claiming contributed work is in the public domain?

Some of it is public domain, like:

----------snip-----------
/* File “FastTimes.c” - Original code by Matt Slot /
/
Created 4/24/99 - This file is hereby placed in the public domain

----------snip-----------

Some other files are under licenses that free the owner from copyright
control (i.e. you can relicense my code however you want), like:

----------snip------------
/* $Xorg: panoramiXext.h,v 1.4 2000/08/18 04:05:45 coskrey Exp $ /
/
****************************************************************
Copyright © 1991, 1997 Digital Equipment Corporation, Maynard,
Massachusetts. Permission is hereby granted, free of charge, to any
person obtaining a copy of this software and associated documentation
files (the “Software”), to deal in the Software without restriction,
including without limitation the rights to use, copy, modify, merge,
publish, distribute, sublicense, and/or sell copies of the Software.
----------snip-------------

There’s always the possibility of creating a clean “sister” library,
say, for embedded device development, that could be compatible with
relevant SDL modules, but under a license more compatible with embedded
platforms. If Sam isn’t either interested or able to update the
license, this is a direction I’m leaning (eSDL?).

Any thoughts?

This is a major reason I’m dropping SDL, myself; "you can probably get

What are you using instead?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Patrick Roberts wrote:
| As it stands, the SDL stock LGPL renders at least the Symbian version
| academic, as there is no way to comply with the license other than to
| only give out the source, and require end-users compile their own binary.

Nah, I’m sure there’s nothing in the LGPL against providing a binary, so
long as you also provide the source.

Chris E.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBB2Y9RgD2xPOqY+URArr9AJ9uwFmo9gVH43a1Rc97HoAEJsNNcgCgstFK
uyDcBGuZYjRd2oNfkKPJw7I=
=yU+o
-----END PGP SIGNATURE-----

I tried to reply to this privately, but got bounced:

: host pbimaild.prodigy.net[207.115.57.15] said: 550 5.0.0
Access denied To request removal, send the complete error message,
including your ip addresses, in an E-mail to removeme at sbc.sbcglobal.net
(in reply to MAIL FROM command)

prodigy/pacbell/swbell seems to run a broken spam filter, which prevents me
from mailing you. (If I were you, I’d get a new email provider; there’s
no excuse for a major ISP summarily bouncing legitimate mails. That’s
exactly why I run my own SMTP–to prevent incompetent netadmins from making
me lose mail and never even know it. :slight_smile:

All griping about pacbell aside, do you have an alternate email address?On Wed, Jul 28, 2004 at 12:50:33AM -0700, Patrick Roberts wrote:

(probably only last paragraph is interesting if you’re not Glenn :wink:


Glenn Maynard

(For example, a hostile company
could buy out the copyright stake of any substantial SDL contributor and
sue five years down the line–and that’s not far-fetched at all.)

That statement is false. Code under the GPL/LGPL/BSD/[probably others] license remains under that license for ever. People owning the copyright on a part of the code have the right to relicense that part of the code as they wish, but that changes nothing for the project this code is in. With SDL, the code that’s in SDL remains under LGPL for ever, and people have the right to reuse it in other projects under the LGPL license.

But of course, if they wish, people having the copyright on some parts of the code are allowed to use the parts they’ve written under another license (even make it closed source) in another project. That’s what happened to tuxracer after version 0.61 : up to 0.61, tuxracer was GPL, but after 0.61 almost all the contributors agreed on making the code closed source, and the parts written by people disagreeing with this change were removed. Tuxracer now has a closed source version, but the GPL version 0.61 still legally exists under the GPL, although it’s not really maintained AFAIR. But if someone wanted to continue it, they would be allowed to under the terms of the GPL.

Do you imagine the trouble if each free software project contributor could sue each project they contributed to ?

Stephane

You missed the context of the thread, which is releasing binaries for
architectures where users can’t relink binaries, which is in violation
of the LGPL.

Sam says that he doesn’t mind. That’s good to know, but it’s still not
safe; the only thing that would make it safe would be a statement from
all SDL copyright holders, explicitly granting permission.

Even if I’m sure that none of those copyright holders are going to sue me,
that’s not enough. I don’t actually have permission, so if copyright
changes hands for any reason down the road, I could find myself with a
lawsuit by the new copyright holder, who may not be so generous.

(It may sound paranoid, but unfortunately paranoia is the only approach
to copyright permissions that might keep you safe. :)On Wed, Jul 28, 2004 at 11:34:37AM +0200, Stephane Marchesin wrote:

(For example, a hostile company
could buy out the copyright stake of any substantial SDL contributor and
sue five years down the line–and that’s not far-fetched at all.)

That statement is false. Code under the GPL/LGPL/BSD/[probably others] license remains under that license for ever. People owning the copyright on a part of the code have the right to relicense that part of the code as they wish, but that changes nothing for the project this code is in. With SDL, the code that’s in SDL remains under LGPL for ever, and people have the right to reuse it in other projects under the LGPL license.


Glenn Maynard

As I understand (so conjecture :stuck_out_tongue: as the GPL/LGPL has no precedents),
if you contribute work the © assignment in the file stands as the
copyright control… this is how people can submit minor enhancements
and bug-fixes to FSF-owned software and the FSF still holds copyright on
the work without an explicit reassignment of copyright. (i.e.
“Everything in this file belongs to me unless it says so otherwise at
some location” …which is part of the indemnification problem.)

No, people contributing to GNU projects are required to assign their copyright to the FSF so that FSF is legally allowed to defend itself/attack projects infringing its GPL code (only the copyright owner is allowed to go to a trial, so that if the GNU software didn’t use that copyright scheme, individual copyright owners would have to defend themselves, which would be troublesome for individuals against a huge company).

Well, if you don’t understand the licensing problems, the gnu.org site has a fun quizz :
http://www.gnu.org/cgi-bin/license-quiz.cgi
You can learn lots of things with this.

Stephane

(For example, a hostile company
could buy out the copyright stake of any substantial SDL contributor and
sue five years down the line–and that’s not far-fetched at all.)

That statement is false. Code under the GPL/LGPL/BSD/[probably others] license remains under that license for ever. People owning the copyright on a part of the code have the right to relicense that part of the code as they wish, but that changes nothing for the project this code is in. With SDL, the code that’s in SDL remains under LGPL for ever, and people have the right to reuse it in other projects under the LGPL license.

You missed the context of the thread, which is releasing binaries for
architectures where users can’t relink binaries, which is in violation
of the LGPL.

Well, then why not simply release your .o files ? That’s ok with the LGPL since it allows relinking, and that’s ok with you since it allows you to keep your source code secret.

Stephane> On Wed, Jul 28, 2004 at 11:34:37AM +0200, Stephane Marchesin wrote:

Chris E. wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Patrick Roberts wrote:
| As it stands, the SDL stock LGPL renders at least the Symbian version
| academic, as there is no way to comply with the license other than to
| only give out the source, and require end-users compile their own binary.

Nah, I’m sure there’s nothing in the LGPL against providing a binary, so
long as you also provide the source.

The LGPL issue with Symbian (and some other embedded OSes) is that
they only allow static linking.> Chris E.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBB2Y9RgD2xPOqY+URArr9AJ9uwFmo9gVH43a1Rc97HoAEJsNNcgCgstFK
uyDcBGuZYjRd2oNfkKPJw7I=
=yU+o
-----END PGP SIGNATURE-----


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

Hmm… I’m supposed to have all pacbell’s spam filtering turned off.

Can you try:

proberts9999[at]yahoo.com (which has spam filtering)

or if that doesn’t work, as a last resort:

proberts[at]anim.dreamworks.com

sorry about that-
Pat

Glenn Maynard wrote:> On Wed, Jul 28, 2004 at 12:50:33AM -0700, Patrick Roberts wrote:

(probably only last paragraph is interesting if you’re not Glenn :wink:

I tried to reply to this privately, but got bounced:

<@Patrick_Roberts>: host pbimaild.prodigy.net[207.115.57.15] said: 550 5.0.0
Access denied To request removal, send the complete error message,
including your ip addresses, in an E-mail to removeme at sbc.sbcglobal.net
(in reply to MAIL FROM command)

prodigy/pacbell/swbell seems to run a broken spam filter, which prevents me
from mailing you. (If I were you, I’d get a new email provider; there’s
no excuse for a major ISP summarily bouncing legitimate mails. That’s
exactly why I run my own SMTP–to prevent incompetent netadmins from making
me lose mail and never even know it. :slight_smile:

All griping about pacbell aside, do you have an alternate email address?

Stephane Marchesin wrote:

(For example, a hostile company
could buy out the copyright stake of any substantial SDL contributor and
sue five years down the line–and that’s not far-fetched at all.)

That statement is false. Code under the GPL/LGPL/BSD/[probably others] license remains under that license for ever. People owning the copyright on a part of the code have the right to relicense that part of the code as they wish, but that changes nothing for the project this code is in. With SDL, the code that’s in SDL remains under LGPL for ever, and people have the right to reuse it in other projects under the LGPL license.

You missed the context of the thread, which is releasing binaries for
architectures where users can’t relink binaries, which is in violation
of the LGPL.

Well, then why not simply release your .o files ? That’s ok with the LGPL since it allows relinking, and that’s ok with you since it allows you to keep your source code secret.

It’s not an issue of closed-source, it is a problem even with
GPL/LGPL covered programs.

With a number of embedded OSes, the end user is not able to compile
or relink, and the OS doesn’t dynamically link. For example: If you
create a program for SymbianOS, the average user does not have the
ability to compile and link source. It would be nice to give them a
working version; otherwise, the software created is useless to the vast
majority of users. In order to do that, you must create a statically
linked executable. Because the statically linked version contains both
non-GPL/LGPL-compatible code from Symbian (and potentially other
companies involved in the OS), it violates the LGPL. More problems
arise when the running OS differs significantly from the development OS,
as is the case with most embedded OSes. Even if you can dynamically
link, it may require pre-linking with code not provided standard with
the OS, which violates the GPL/LGPL. (Because the GPL was created with
Unix-ish OSes in mind, the FSF could not have reasonably predicted this
problem, so it’s not their fault. They can take pride in that their
software ideology has been so widely embraced beyond its original intent.)

The Java community has been arguing something similar with the FSF.
They’ve been asking the FSF to re-word part of the GPL to allow for the
way the Java VM works. (Something like all GPL Java violates the GPL.)
When the GPL was created, the FSF could not have reasonably predicted
the problem. However, it has been up to individual authors to create
exclusions because, unfortunately, the FSF’s official response has been
that Sun should put Java under the GPL.>>On Wed, Jul 28, 2004 at 11:34:37AM +0200, Stephane Marchesin wrote:

Stephane


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

Patrick Roberts wrote:

Well, then why not simply release your .o files ? That’s ok with the
LGPL since it allows relinking, and that’s ok with you since it
allows you to keep your source code secret.

It’s not an issue of closed-source, it is a problem even with
GPL/LGPL covered programs.

With a number of embedded OSes, the end user is not able to compile
or relink, and the OS doesn’t dynamically link. For example: If you
create a program for SymbianOS, the average user does not have the
ability to compile and link source. It would be nice to give them a
working version; otherwise, the software created is useless to the
vast majority of users.

Hmm, if you distribute the .o files, you can do that alongside with the
static binaries. See the LPGL, article 6 a) it says <<Accompany the work
[…] 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.>>

The only trouble is, as you said, when the build environment is
proprietary. That’s really a gray area I wouldn’t venture in :slight_smile:

Sorry if I’m too off topic, if you feel that discussion should go away,
don’t hesitate to make your voice heard :slight_smile:

Stephane

For those bleeding from the ears wanting the license discussion to go
away, have no fear: I’m going to be out of town for almost a week. :slight_smile:
I think this is reasonably on-topic, though, since it’s important that
users of SDL understand the restrictions its license places on them.On Wed, Jul 28, 2004 at 12:05:41PM +0200, Stephane Marchesin wrote:

Well, then why not simply release your .o files ? That’s ok with the LGPL since it allows relinking, and that’s ok with you since it allows you to keep your source code secret.

To be clear, the type of systems we’re talking about are proprietary
embedded systems; you typically have to pay to get access to software
(and sometimes hardware) to build binaries. The problem is that in
order to satisfy this requirement, you’d have to include both .o
files (for your stuff) and .a/.lib files for the system libraries
being used.

However, these are commercial libraries; the licenses very often prohibit
redistribution of those development libraries on their own, requiring
that they only be redistributed as part of a built and stripped binary,
or even requiring explicit approval before any kind of distribution.

The most relevant example for people here is probably gaming consoles,
most of which are in this category, for example. The desire to be able to
port software to those should be understandable by most people with vague,
hopeful aspirations of making money from a game some day. :slight_smile:


Glenn Maynard

Stephane Marchesin wrote:

With a number of embedded OSes, the end user is not able to compile
or relink, and the OS doesn’t dynamically link. For example: If you
create a program for SymbianOS, the average user does not have the
ability to compile and link source. It would be nice to give them a
working version; otherwise, the software created is useless to the
vast majority of users.

Hmm, if you distribute the .o files, you can do that alongside with the
static binaries. See the LPGL, article 6 a) it says <<Accompany the work
[…] 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.>>

The only trouble is, as you said, when the build environment is
proprietary. That’s really a gray area I wouldn’t venture in :slight_smile:

The problem comes with the end of 6:

-----snip-----
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. However, as a special exception, the
source code distributed need not include anything that is normally
distributed (in either source or binary form) with the major components
(compiler, kernel, and so on) of the operating system on which the
executable runs, unless that component itself accompanies the executable.
-----snip-----

Even for systems with an open development system, such as Symbian
has, the exe author may not have the right to redistribute all the files
needed for another person to build the code. It could be anything from
header files all the way up to the actual compiler, considering neither
is distributed with the run-time OS.

I think what both Glenn and I were hoping for is an official clearing
up of the gray area you mention that goes with Sam’s (?) note on SDL
embedded system use:

-----snip-----
Embedded Use:
Personally, I don’t have a problem with anybody statically linking SDL
for use with embedded environments that don’t already have an open
development environment. (i.e. the users can’t relink programs anyway)
However, this does technically violate the LGPL, so be cautioned.
-----snip-----

Sorry if I’m too off topic, if you feel that discussion should go away,
don’t hesitate to make your voice heard :slight_smile:

I think this is an appropriate thread, but then I’ve only been here
for a few days. I was going to port SDL to a new platform, but soon
realized that the license would prohibit anyone from ever creating a
program usable by anyone other than developers. First and foremost,
however, I feel it is most important to respect the intent with which
the author released the code into the community.

I’m ecstatic the discussion has been professional. It seem like
anytime I’ve seen a license thread that involves the GPL/LGPL, it’s
quickly turned angry and religious. I think this speaks volumes to the
caliber of the SDL developers and users on this list.

-Pat> Stephane


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

The only trouble is, as you said, when the build environment is
proprietary. That’s really a gray area I wouldn’t venture in :slight_smile:

It’s really not a gray area: distributing static binaries without including
the object files necessary to rebuild is in unambiguous violation of the
license, unless an exception is granted (which it hasn’t been).

Even for systems with an open development system, such as Symbian
has, the exe author may not have the right to redistribute all the files
needed for another person to build the code. It could be anything from
header files all the way up to the actual compiler, considering neither
is distributed with the run-time OS.

A relevant case like this is gaming consoles, where you’d need to include
used system libraries (.a/.lib), and you usually aren’t alowed to distribute
those outside of an approved, stripped final binary.

I think what both Glenn and I were hoping for is an official clearing
up of the gray area you mention that goes with Sam’s (?) note on SDL
embedded system use:

While I think it would be nice, I don’t think it’s going to happen, and
I’m not going to bother Sam about it. I’m just making sure that the
implications of the license are known.On Wed, Jul 28, 2004 at 08:07:52PM -0700, Patrick Roberts wrote:


Glenn Maynard

Glenn Maynard wrote:

The only trouble is, as you said, when the build environment is
proprietary. That’s really a gray area I wouldn’t venture in :slight_smile:

It’s really not a gray area: distributing static binaries without including
the object files necessary to rebuild is in unambiguous violation of the
license, unless an exception is granted (which it hasn’t been).

Even for systems with an open development system, such as Symbian
has, the exe author may not have the right to redistribute all the files
needed for another person to build the code. It could be anything from
header files all the way up to the actual compiler, considering neither
is distributed with the run-time OS.

A relevant case like this is gaming consoles, where you’d need to include
used system libraries (.a/.lib), and you usually aren’t alowed to distribute
those outside of an approved, stripped final binary.

Heya,

may I drop in for a moment. The exclusion clause for system libraries and
compiler headers is a relict of the (plain) GPL. RMS (Stallman) has remarked
some of the time to prefer a clean gpl’ed environment from the first bios
byte to the widest pixel applications. But at the time of the project creation
there was no free operating system, so in order to make it possible, an
exception was included. - The problem here comes from the fact that those
unixes of that time had been shipping along with a compiler and headers as
a free part of the operating system environment. This is untrue for symbian
platforms where the runtime environment and the development kit are two
distinct things to pay for (but one is usually available for a mere user). So
literally you would be allowed to write programs that run on the symbian development kit system and not on the mere runtime environment. Oh boy.
(in other words, if you sell the development kit alongside your programs then
this is fine, or only to those who already have it, even when not used at runtime).

I think what both Glenn and I were hoping for is an official clearing
up of the gray area you mention that goes with Sam’s (?) note on SDL
embedded system use:

While I think it would be nice, I don’t think it’s going to happen, and
I’m not going to bother Sam about it. I’m just making sure that the
implications of the license are known.

The GPL is about to protect the rights of the final user, to modify and relink
the program at will, and the LGPL has the viral effect removed. Most developers
are more in the thinking of protecting their own rights, so modifications (and
usage) are not kept away in the dark - which is side effect of the LGPL
restrictions, and which BSD-style licenses can not ensure (see WINE problems).
Many of the embedded uses are very near of hiding away stuff, but some are
not, and the LGPL does not cover those. Bad Luck. Since I was approached quite
often to allow staticlinking of zziplib.sf.net, I did once make an official exception
but finally I came around to publish under a dual LGPL/MPL license - where the
MPL restrictions are sometimes seen to be gpl-incompatible (more restrictive)
but at the very same time the additional options (less restrictive) are themselves
filling the holes of where I think usage is absolutely correct. And like LGPL, the
license is backed by major entities.

That’s one way of approaching the problem. As for SDL, people could contact
their lawyer about Sam’s statement, since a public connotation is as good as
a formal clarification in most cases, as long as it would seem to the reader
that he speaks in the name of (all/the) copyright holder. The FUD of someone
coming later in, buying everything out and sueing the a** off anyone being free
to use it earlier, that’s in real not working. Even sco has been failing in such
areas (as for the unix trademark) already. In doubt it would be failure of the
prior owners and not that of the one who took the offer. And really, you could
even use a silent acceptance buy posting publically announcements of your
work everywhere that would reach the SDL copyright holders and see them
not veto about you saying “I’m not shipping the development kit which would
be needed to relink”.

btw, what about doing a formal clarification that a development kit is fine
when speaking about the runtime target platform free usage? That would
not include static linking with third party closed libraries or something like
that, just the system compiler stuff needed to fill in the relink clause. Would
that be sufficient for you?

cheers,
– guido http://google.de/search?q=guidod
GCS/E/S/P C++/++++$ ULHS L++w- N++@ s+:a d(±) r+@>+++ y++

Excerpt from MPL:
3.2. Availability of Source Code.
Any Modification which You create or to which You contribute must be
made available in Source Code form under the terms of this License
either on the same media as an Executable version or via an accepted
Electronic Distribution Mechanism to anyone to whom you made an
Executable version available; and if made available via Electronic
Distribution Mechanism, must remain available for at least twelve (12)
months after the date it initially became available, or at least six
(6) months after a subsequent version of that particular Modification
has been made available to such recipients. You are responsible for
ensuring that the Source Code version remains available even if the
Electronic Distribution Mechanism is maintained by a third party.> On Wed, Jul 28, 2004 at 08:07:52PM -0700, Patrick Roberts wrote: