About lciense

SDL Development
1

Hi!

I agree with Sam: it’s enough for embedded system, but it’s also a MUST.
For example I hardly wait to see a Symbian port of SDL. In symbian it is
possible to dynamic link, but with a lot of restrictions (no global
variables!) But if would allow static linking, that would solve a lot of
problems.

So I vote for the new license :wink:

And I also plan to work on the symbian version (I have 3 symbian phones
to test on: Nokia 3650, Nokia 6600 and SE P800) I already developed some
sort of cross platform API, but I would prefer SDL (it’s more mature).–
Best regards,
Szasz Pal

Space Software Studio
http://www.spacesoftwarestudio.com
-------------- next part --------------
A non-text attachment was scrubbed…
Name: space.vcf
Type: text/x-vcard
Size: 192 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20051028/61b8a4f7/attachment.vcf

2

Symbian falls into the same category as Windows, Linux and OSX - it is
possible for the user to relink your application. Symbian SDK is
freely (as in beer) available and the user has the option to swap
binaries in the phone.

You don’t need proposed license change for Symbian. Symbian is in no
way similar to platforms like Playstation or BREW.On 10/28/05, Szasz Pal wrote:

Hi!

I agree with Sam: it’s enough for embedded system, but it’s also a MUST.
For example I hardly wait to see a Symbian port of SDL. In symbian it is
possible to dynamic link, but with a lot of restrictions (no global
variables!) But if would allow static linking, that would solve a lot of
problems.

3

Symbian falls into the same category as Windows, Linux and OSX - it is
possible for the user to relink your application. Symbian SDK is
freely (as in beer) available and the user has the option to swap
binaries in the phone.

You don’t need proposed license change for Symbian. Symbian is in no
way similar to platforms like Playstation or BREW.

Ok, but only if I provide the object files so the user can relink my
application with SDL, which I don’t want to :-)–
Best regards,
Szasz Pal

Space Software Studio
http://www.spacesoftwarestudio.com
-------------- next part --------------
A non-text attachment was scrubbed…
Name: space.vcf
Type: text/x-vcard
Size: 192 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20051028/6d71d939/attachment.vcf

4

maybe you misunderstood … the idea was to dual license in the case of
embedded systems only … “normal”, i.e. windows/linux desktop systems, will
still use the current LGPL
-mikeOn Fri, Oct 28, 2005 at 10:18:15AM +0300, Szasz Pal wrote:

So I vote for the new license :wink:

5

Ok, but only if I provide the object files so the user can relink my
application with SDL, which I don’t want to :slight_smile:

THIS is EXACTLY what we have been protected from for years under the
good old LGPL.

Personally I am shocked any of you are condoning this license change,
which is of questionable legality to begin with. (Although I would
never be so foolish as to attribute the right/wrongness of an action by
whether or not it was legal.)On Oct 28, 2005, at 1:30 PM, Szasz Pal wrote:

6

Ok, but only if I provide the object files so the user can relink my
application with SDL, which I don’t want to :slight_smile:

Ah, but you must under the LGPL. You don’t need to provide them in the
application package, but you must provide them upon demand, if requested
by the end user of your application.

-Sam Lantinga, Software Engineer, Blizzard Entertainment
7

I’m curious, who’s to say which environments are ‘exempt’ from the LGPL,
and fall under the alternate license?

Would Sam (or someone) “bless” particular platforms (e.g., BREW), and
list them somewhere (in the license and/or libsdl.org website)?

And in that case, I suppose we’d want some kind of form, or other way of
submitting a request, for when new platforms come out.

And what happens when/if a platform ‘opens up’, later down the road?
(Say suddenly all owners of BREW phones now have a way to upload apps
directly, rather than purchasing them over-the-air… how will that affect
the license?)On Fri, Oct 28, 2005 at 06:40:09PM +0000, Mike Frysinger wrote:

maybe you misunderstood … the idea was to dual license in the case of
embedded systems only … “normal”, i.e. windows/linux desktop systems, will
still use the current LGPL

–
-bill!
bill at newbreedsoftware.com
http://www.newbreedsoftware.com/

8

But you have to, or you’re using the wrong library. Perhaps there’s
something nice and expensive and commerical that you could license? ;^)

(And, unless Symbian becomes one of the LGPL-exempt platforms that SDL’s
proposed ‘other license’ allows static linking without providing obj and/or
source, it will continue to be that way.)

-bill!On Fri, Oct 28, 2005 at 08:30:08PM +0300, Szasz Pal wrote:

Ok, but only if I provide the object files so the user can relink my
application with SDL, which I don’t want to :slight_smile:

9

And do you really want to “reward” those platforms that don’t allow the
user any real freedom with the special ability to obscure SDL in their
apps, while those platforms that do give their users at least some level
of freedom of usability are more restricted?

This is sounding more and more like a bad idea to me.On Fri, Nov 04, 2005 at 12:51:52PM -0800, Bill Kendrick wrote:

I’m curious, who’s to say which environments are ‘exempt’ from the LGPL,
and fall under the alternate license?

Would Sam (or someone) “bless” particular platforms (e.g., BREW), and
list them somewhere (in the license and/or libsdl.org website)?

And in that case, I suppose we’d want some kind of form, or other way of
submitting a request, for when new platforms come out.

And what happens when/if a platform ‘opens up’, later down the road?
(Say suddenly all owners of BREW phones now have a way to upload apps
directly, rather than purchasing them over-the-air… how will that affect
the license?)

–
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/20051104/b9e1f0b4/attachment.pgp

10

Hrm, interesting point. I guess my concern is more for SDL than whether
’platforms’ (as some kind of entities) are ‘rewarded’ or not.
(Unfortunately, we as both developers and consumers have an uphill battle
convincing the platform makers to change their ways. And as a consumer,
it’s hard for me to go to a Verizon store and ask for a NON-BREW phone,
for example. :^) )

I don’t see SDL itself being adversely affected. My reasoning:

  • Updates/ports/bugfixes made to SDL get it running on another platform
    will still get distributed upstream.

    It won’t matter whether the SDL-using apps themselves conform to the
    LGPL (static link with obj and/or src, or dyn. link) or to this 'new’
    license Sam is considering proposing.

  • SDL, as an LGPL’d license, never forced developers to release their
    source code to begin with.

    I can just as easily create closed source apps while adhering to the LGPL
    (e.g., a closed source game for Windows which dynamically links),
    as I could with the proposed new license (e.g., a closed source game that
    can only be purchased Over The Air for some BREW game, where I cannot
    provide an object).

Of course, thinking about it more, I’m beginning to wonder myself if a
new license is truly necessary. I can simply release an ARM “.O” file of
an SDL-using BREW app. The end user can download it off a website (or I
could mail them a disc), but it will be impossible for them to do anything
with it.

Whether or not they can use it in a particular environment isn’t my issue.
LGPL states:

Preamble:

“If you link other code with the library, you must provide complete
object files to the recipients, so that they can relink them with the
library after making changes to the library and recompiling it. And
you must show them these terms so they know their rights.”

Section 6a:

“… if the work is an executable linked with the Library, 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. …”

If they have the expensive developer tools, a contract with Qualcomm,
a proper USB cable, and have had their phone ‘test-enabled’, they
"can relink". If not, I don’t think it’s my problem.

I guess the biggest issue, at least that I see on something like a phone,
is including the entire text of the LGPL for them to read. :^/

So anyway, have I confused the issue enough now? ;^) Sorry!On Fri, Nov 04, 2005 at 04:27:49PM -0500, Steaphan Greene wrote:

And do you really want to “reward” those platforms that don’t allow the
user any real freedom with the special ability to obscure SDL in their
apps, while those platforms that do give their users at least some level
of freedom of usability are more restricted?

–
-bill!
bill at newbreedsoftware.com
http://www.newbreedsoftware.com/

11

Of course, thinking about it more, I’m beginning to wonder myself if a
new license is truly necessary. I can simply release an ARM “.O” file
of
an SDL-using BREW app.

If they have the expensive developer tools, a contract with Qualcomm,
a proper USB cable, and have had their phone ‘test-enabled’, they
"can relink". If not, I don’t think it’s my problem.

Wrong. You selectively quoted the LGPL. The LGPL makes it your problem.
Also from section 6:

" 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 materials to be 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."

In other words, you MUST give the end user all tools necessary to link
your object files, and the only reason that’s not commonly done on
Linux, for example, is because those tools are normally normally
distributed with Linux systems.

This is one of my biggest issues with the LGPL: almost no one who uses
it actually understands what it says. You see so many projects online
go through a similar process: They license their work under the LGPL,
and then months later realize the LGPL wasn’t actually quite what they
thought it was. I would make a completely anecdotal and unverifiable
guess that most projects which select the LGPL intend their users to be
able to statically link without restriction, and don’t understand that
the LGPL forbids that.

  • Mike BenfieldOn Nov 4, 2005, at 5:31 PM, Bill Kendrick wrote:
12

Hello !

I think we should use the FLTK solution
for embedded plattforms and for plattforms
where only static linking is possible
and ask all the developers if they can
live with this solution.

CU

13

" 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 materials to be 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."

In other words, you MUST give the end user all tools necessary to link
your object files, and the only reason that’s not commonly done on
Linux, for example, is because those tools are normally normally
distributed with Linux systems.

Last time I checked, 0 compilers come with a default install of windows.

Wouldn’t this make a lot of SDL-using software on windows violate the LGPL?On Fri, 04 Nov 2005, Michael Benfield wrote:

–
Any sufficiently advanced incompetence is indistinguishable from malice.
- Vernon Schryver

14

Last time I checked, 0 compilers come with a default install of
windows.

Wouldn’t this make a lot of SDL-using software on windows violate the
LGPL?

I’ve thought about this before and I believe that technically, yes,
they are violating the LGPL. But, it’s not likely to get them in much
trouble because suitable compilers are readily and freely available and
if someone did come knocking on the door demanding the necessary tools
the developer could just hand him mingw or whatever. This is completely
different from these embedded platforms where the developer cannot
provide the user with the necessary tools.

  • Mike BenfieldOn Nov 4, 2005, at 7:36 PM, Jesse Meyer wrote:
15

Jesse Meyer wrote:

" 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 materials to be 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."

In other words, you MUST give the end user all tools necessary to link
your object files, and the only reason that’s not commonly done on
Linux, for example, is because those tools are normally normally
distributed with Linux systems.

Last time I checked, 0 compilers come with a default install of windows.

Wouldn’t this make a lot of SDL-using software on windows violate the LGPL?

No. Again, the passage quoted is taken from Section 6 of LGPL. Section 6
deals with static linking exception, and most SDL-using software on Windows
links to the SDL.dll (and thus dynamically, see Section 5 for that).

-Alex.

16

Last time I checked, 0 compilers come with a default install of
windows.

Wouldn’t this make a lot of SDL-using software on windows violate the
LGPL?

I’ve thought about this before and I believe that technically, yes,
they are violating the LGPL. But, it’s not likely to get them in much
trouble because suitable compilers are readily and freely available and
if someone did come knocking on the door demanding the necessary tools
the developer could just hand him mingw or whatever. This is completely
different from these embedded platforms where the developer cannot
provide the user with the necessary tools.

Unless, of course, they use compiler-specific code and it won’t compile
with another compiler…

I suspect that more of a few projects would have this problem.
Especially projects that rely heavily on tricks and assembly code for
performance.

Just my $.02On Fri, 04 Nov 2005, Michael Benfield wrote:

On Nov 4, 2005, at 7:36 PM, Jesse Meyer wrote: