[Savannah-hackers] LLGPL questions (UFFI & CL-READLINE)

[Loic Dachary]

        Hi,

        I read the LLGPL as published at
http://opensource.franz.com/preamble.html and included at the end of
this mail. Would you be so kind as to clarify a few points and help me
understand it ? I've found hard to figure out if the LLGPL license is
correctly written, from a legal point of view. Since I'm not a lawyer
myself, I usually refer to the conclusions of third party lawyers
to make up my mind but I did not find any about the LLGPL.

        My first question is about the inclusion of the LLGPL. It says
that the preamble takes precedence over the LGPL, therefore I infer
that it intends to modify the terms of the LGPL, if
appropriate. However, the LGPL clearly says that it can only be used
verbatim (Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed). It seems to
me that wrapping it with a "preamble-modifier" has the same effect as
modifying the LGPL itself. Did you discuss this with the FSF ? Did
they approve this specific use of the LGPL ?

        The reason I'm trying to understand the LLGPL is because a
software component (UFFI http://files.b9.com/uffi/uffi-1.2.15.tar.gz)
is being released under the LLGPL and is used by another software
component (CL-READLINE
http://www.niksula.cs.hut.fi/~tsiivola/files/cl-readline-0.1.1.tar.gz)
being released under the Expat License (also known as the MIT
license). I would like to clarify any doubt about the Free Software
status of UFFI so that people can use CL-READLINE in freedom.

        Thanks in advance for your help,

LLGPL ----------------------------------------------------------------------
Preamble to the Gnu Lesser General Public License

Copyright (c) 2000 Franz Incorporated, Berkeley, CA 94704

The concept of the GNU Lesser General Public License version 2.1
("LGPL") has been adopted to govern the use and distribution of
above-mentioned application. However, the LGPL uses terminology that
is more appropriate for a program written in C than one written in
Lisp. Nevertheless, the LGPL can still be applied to a Lisp program if
certain clarifications are made. This document details those
clarifications. Accordingly, the license for the open-source Lisp
applications consists of this document plus the LGPL. Wherever there
is a conflict between this document and the LGPL, this document takes
precedence over the LGPL.

A "Library" in Lisp is a collection of Lisp functions, data and
foreign modules. The form of the Library can be Lisp source code (for
processing by an interpreter) or object code (usually the result of
compilation of source code or built with some other
mechanisms). Foreign modules are object code in a form that can be
linked into a Lisp executable. When we speak of functions we do so in
the most general way to include, in addition, methods and unnamed
functions. Lisp "data" is also a general term that includes the data
structures resulting from defining Lisp classes. A Lisp application
may include the same set of Lisp objects as does a Library, but this
does not mean that the application is necessarily a "work based on the
Library" it contains.

The Library consists of everything in the distribution file set before
any modifications are made to the files. If any of the functions or
classes in the Library are redefined in other files, then those
redefinitions ARE considered a work based on the Library. If
additional methods are added to generic functions in the Library,
those additional methods are NOT considered a work based on the
Library. If Library classes are subclassed, these subclasses are NOT
considered a work based on the Library. If the Library is modified to
explicitly call other functions that are neither part of Lisp itself
nor an available add-on module to Lisp, then the functions called by
the modified Library ARE considered a work based on the Library. The
goal is to ensure that the Library will compile and run without
getting undefined function errors.

It is permitted to add proprietary source code to the Library, but it
must be done in a way such that the Library will still run without
that proprietary code present. Section 5 of the LGPL distinguishes
between the case of a library being dynamically linked at runtime and
one being statically linked at build time. Section 5 of the LGPL
states that the former results in an executable that is a "work that
uses the Library." Section 5 of the LGPL states that the latter
results in one that is a "derivative of the Library", which is
therefore covered by the LGPL. Since Lisp only offers one choice,
which is to link the Library into an executable at build time, we
declare that, for the purpose applying the LGPL to the Library, an
executable that results from linking a "work that uses the Library"
with the Library is considered a "work that uses the Library" and is
therefore NOT covered by the LGPL.

Because of this declaration, section 6 of LGPL is not applicable to
the Library. However, in connection with each distribution of this
executable, you must also deliver, in accordance with the terms and
conditions of the LGPL, the source code of Library (or your derivative
thereof) that is incorporated into this executable.

-- 
Loic   Dachary         http://www.dachary.org/  address@hidden
12 bd  Magenta         http://www.senga.org/      address@hidden
75010    Paris         T: 33 1 42 45 07 97          address@hidden
        GPG Public Key: http://www.dachary.org/loic/gpg.txt