LLGPL Clarification

[Marc Santoro]

Greetings all,

I'm not a lawyer, but...

I recently discovered the LLGPL <http://opensource.franz.com/preamble.html> 
It claims that the preamble overrides the LGPL; however, I do not see 
several things discussed in the LLGPL that, if defined by the LGPL, could 
be bad.

I do not feel that the LLGPL adequately protects the Lisp vendor or the 
developers of Lisp applications that include code licensed under the LLGPL, 
in particular because of Section 5, Lisp's complex macro system, and things 
like eval and lexical closures. I believe that in order to be effective, 
the LLGPL really needs to not be based on the LGPL, and include an 
effective statement of what defines a derivative work in terms of Lisp. The 
LLGPL defines this ineffectively by using the term "linking", which is not 
adequate, and not even particularly valid in terms of Lisp and other higher-
order languages.

To clarify, let me first quote part of Section 5 of the LGPL:

"When a "work that uses the Library" uses material from a header file
that is part of the Library, the object code for the work may be a
derivative work of the Library even though the source code is not.
Whether this is true is especially significant if the work can be
linked without the Library, or if the work is itself a library. The
threshold for this to be true is not precisely defined by law.

If such an object file uses only numerical parameters, data
structure layouts and accessors, and small macros and small inline
functions (ten lines or less in length), then the use of the object
file is unrestricted, regardless of whether it is legally a derivative
work. (Executables containing this object code plus portions of the
Library will still fall under Section 6.)"

(end quote)

First off, Lisp doesn't have header files. But often macros are made 
available in some other way by an application or Library, and Lisp macros 
have a tendancy (in my experience, at least) to often grow to more than 10 
lines in length. In this case, the bytecode or native code generated by the 
Lisp would in fact contain object code that is part of the Library (this 
is -not- linking). This would make the application a derivative of the 
Library, imposing further licensing restrictions. Also, eval and lexical 
closures could be used along the same lines -- in a way that causes the 
inclusion of Library code into the routines using these data/functions 
exported by the Library. 

The LLGPL states that Section 6 is not applicable to the Library. However, 
because the work that uses the macros/closures and thus includes the 
library is considered a derivative, and the LLGPL specifies that 
derivatives are covered by the LGPL, then individual routines within the 
application that use complex macros or closures, or any other way of 
exporting code will be considered derivatives and covered by section 6 of 
the LGPL (not the LLGPL).

Now, refer to Section 2:

"But when you distribute the same sections as part of a whole which is a 
work based on the Library, the distribution of the whole must be on the 
terms of this License, whose permissions for other licensees extend to the
entire whole,"

This to me says that the executable distributed which uses significant 
macros from the Library and thus contains routines which are considered 
derivative works must be distributed as a whole, under the terms of the 
LGPL.

This would mean, for example, that someone could write a macro that 
simulates a toplevel read-eval-print loop, license that macro under the 
LLGPL, make an executable containing this macro that executes the macro at 
startup, and release that executable under the LGPL. A nifty way to pirate 
Lisp...

Anyway, I would appreciate any insight and clarifications to this matter. I 
recently submitted a question to Richard Stallman on an issue similar to 
this, to which he replied he would need to speak with a lawyer (namely, if 
an application vendor releases anything under GNU/Linux linked with LGPL 
libraries, whether Sections 5 and 6 would give users of these applications 
permission to disable copy protection). This comes up because again, 
executables containing substantial portions of the library in the code 
itself (again, nothing to do with linking) -- from header files, or macro 
definition files, are considered derivative works under the LGPL, and thus 
are subject to it's licensing terms.

Thank you,
  Marc Santoro