LLGPL Clarification

[John Foderaro]

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


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






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



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

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

As an example:  AllegroServe is LLGPL'ed and it contains a very
important (and large) macro called 'html' to help you generate html.   
You can definitely use the html macro in your application and 
in no way shape or form does the use of the html macro force you
to release your code under the LLGPL.     And there are 
more macros (with-http-response, with-http-body) that not only
are you encouraged to use in your code but you really have to 
use in your code or your code won't work with  AllegroServe.

I hope that's clear to everyone now.


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


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