Newer LGPL version

Hello !

What does the change to a newer
LGPL version means for the
Developers and the Users ?

CU

Hello !

What does the change to a newer
LGPL version means for the
Developers and the Users ?

Oh, sorry, I forgot to mention… it explicitly states that linking
to a shared library is a way of meeting the requirements of section
6 in the LGPL, so you don’t need to provide source or object code
separately. It’s what the SDL license page has said for years,
but it’s explicitly stated in the license now.

-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

Hello !

What is for example if i develop commercial software
on an Embedded Device and use for example a
commercial compiler + other commercial libs + SDL ?

Is that possible or not ?

It is really a shame that the SDL developers cannot say
hey we allow static linking on embedded devices or on
devices where shared link. is not possible.

CU

What is for example if i develop commercial software
on an Embedded Device and use for example a
commercial compiler + other commercial libs + SDL ?

Let me preface this with: "I am not a lawyer"
It seems to me like this is fine, as long as you provide any pieces
which are not publicly available.

It is really a shame that the SDL developers cannot say
hey we allow static linking on embedded devices or on
devices where shared link. is not possible.

You can static link as much as you like, provided you adhere
to the LGPL license.

-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

Hello !

You can static link as much as you like, provided you adhere
to the LGPL license.

I would like to ask every
contributer to the SDL and helper libs. :

Please write an email to me, if it would be okay for
you to allow staticlinking on devices systems where shared
linking is not possible and only there.

Please mail it to me directly, to not spam the mailinglist.

CU

I would like to ask every
contributer to the SDL and helper libs. :

Please write an email to me, if it would be okay for
you to allow staticlinking on devices systems where shared
linking is not possible and only there.

You realize, it’s perfectly legal to staticly link an LGPL library, right?
If you’re asking for special permission to use SDL under different licensing
terms, then you’ll have to contact every single person who’s contributed to
the SDL codebase. You’ll be sifting through a lot of e-mail to find that. :slight_smile:

-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

Hello !

What is for example if i develop commercial software
on an Embedded Device and use for example a
commercial compiler + other commercial libs + SDL ?

I am not a layer, but here is how I whould do it: Build
the game as a library (that includes other commercial
libraries that is included) so that to build the game
you perform

ld libgame.a libSDL.a libother-lgpl-libraries.a -o game

as the final step. Then to comply with LGPL all you need
is make libgame.a available.

It is really a shame that the SDL developers cannot say
hey we allow static linking on embedded devices or on
devices where shared link. is not possible.

It’s mostly a guideline and not a rule. In fact, if you
build from the source distribution you get both static
and dynamic libraries by default.On Mon, 30 Jan 2006, Torsten Giebl wrote:

Hello !

You realize, it’s perfectly legal to staticly link an LGPL library,
right?

Yes.

If you’re asking for special permission to use SDL under different
licensing terms, then you’ll have to contact every single person who’s
contributed to the SDL codebase. You’ll be sifting through a lot of
e-mail to find that. :slight_smile:

You started this question and
i think it is important to do it.
It is like &&. When i get one false email,
i can kick the rest :slight_smile:

CU

Hello !

Yes, you can statically link. No, I do not give you permission to use
SDL under other licensing terms.

You understand me wrong, you should not give me anything.
I wanted just to restart that discussion.

Please don’t. There’s nothing wrong with statically linking SDL
in an embedded environment, as long as you provide the object files
for someone to relink the library with your application, if they
have a development environment.

If you have a legitimate reason to request different redistribution
terms, then that’s fine.

-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

I distribute statically linked binaries for convenience, but this is on
a project that’s entirely BSD licensed. Source and build environment
is always freely available. Is this acceptable?On 1/30/06, Sam Lantinga wrote:

Hello !

Yes, you can statically link. No, I do not give you permission to use
SDL under other licensing terms.

You understand me wrong, you should not give me anything.
I wanted just to restart that discussion.

Please don’t. There’s nothing wrong with statically linking SDL
in an embedded environment, as long as you provide the object files
for someone to relink the library with your application, if they
have a development environment.

The issue is, I think the LGPL says you need to provide a means for people
to re-link a statically-linked application.

So for example, if I were to use SDL on one of these BREW phones, I’d
need to (1) provide the object – that’s fine, but (2) provide the tools
to re-link (which I cannot legally do, since Qualcomm controls theme[*]).

And even then, the end user will have no way of uploading the new app
to the phone, since their carrier controls that. :^/

So what I think Torsten (and others) are asking for is a 'work-around’
to the following clause in 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.

… here, one would need to provide the proprietary compilers/linkers …

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 this case, if it were an executable for a GNU/Linux desktop or
server system, for example, it’s fine to not provide anything, since
the tools typically come as part of the platform …

… in the case of something like BREW, where only licensed developers can
create software, which is then only ever distributed by the wireless carriers,
the phone does not have compilers/linkers installed :^) …

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.

… and finally, ouch

Ob Disclaimer: I am not a lawyer, and I haven’t examined much beyond
LGPL Section 6 in recent weeks…

[*] Ok, in the BREW example, I think ARM GCC can work, but pretend it can’t.
;^)On Tue, Jan 31, 2006 at 12:02:32AM +0100, Torsten Giebl wrote:

Hello !

You realize, it’s perfectly legal to staticly link an LGPL library,
right?

Yes.


-bill! Tux Paint 2006 wall calendar,
bill at newbreedsoftware.com CDROM, bumper sticker & apparel
http://www.newbreedsoftware.com/ http://www.cafepress.com/newbreedsw

Well, says you, Sam. :^) But that seems to contradict the actual license.

(Specifically, you saying “as long as you provide the object
files … /if they/ have a development environment” (emphasis added),
whereas the LGPL says “the ‘work that uses the Library’ /must/ include
any data and utility programs needed for reproducing the executable
from it.”)

So, in other words, Sam says it’s okay to release executable, as long
as an object is made available for re-linking to SDL, even if the end
users can’t do squat with them.

But the LGPL says that if you release an executable, you have to
provide both the object and the means for re-linking, if they don’t
come standard with the OS.

Sorry to keep on it, but I just want to make sure Sam understands what
Torsten and others (including me!) seem to be concerned about. :^)
I’ll shut up now. :)On Mon, Jan 30, 2006 at 03:49:23PM -0800, Sam Lantinga wrote:

Please don’t. There’s nothing wrong with statically linking SDL
in an embedded environment, as long as you provide the object files
for someone to relink the library with your application, if they
have a development environment.


-bill! Tux Paint 2006 wall calendar,
bill at newbreedsoftware.com CDROM, bumper sticker & apparel
http://www.newbreedsoftware.com/ http://www.cafepress.com/newbreedsw

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 this case, if it were an executable for a GNU/Linux desktop or
server system, for example, it’s fine to not provide anything, since
the tools typically come as part of the platform …

… in the case of something like BREW, where only licensed developers can
create software, which is then only ever distributed by the wireless carriers,
the phone does not have compilers/linkers installed :^) …

Ah, I read it thus:
"the materials to be distributed need not include anything that is
normally distributed with the major components"
With the compiler listed as one of the major components of the system,
I assumed that “normally distributed” to mean “normally distributed as
part of the development environment”.

For example, you might provide your object files to a Windows user,
but if they don’t have a development environment installed it wouldn’t
do them any good at all. However, if they do have a compiler, then
they should be able to use it to relink the files you provide with a
custom version of SDL.lib

If you linked with a proprietary library that prohibited redistribution,
that wasn’t normally distributed with the development environment, then
of course you would be unable to comply with the LGPL, and would have to
request alternative licensing terms.

As far as being unable to re-deploy a modified executable, well…
I’m not sure whether that’s relevant. Does anyone know of a legal
precedent?

-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

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 this case, if it were an executable for a GNU/Linux desktop or
server system, for example, it’s fine to not provide anything, since
the tools typically come as part of the platform …

… in the case of something like BREW, where only licensed developers can
create software, which is then only ever distributed by the wireless carriers,
the phone does not have compilers/linkers installed :^) …

Ah, I read it thus:
"the materials to be distributed need not include anything that is
normally distributed with the major components"
With the compiler listed as one of the major components of the system,
I assumed that “normally distributed” to mean “normally distributed as
part of the development environment”.

Ah, ok, understood.

> As far as being unable to re-deploy a modified executable, well... > I'm not sure whether that's relevant. Does anyone know of a legal > precedent?

I know some DVRs use Linux. (e.g., TiVo) The Nokia 770 handheld
device includes SDL. Of course, that’s way closer to a desktop system
than a BREW cellphone is (since you can really hack the hell out of it
as an end user).On Mon, Jan 30, 2006 at 05:41:06PM -0800, Sam Lantinga wrote:


-bill! Tux Paint 2006 wall calendar,
bill at newbreedsoftware.com CDROM, bumper sticker & apparel
http://www.newbreedsoftware.com/ http://www.cafepress.com/newbreedsw

(Specifically, you saying “as long as you provide the object
files … /if they/ have a development environment” (emphasis added),
whereas the LGPL says “the ‘work that uses the Library’ /must/ include
any data and utility programs needed for reproducing the executable
from it.”)

You have a point, the LGPL does not seem specific enough about this
point to avoid all legal risk (though I’m not a lawyer). However, the
business risk seems quite low – it seems to me that the intent is clear
enough that the weight of evidence would favour Sam’s interpretation.
In addition, I’m sure a maliciously litiguous customer could find clauses
in any text to use as a basis for litigation – this specific clause
does not seem to me to especially increase that risk.

“Utilities” to me seems to indicate preprocessor scripts, special
instructions (like the exact sequence of commands required to produce a
statically linked executable, often this is non-trivial) or makefiles,
but excludes the development environment or the operating system required
to run the dev tools.

Note the text explicitly says: “need not include anything that is normally
distributed […] with the major components (compiler, kernel, and so on)
of the operating system on which the executable runs”. To my mind, the
intent here is clear, the complete system envisaged contains dev tools.
If someone has chosen to only buy or install an incomplete system that
doesn’t include dev tools, then the LGPL doesn’t seem to have anything
to say about the situation.

But the LGPL says that if you release an executable, you have to
provide both the object and the means for re-linking, if they don’t
come standard with the OS.

The standard operating system for someone seeking to recompile an
executable includes as “major components” the “compiler” as well as
the OS platform to run those tools. You can’t really separate the dev
tools from the OS, and to me the LGPL seems to envision the complete
development system – it explicitly mentions the compiler as a major
component of the operating system being envisaged.

In my experience, the existence of such arguments indicates: 1) the
text is leaving some things ambiguous that really should be defined, 2)
in a dispute, any decent lawyer will argue for the interpretation of the
text that favours their client, and 3) a dispute is unlikely to produce
a conclusive result.

If someone is worrying about the ambiguity possibly giving enough leeway
for a litiguous customer to drag them into court, then they should chat
to the FSF and explain their concern, that the LGPL could reasonably be
interpreted to require free distribution of proprietary development tools
and operating systems, or at least forcing the use of free dev tools,
so that the next version of the licence text can clarify their intent.
Arguing with the SDL developers about such fine legal points is not
likely to yield the desired outcome, I doubt any of the subscribers to
this mailing list have either the time or the inclination to optimize
the licence text.

(My response in the body of this email is hereby placed in the public
domain. Feel free to use it to brief lawyers, construct arguments,
to email the FSF, or for any other purpose.)

– Andras Salamon @Andras_SalamonOn Mon, Jan 30, 2006 at 04:16:56PM -0800, Bill Kendrick wrote: