LLGPL Clarification

[Bob Rogers]

   From: John Foderaro <jkf@franz.com>
   Date: Fri, 31 May 2002 10:12:51 -0700

   >> That is incorrect.  My understanding of most cpp implementations is that
   >> they use token substitution, which is not in principle any different
   >> than what Lisp does (though much less general).

   the design of the C language system has the C preprocessor as 
   a simple text substitution system.  Whether some implementations
   contain optimizations that preprocess the input to make the
   text substitutions faster is irrelevant.

My point exactly, though taken from the other direction.

   In no case do standard C preprocessor macros cause user defined code
   to run at compile time when then generates the internal parsed form
   that the compiler uses.  [although gcc is pushing the envelope here
   in very non-standard ways]

Granted (even with your parenthetical caveat), though I maintain that
the internal representation is irrelevant.  I assume we all agree that
Lisp macros are a vastly more powerful superset of C macros, largely
because the compile-time/runtime distinction is blurred.

   >>    And, even if this were true, I can't see that it makes any
   >> difference.  If I were to hack a Lisp compiler to print macroexpansions
   >> and then reread them, would that change the licensing conditions for
   >> packages compiled with the hacked compiler? 

   You can't always print macroexpansions.  First because not all
   lisp objects can be printed and then read back in (e.g. streams
   and many array types).  Second because macroexpansions may
   have side effects.  How are you going to find and print out 
   the side effects of a macro just run?

You can't, of course; all of that is true.  But how does the fact that
my hacked compiler is buggy (not to mention non-ANSI) affect my point,
particularly for the vast majority of macroexpansions that are
non-side-effecting and printable?  Essentially, you seem to be saying
that the intermediate representation used internally by the compiler
affects the legal relationship between program components compiled by
that compiler.  I believe that is incorrect, and, more importantly,
irrelevant; read on.

   >>        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.

   Nothing Marc Santoro pointed out proved that compiled Lisp macroexpanded
   code is derivitive.  Please quote the sections of the LGPL that
   proves this in your mind.

That's the problem; there is no such section in the LLGPL.  The
prevailing notion of software copyright (in my non-professional
understanding) is that object code implicitly carries the copyright of
the source code from which it was compiled.  The LGPL has paragraphs 3
and 4 of section 5 that exempt the expansion of LGPL macros, but, as you
have gone to great lengths to explain, that does not apply to LLGPL
code.  For why this is a problem, see below.

   >>   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 can neither agree or disagree with your statement because it
   begins with a false premise:

	   incorporates some of the Library's code by virtue of having
	   been expanded from a library macro.

   The expansion of a Lisp macro does not cause *any* of the library's
   source code to be incorported.    Thus since no code has
   been incorporated there's no question about whether it's valid
   to use Lisp macros or not.   It's ALWAYS valid.

That depends critically on your narrow interpretation of the term
"source code."  See below for why I think this needs to be codified.

   To put it plainly:  You can use macros from LLGPL'ed lisp libraries
   in your code.

   . . .

   I hope that's clear to everyone now.

Your intent is manifestly clear, but I think the legal incantations
themselves should be as clear (to the extent the lawyers will permit).

   >>    But what about binary-only distribution of a macro that expands into
   >> a Library macro? 

   to answer this question just remind yourself of two things:
   1. macros in Lisp are really functions.  using functions from an
      library is ok.
   2. lisp macros do not generate lisp source.  Thus there is no
      confusion about derived works when you use lisp macros.

   so the answer to your question is that the scenario you mentioned
   is perfectly valid.   Your code is not a derived work.

Aha; I think we have finally come to the gist of the matter.  As stated
above, an object file is still considered to be derived from the source
for copyright purposes, even though it is manifestly not source code.
In similar fashion, Lisp macros generate something that is derived from
the source of both the macro definition (macro boilerplate that is part
of the Library code) and the macro call (the application code); the fact
that the derived representation is in a different form than the source
is irrelevant (or should be), especially since that form is generally
converted immediately to object code.  It is this mixture of Library and
application source code that causes the licensing headaches, since it
must be considered a derived work by default.  In fact, the result of
macroexpansion is much closer in form to the source than the object, so
an explicit exemption is all the more vital.

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

   I though this was obvious.  If it's not obvious to others then we will
   have to consider putting it into writing.

I think that would be a great service to the community.  (Bearing the
brunt of these gripes and quibbles certainly is; I appreciate the fact
that Franz Inc. is willing to blaze a trail in this area.)

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