Embedded license? (SDL contributers please read!)

I’m considering providing an alternative SDL license exclusively
for embedded development where the development kits or operating
environment do not lend themselves to the relinking clause of the
LGPL.

The terms of the license would essentially be free use with credit
to the SDL project and a requirement that any modifications to the
library be made available to the product end user.

If there is anyone who has contributed any code or assistance to
the SDL project who is not comfortable with this, please contact
me privately.

Thanks!
-Sam Lantinga, Software Engineer, Blizzard Entertainment_______________________________________________
SDL-announce mailing list
SDL-announce at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl-announce

I’m considering providing an alternative SDL license exclusively
for embedded development where the development kits or operating
environment do not lend themselves to the relinking clause of the
LGPL.

The terms of the license would essentially be free use with credit
to the SDL project and a requirement that any modifications to the
library be made available to the product end user.

If there is anyone who has contributed any code or assistance to
the SDL project who is not comfortable with this, please contact
me privately.

I’ve only made some very minor contributions to the Mac stuff and
some Altivec blitters, but I think this is good. Personally I prefer
MIT/BSD style licenses anyway, so I’m all for anything that makes
choosing SDL easier for any developer regardless of their intent.

-bobOn Oct 24, 2005, at 8:01 PM, Sam Lantinga wrote:

The license is pretty clear IMHO that as long as non-linked binaries
are provided free to the public, then you are not in violation of the
license. That is to say, if I write a proprietary application that uses
SDL, and I want to provide a statically linked binary, that is A-Okay
as long as I also provided a version that is not linked to SDL yet.

Personally it’s important to me that if someone has benefited from the
work of SDL’s contributors, that they also provide their users with the
benefits of being able to link their applications to any version of the
SDL library they like, even long after that person / company stops
supporting that software.On Oct 24, 2005, at 11:01 PM, Sam Lantinga wrote:

I’m considering providing an alternative SDL license exclusively
for embedded development where the development kits or operating
environment do not lend themselves to the relinking clause of the
LGPL.

The terms of the license would essentially be free use with credit
to the SDL project and a requirement that any modifications to the
library be made available to the product end user.

If there is anyone who has contributed any code or assistance to
the SDL project who is not comfortable with this, please contact
me privately.

Thanks!
-Sam Lantinga, Software Engineer, Blizzard Entertainment


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


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

The license is pretty clear IMHO that as long as non-linked binaries
are provided free to the public, then you are not in violation of the
license. That is to say, if I write a proprietary application that uses
SDL, and I want to provide a statically linked binary, that is A-Okay
as long as I also provided a version that is not linked to SDL yet.

The reason for dynamic linking of LGPL code is so the end user can swap
it out with a different version…on embedded devices, you can’t (i.e. -
on a PlayStation 2 game that uses SDL, how would you switch out the
library as an end user? What if your DVR used SDL to draw its program
listings, and you can’t replace the ROM chip that holds the program?).

I think this is what Sam’s looking for. In non-embedded applications,
the usual LGPL would apply as it does now, but he wants to hand-waive
the dynamic linking requirement for just that one instance.

I think this is reasonable, and it’s why I abandoned the LGPL wholesale
for PhysicsFS…people wanted to use it on consoles, and there wasn’t
any reasonable way to do that with the standard LGPL.

–ryan.

The reason for dynamic linking of LGPL code is so the end user can swap
it out with a different version…on embedded devices, you can’t (i.e. -
on a PlayStation 2 game that uses SDL, how would you switch out the
library as an end user? What if your DVR used SDL to draw its program
listings, and you can’t replace the ROM chip that holds the program?).

I think this is what Sam’s looking for. In non-embedded applications,
the usual LGPL would apply as it does now, but he wants to hand-waive
the dynamic linking requirement for just that one instance.

Yup.
-Sam Lantinga, Software Engineer, Blizzard Entertainment

I was curious about SDL on PS2 precisely because of this. I was also
curious about the politics of releasing PS2 source code in an open
source project…or Xbox or PSP or…is it even legal under standard
agreements for the dev-tools?

Just curious.On 10/25/05, Sam Lantinga wrote:

The reason for dynamic linking of LGPL code is so the end user can swap
it out with a different version…on embedded devices, you can’t (i.e. -
on a PlayStation 2 game that uses SDL, how would you switch out the
library as an end user? What if your DVR used SDL to draw its program
listings, and you can’t replace the ROM chip that holds the program?).

I think this is what Sam’s looking for. In non-embedded applications,
the usual LGPL would apply as it does now, but he wants to hand-waive
the dynamic linking requirement for just that one instance.

Yup.
-Sam Lantinga, Software Engineer, Blizzard Entertainment


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


Casey O’Donnell
RPI STS Department - Graduate Student

http://homepage.mac.com/codonnell/
http://homepage.mac.com/codonnell/wxsync/
http://homepage.mac.com/codonnell/wxblogger/

Hello !

I’ve only made some very minor contributions to the Mac stuff and
some Altivec blitters, but I think this is good. Personally I prefer
MIT/BSD style licenses anyway, so I’m all for anything that makes
choosing SDL easier for any developer regardless of their intent.

What would be the difference for
the people using MIT/BSD license
for SDL ?

CU

I’ve only made some very minor contributions to the Mac stuff and some
Altivec blitters, but I think this is good. Personally I prefer
MIT/BSD style licenses anyway, so I’m all for anything that makes
choosing SDL easier for any developer regardless of their intent.

Not to throw this too far off topic, but have you ever had the
experience of contributing code to a project, having a company take that
project and enhance it slightly, then try to charge you for the enhanced
version of your own code? I have:

http://www.transgaming.com/

I was also an XFree86 “developer”… No need to harp on that fiasco.

You need to really be careful with BSD-style licensing, especially now
that free software is so much closer to the cutting edge and multiple
architectures are becoming more common.

I haven’t yet made any major contributions to SDL, but I’d hate to see
it slip any lower than LGPL. I understand the problem with embedded
applications, and, IMHO, certainly something should be arranged for
these cases, as long as it remains in the same spirit. Perhaps the FSF
would like to tackle this issue and come up with a reasonable solution
to this problem for all LGPL projects? Perhaps they have already looked
into this issue before and already have a solution?

I know this is rather empty since I haven’t really contributed yet, but
if SDL were to open itself up to this type of closed-development
hijacking, I certainly would not contribute to it in the future. I’ve
learned my lesson.On Mon, Oct 24, 2005 at 09:15:48PM -0700, Bob Ippolito wrote:


Steaphan Greene
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt
-------------- 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/20051025/523a0f2d/attachment.pgp

I’ve only made some very minor contributions to the Mac stuff and
some
Altivec blitters, but I think this is good. Personally I prefer
MIT/BSD style licenses anyway, so I’m all for anything that makes
choosing SDL easier for any developer regardless of their intent.

Not to throw this too far off topic, but have you ever had the
experience of contributing code to a project, having a company take
that
project and enhance it slightly, then try to charge you for the
enhanced
version of your own code? I have:

http://www.transgaming.com/

I was also an XFree86 “developer”… No need to harp on that fiasco.

You need to really be careful with BSD-style licensing, especially now
that free software is so much closer to the cutting edge and multiple
architectures are becoming more common.

I haven’t yet made any major contributions to SDL, but I’d hate to see
it slip any lower than LGPL. I understand the problem with embedded
applications, and, IMHO, certainly something should be arranged for
these cases, as long as it remains in the same spirit. Perhaps the
FSF
would like to tackle this issue and come up with a reasonable solution
to this problem for all LGPL projects? Perhaps they have already
looked
into this issue before and already have a solution?

I know this is rather empty since I haven’t really contributed yet,
but
if SDL were to open itself up to this type of closed-development
hijacking, I certainly would not contribute to it in the future. I’ve
learned my lesson.

I contribute to open source to save other developers time and to make
it easier to write better software. I don’t care if someone wants to
sell it back to me. I’d buy it if it was a product that I needed,
and a little competition never hurt anyone. If all they did was make
some slight enhancements, it shouldn’t be a big deal to enhance the
open source version and put them out of business with a free product.

I don’t normally contribute to LGPL or GPL projects specifically
because I don’t want developers to be hassled about how and where
they use the code, I just want them to use it. If they want to make
it better and contribute to the project, that’s great, but I don’t
expect them to. Coercing people into contributing via LGPL/GPL
certainly isn’t necessary, because there’s plenty of counter-examples
where less restrictively licensed projects are doing just fine with
plenty of contributors.

Clearly we simply have different ideals, so there isn’t much more to
discuss here between us.

-bobOn Oct 25, 2005, at 12:26 PM, Steaphan Greene wrote:

On Mon, Oct 24, 2005 at 09:15:48PM -0700, Bob Ippolito wrote:

Right. Neither of our viewpoints is right or wrong. They just
represent different opionions. I guess we’ll just agree to disagree
here.On Tue, Oct 25, 2005 at 03:11:49PM -0700, Bob Ippolito wrote:

Clearly we simply have different ideals, so there isn’t much more to
discuss here between us.


Steaphan Greene
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt
-------------- 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/20051025/4d432009/attachment.pgp

I know I only contribute my own experience to the list and irc channel,
but I’d have to say that in my experience dealing with licensing issues
that this is a perfect move for SDL for embedded devices/systems.
GPL/LGPL have some minor restrictions that are no problem to handle when
dealing with PC based distribution, but can rear their ugly heads when
dealing with an embedded environment. Plus, anything that gets SDL more
use and press is always good to hear.

-Elden Armbrust

Sam Lantinga wrote:>>The reason for dynamic linking of LGPL code is so the end user can swap

it out with a different version…on embedded devices, you can’t (i.e. -
on a PlayStation 2 game that uses SDL, how would you switch out the
library as an end user? What if your DVR used SDL to draw its program
listings, and you can’t replace the ROM chip that holds the program?).

I think this is what Sam’s looking for. In non-embedded applications,
the usual LGPL would apply as it does now, but he wants to hand-waive
the dynamic linking requirement for just that one instance.

Yup.
-Sam Lantinga, Software Engineer, Blizzard Entertainment


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

Hello !

Please look at the FLTK project ( http://www.fltk.org ),
they use current LGPL + exceptions for static linking
and it works really good for them.

CU

When I first started using SDL, I thought part of the choice of using
the LGPL license was to help give users of software freedom of choice
of operating system.

If I buy some proprietary software that chose to use SDL as opposed to
DirectX, it’s now significantly easier for that company to offer their
software for platforms not supported by Microsoft.

But more than that, it’s now easier for me to attempt to use the
software on a system not supported by the software’s manufacturer.

SDL’s use of the GNU LGPL license helps to protect my right to choose
an operating system other than Microsoft Windows.

Hello, Sam!

SL> I’m considering providing an alternative SDL license exclusively
SL> for embedded development where the development kits or operating
SL> environment do not lend themselves to the relinking clause of the
SL> LGPL.

SL> The terms of the license would essentially be free use with credit
SL> to the SDL project and a requirement that any modifications to the
SL> library be made available to the product end user.

SL> If there is anyone who has contributed any code or assistance to
SL> the SDL project who is not comfortable with this, please contact
SL> me privately.

I’m as QNX port maintainer completely agree with this idea. It would be nice
! And I’m always trying to publish my code under BSD-style license.

With best regards, Mike Gorchak. E-mail: @Mike_Gorchak

Hello, Sam!

SL> I’m considering providing an alternative SDL license exclusively
SL> for embedded development where the development kits or operating
SL> environment do not lend themselves to the relinking clause of the
SL> LGPL.

SL> The terms of the license would essentially be free use with credit
SL> to the SDL project and a requirement that any modifications to the
SL> library be made available to the product end user.

SL> If there is anyone who has contributed any code or assistance to
SL> the SDL project who is not comfortable with this, please contact
SL> me privately.

I’m as QNX port maintainer completely agree with this idea. It would be
nice ! And I’m always trying to publish my code under BSD-style license.

Sam wants a license where when you modify the code, you have to give back,
just without the linking restrictions. It is way much more close to the
current LGPL than a BSD style.
In fact, all you have to do is to just keep the LGPL license and add an
exception for static linking. Torsten pointed out that FLTK does it, and it
works.

Cheers,
RicardoEm Quinta 27 Outubro 2005 09:07, o Mike Gorchak escreveu:

With best regards, Mike Gorchak. E-mail: lestat at i.com.ua


If God had meant for us to be in the Army, we would have been born with
green, baggy skin.

Hello, Ricardo!

RC> Sam wants a license where when you modify the code, you have to give
RC> back, just without the linking restrictions. It is way much more close
RC> to the current LGPL than a BSD style.
RC> In fact, all you have to do is to just keep the LGPL license and add
RC> an exception for static linking. Torsten pointed out that FLTK does it,
RC> and it works.

Ok, Anyway it is better than the plain LGPL :slight_smile:

With best regards, Mike Gorchak. E-mail: @Mike_Gorchak

I don’t know how similar it is, but wxWidgets also has an exception
for static linking, though it even allows it on non embedded
platforms…so it’s more lenient than even FLTK or the proposed
changes I guess.On 10/27/05, Ricardo Cruz wrote:

In fact, all you have to do is to just keep the LGPL license and add an
exception for static linking. Torsten pointed out that FLTK does it, and it
works.

Hello !

I don’t know how similar it is, but wxWidgets also has an exception
for static linking, though it even allows it on non embedded platforms…so
it’s more lenient than even FLTK or the proposed changes I guess.

Yup, it would be cool to general allow static linking.

CU

That would completely change the whole idea. This would mean you’d be
back to proprietary games just releasing a single binary and if a new
piece of hardware isn’t supported by the statically linked version od
SDL, you are once-again screwed. I think (hope?) that Sam doesn’t want
to see this happen to SDL.On Thu, Oct 27, 2005 at 04:45:44PM +0200, Torsten Giebl wrote:

I don’t know how similar it is, but wxWidgets also has an exception
for static linking, though it even allows it on non embedded platforms…so
it’s more lenient than even FLTK or the proposed changes I guess.

Yup, it would be cool to general allow static linking.


Steaphan Greene
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt
-------------- 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/20051027/5b22e50d/attachment.pgp

Hello !

That would completely change the whole idea. This would mean you’d be
back to proprietary games just releasing a single binary and if a new piece
of hardware isn’t supported by the statically linked version od SDL, you
are once-again screwed. I think (hope?) that Sam doesn’t want to see this
happen to SDL.

Okay, this would be more than Sam wanted, but it would
allow people to choose whether they want to distr. the
binary stat. or dynam. For me it is always good if the coder
has more rights than less.

CU