LLGPL Clarification

[Bob Rogers]

   From: John Foderaro <jkf@franz.com>
   Date: Sat, 01 Jun 2002 08:16:35 -0700

    As I find myself wanting to restate the points I've already made
   I realize that this discussion has gone full circle.  There's
   no point in repeating myself, that's what mail archives are for.

    There seem to be two ways to read the LLGPL and LGPL.  Which is
   correct?  To me when I understand something it makes things clearer
   rather than more confused.  Those people who believe that the
   use of a large Lisp macro in a LLGPL'ed library someone creates
   a derived work end in with a world full of contraditions.  This alone
   should offer a clue that this is not the correct interpretation.

    For example Bob Rogers points out this macro in pxml and claims
   that to use it would create a derivative work since it's over 10 
   lines long.

No, that's not what I claimed (clarified below).

   Perhaps you haved been confused by the fact that I am reserving the
acronym "LGPL" to refer to the original GNU version, and "LLGPL" to
refer to the version "clarified" by Franz.  I had hoped this usage would
be clear, but since you talk about "two ways to read the LLGPL and
LGPL," it sounds as if you want to blur the distinction.

   . . .

   ok what if I wrote it like this . . .

    now it's 6 lines along.  Will using it now magically NOT create
   a derivitive work?   And if you answer is yes (and it has to be
   based on how you've read the LLGPL) then how crazy is that?

You have missed my point completely; the actual length of the macro, or
of anything else, is irrelevant.  I think we agree that the macro length
would be a factor only in the original LGPL, since it is mentioned in
the first sentence of section 5 paragraph 4, but you have disavowed this
sentence entirely as inapplicable to Lisp.

   Instead, I chose this example because it contains a sizeable chunk of
code that gets compiled almost verbatim into client applications; what
you have failed to do is explain why the compiled version of this chunk
is not considered derivative by the LLGPL.  I picked a larger macro in
the hope that the greater size would make this issue plainer.

   What if I rewrite the macro as a small macro and a big function . . .

   Now the macro is only 2 lines long.  Bob Rogers and Marc Santoro
   would have to admit that using this macro is not a derivative work.

No; again, you misunderstand.  The principle is that LLGPL content (the
stuff in the backquoted form, whether you want to call it code, data, or
something else entirely) is getting compiled into client applications.
None of these rewrites affect my point.

   (The backquoting means that the "code" is really data to the macro.
But so what?  In Lisp, as we well know, code is data, and data is code.
(Or "are code"?? -- damnable language.)  But both are copyrighted, so
that quirk of Lisp does not pose a challenge.)

   . . .

   The whole argument about derivative work (which was designed to
   protect C programmers) makes no sense in the Lisp world.

???  You don't believe Lisp programmers need similar protection??  Or
are you merely saying that Lisp needs a different notion of "derivative
work"?  I'm inclined to disagree, but in any case, if such a notion is
in fact different, how do you expect it to have any force if you don't
make it explicit in the license?

   When you assume something that makes no sense you quickly end up with
   contraditions as I've show above.

I don't think so.  You have indeed shown some "contradictions," but only
in misinterpretations of my statements.  Except for correctly pointing
out that backquoted Lisp macro "code" is better thought of as data, even
though that should make no difference for copyright purposes, you have
yet to address the actual line of reasoning.

   Often people come across documents and try to guess the intent
   of the authors.  In the case of the LLGPL I'm  a co-author so
   no guessing is required.  I've spelled out exactly in the previous
   letters the intent of the LLGPL and I can state again that
   under the LLGPL the result of macro expansion does NOT result
   in LLGPLed code.  

Again, you have made your intent abundantly clear.  But I am still in
the dark as to how the letter of the LLGPL implements that intent.

   You may say that while the intentions of the authors aren't
   questioned did those intentions make it to down on paper correctly?
   To really understand the LLGPL you have to have a good knowledge of
   the C language and the Lisp language.  I and many others (including a
   lawyer specializing in software issues) believe the LLGPL expresses
   those intentions.  Those are the facts.

Actually, those are opinions; the word "believe" should have tipped you
off.

   Neither I nor anyone else offers a warranty that the LLGPL expresses
   those intentions.  If you are uncomfortable with the LLGPL see a
   lawyer (or a more experienced programmer) for consultation or avoid
   LLGPL'ed code.

If I really do need a lawyer and/or someone with more than my degree of
software experience (see the postscript) in order to understand that the
LLGPL means what you say it means, despite the fact that it appears on
the face of it to mean something different, then perhaps you should be
concerned that the LLGPL is way too obscure.  (And lawyers have been
known to disagree with each other; here's hoping you never have to
undergo a legal challenge.)

   And that's all I've got to say on this issue.

Good; I'm getting tired of this myself.  Though it's quite clear that
one or both of us greatly misunderstands the other, I'm out of ideas for
cutting through the fog.

   Just for grins, though, and because I haven't yet had an occasion to
set it all out in one place, let me summarize my line of reasoning:

   1.  When a work (program, novel, etc.) is copyrighted, translated
versions (compiled, macroexpanded, gzipped, Latvian, etc.), whether made
by human or machine, are also covered by that copyright, unless
explicitly exempted.  (I seem to recall reading that copyright is
intended to protect "the expression of an idea," so anything less broad
would open up unacceptable loopholes.)

   2.  In C, macros may result in source code fragments from one work (a
library) being compiled into another work (a client application); the
resulting object file would therefore be considered a derived work.

   3.  In the GNU LGPL (http://www.gnu.org/copyleft/lesser.html),
unmodified by the Franz LLGPL preamble, section 5 paragraph 3
acknowledges this situation, somewhat unhelpfully.  Paragraph 4 goes on
to grant an exemption "if such an object file uses only numerical
parameters, data structure layouts and accessors, and small macros and
small inline functions," removing restrictions on the resulting object
files.  Large macros are still subject to the default restrictions on
derived works.

   4.  Lisp macros may also result in library code being compiled into
client applications, though Lisp uses a radically different mechanism.
However different the mechanisms may be, the intent and usage of macros
is quite similar in both languages: at compile time, a bit of library
code rewrites a bit of application code, possibly inserting parts of the
macro into the resulting application binary.

   5.  Though the LLGPL does not explicitly say so, you have clarified
in your email of Thu, 30 May 2002 21:38:16 -0700 that the "such" in the
LGPL sec 5 para 4 passage quoted above refers to header files, and for
this reason, this paragraph does not apply to Lisp.

   6.  The LLGPL therefore does not appear to have *any* exemption for
macroexpanded code.  Macros are implicitly subsumed under "functions"
and no mention is made of macro expansions.  Indeed; I can't find the
words "macro" or "inline" in the whole preamble.

   I think we part ways at step 4, because you believe that C macros are
"code" but Lisp macros are "metacode" (i.e. code that produces code),
and this difference means that there is no copyrighted library content
in the resulting Lisp macroexpansion.  The conclusion is
intended to be a paraphrase of the following quote from
your email on Fri, 31 May 2002 10:12:51 -0700:

    The expansion of a Lisp macro does not cause *any* of the library's
    source code to be incorported.

but generalized from "source code" to "content".  Is that a fair
restatement?  I won't quibble with the premise, but the conclusion
simply does not follow.

   Perhaps a terminology change would help.  You might consider a
nontrivial C macro to contain "template code," but does this phrase not
also apply to nontrivial backquoted forms within Lisp macros?

   But the legal status of executables may actually be much clearer.
Upon rereading the preamble, I was struck by another plausible (to my
non-legal mind) legal theory.  The blanket exemption for linked
executables ought to cover macroexpansions in application code as well:

    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.

Perhaps this is why your lawyer thinks macros are not a problem?

   However, this still leaves the copyright status of binaries in limbo.
(I also find the choice of wording to be somewhat alarming.  Surely what
is meant is "not a derivative" rather than "NOT covered"?  Perhaps it
would be good to have more than one lawyer look at this?)

   If anybody sees a hole in any of this (that has not already been
discussed), I would appreciate hearing about it.  But please send it
off-list, as I'm sure jkf and I aren't the only ones who are weary of
this thread.

   Failing some revelation, I'm content to leave it at that.

   Thanks again for the opportunity to consider these issues in greater
detail,

					-- Bob Rogers

P.S.  Fans of historical irony may appreciate this recollection, which
has only slowly dribbled back into my consciousness during the course of
this thread.  I've been writing code for nearly 30 years now, though
only in Lisp since 1981.  The first Lisp system I used was none other
than "franz lisp" from Berkeley, precursor to the Allegro product.  Of
course, the original franz was distributed with source, and though I
remember little of the actual experience, I got my introduction to how
to write macros by reading a file called "jkfmacs.l" (IIRC).  It
actually took me a while to figure out that "jkf" was somebody's
initials, and not some new bit of Lisp arcana, or something to do with
J-K flip-flops.