Re: LLGPL Clarification

   From: John Foderaro <[email protected]>
   Date: Thu, 30 May 2002 21:38:16 -0700

   >> When you use macros, you create a derivative work. 

       This is always false in the LLGPL and possibily false in the LGPL (it
   depends on the size of the macro).

Then the LLGPL needs to say so explicitly, since the default legal
interpretation (as Marc Santoro points out) is that compiled
macroexpanded code is derivative.

   I can understand your desire to use the LGPL verbatim, but it is
rather obscure to have to override large chunks of it in the preamble.
A self-contained LLGPL that followed the LGPL closely but was written
with Lisp in mind would be much clearer, it seems to me.  (But I'll bet
this is an old battle.)

       Your misunderstanding of the LLGPL is due to your misunderstanding
   of the end of section 5 of the LGPL . . .

      . . . Thus (and this is the key point) sentence 4 is talking
      macros found in *header files*.

      Lisp doesn't have header files.   Sentence 4 does not apply to Lisp.

      I don't see how this can be any clearer.

Excellent; you have clearly explained why the license is unclear.
Unless it is covered somewhere else (that I have missed), the LLGPL is
altogether silent on the issue of macros.  That is different from giving
guidance on which usages are permitted, and which are not, which I
believe is the thrust of Marc Santoro's original post.

   For instance, I would hope that it is permitted to distribute a
binary that incorporates some of the Library's code by virtue of having
been expanded from a library macro.  This strikes me as a usage
permitted by the LGPL, but you seem to be disavowing it here.  I would
even go further; I would say this exemption ought to apply for Library
macros of arbitrary complexity, such as a new iteration macro; there
would seem to be no advantage in denying the use of pure syntactic sugar
to authors of proprietary programs.

   But what about binary-only distribution of a macro that expands into
a Library macro?  It seems to me that one could make a case either way
-- both for whether this should be permitted, and whether this
constitutes a derived work.  A robust license should not be silent on
such issues.

   FWIW, I don't think eval and lexical closures are problematic; they
don't introduce any semantics that can't be done (albeit much more
laboriously) with C-style function calls to library functions.  The
possible exception is an eval involving macros, but that is close to the
situation in the preceding paragraph, in that both require expansion of
a Library macro at application runtime.

   Or am I missing something obvious?  (And if it's not obvious, why
isn't it in writing?)

   Thanks in any case for having provided a lightning rod,

					-- Bob Rogers
					   http://rgrjr.dyndns.org/