[SDL] Newer LGPL version

Andras Salamon andras at dns.net
Tue Jan 31 00:04:40 PST 2006


On Mon, Jan 30, 2006 at 04:16:56PM -0800, Bill Kendrick wrote:
> (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 at dns.net




More information about the SDL mailing list