LLGPL Clarification

[Marc Santoro]

>  But you have to understand that Lisp macros are functions
..

This is not quite true. Lisp macros are quite a bit different than 
functions, and in general it can be counted on for an implementation to 
expand part of a macro inline into source code. This a derivative does make.

I will quickly go to another source now: Paul Graham's definition of macros 
in On Lisp. To paraphrase, the key difference between a macro and a 
function is that a macro returns things to be evaluated to produce results 
instead of results directly. This thing to be evaluated may well be a 
verbatim snippet of code. I consider Graham's book an authority on this 
matter, and an available one at that.

You're showing the cases where an expanded macro may not constitute a 
derived work, but I have to point out that this method of argumentation 
contains a logic flaw: You are not arguing the point at hand. I will not 
deny that it is possible to write macros which may be complex enough to not 
generate code that'll make a function be a derivative work (namely, macros 
like this would fall under compilers/interpreters, and this case might 
occur any time the macro contained no backquotes, among others).

Would it be sufficient to define a macro as a function whose return value 
is inlined into code? If we stick to this definition than any macro that 
returns part of itself verbatim would, by being used, create a derivative 
work.

You have still yet to prove that it is not possible for a macro to exist 
that will cause LLGPL code to be inserted verbatim into "work's" code, in 
some random implementation. Since your license does not state "This free 
license applies only when Franz' proprietary products are used to compile", 
I assume your intent is to keep it functional with any reasonable Lisp. 

I must point out, as proof, that under CMUCL 18d on Linux, a very popular 
and common CL implementation:

Here is a macro that is silly enough to fall under LGPL protection:

(defmacro foo (x y z)
  `(if ,x
     (progn
       (format t "Blah!")
       (format t "Arf! ~A~%" ,y))
    (progn
      (format t "Meep! ~A" ,z)
      (format t "Zoink! ~A" ,y)
      (format t "This ")
      (format t "Macro ")
      (format t "Is ")
      (format t "Silly.")
      (terpri t))))

Now, let's do something fun with it.

(defun bar () (foo nil "Gnarf!" "Meep!"))

(compile 'bar)

(disassemble 'bar)

<many lines of x86 assembly code follow)

It is extremely obvious in the assembly code generated that the macro was 
inserted verbatim into the routine bar as it was compiled. This could be 
proven by comparing the assembly code for a function bar that is exactly 
equivalent to the macro. (Of course, to be completely fair, I must admit 
that with optimization settings, the compiler will cut out half of the 
macro, but the other half will always be there verbatim). 

Your argument is the harder to prove because in order to prove the LLGPL 
unambiguous you must prove that there is no circumstance in which the use 
of a macro may constitute a derivative work. I only have to prove that you 
can't prove your argument -- this is logic.

Also, I must admit that I do not find your claim that implementation 
details would necessarily effect licensing to be true in the least. If I 
use a C compiler that has an integrated preprocessor with the capability of 
interpreting arbitrary code during the preprocessing phase, this does not 
invalidate the use of the specifics of the LGPL. If I use a very limited 
Lisp which can only perform simple text substitution, again, it does not 
invalidate the use of the LGPL (or LLGPL). 

Regardless of how it happens, it is obvious and true that something 
generated from the macro is inlined into the function. If that something 
can ever be enough to constitute a derivative work (as defined by law) (and 
as shown above it can be), then the LLGPL needs to be clear on the 
licensing issues revolving around this. As Bob Rogers seems to be saying, 
object code falls under the same license as the source code it was 
generated from.

Interesting note about the Linux kernel that also applies here: There are 
non-free drivers in the kernel; these drivers are non-free because they 
contain third party non-free object code included verbatim in the source 
and the executable. There's an effort to rewrite all this non-free object 
code so the kernel will be legal. I'm mentioning this to point out that it 
doesn't even matter what kind of code is present to cause copyright 
problems, just that it is present. Source, intermediate, object, it doesn't 
matter.

Perhaps I should apologize for using precedents in C, since some readers 
may be prejiduced in one way or another. However, C has undergone much more 
rigorous legal testing, and I believe that precedents established using C 
will likely be applicable (and applied) to similar situations in other 
languages.

Thank you,
  Marc Santoro