LLGPL Clarification

[Marc Santoro]

John Foderaro <jkf@franz.com> said:

> 
>  [The following my opinion only.  I'm not a lawyer. I'm a programmer]
> 
> 
>  The idea of a 'header file' is something used in only a few languages.
> C has header files.   Lisp does *not* have header files.   Because
> Lisp does not have header files the text in section 5 of the LGPL 
> doesn't apply to Lisp.
> 
Seems to me Section 5 is using "header files" as an example -- the next 
paragraph does not mention header files in the least. It discusses macros 
and data structures. 

I'm sure if you were to #include a .c file anyone would agree that the 
object code generated would be just as much a derivative as if you included 
a header file. Just what constitutes a header file is irrelevant anyway, 
because the LGPL does not state that only macros included from header files 
can constitute a derivative work -- it states that macros of length of more 
than 10 lines do.

The fundamental issue here is not header files. It is macros. You express 
my point very well in your explanation of how macros work in Lisp: However 
you fail to mention that when a macro is used, it is essentially operating 
on data -- it takes data as input, and outputs new data for the compiler 
(often including parts of itself). This *is* going to be a derivative. 

Lisp macros "appear" close to Lisp functions when called, but they work in 
drastically different ways. I would much rather discuss reality than the 
illusion one would see when viewing source.

> 
>   
>  Why is all this fuss made about header files?   In a C program the
> header files can have significant value all by themselves, 
> outside of their use to compile or use the Library.  The LGPL wants to add
> a bit of protection for those header files. 
>  Yes, C header files can have macros in them and yes Lisp has something
> called a macro as well but Lisp macros are much closer to Lisp functions
> than C macros are to C functions.  Lisp macros in a Lisp library can 
> be a signficant part of the value of the Lisp library.  It would go
> completely against the nature of Lisp to tell people that they
> can't export powerful Lisp macros an LLGPL'ed library since that will
> make any code that uses those macros a derivative work.
> 

I agree completely with your last sentence. Why are you promoting a license 
that states the opposite?

The solution is not to deny people the ability to export macros or code-as-
data in any form. The solution might be to state that the usage of code-as-
data exported in any form from a LLGPL Library would not constitute a 
derivative. This is a much more general (and not Lisp-specific), and a 
superior solution. It does open up more problems, though: What if a LLGPL 
function exports code-as-data that is not licensed under the LLGPL (for 
example many Lisp core "functions" are implemented as macros, if one of 
these macros is expanded into data in an LLGPL macro, that expanded data 
needs to be covered under the original license. And it may well be 
incompatible with the LLGPL, and the default failsafe in the LGPL is "do 
not distribute"). However this should be a sufficiently rare situation (and 
LGPL states that LGPL code must not rely on non-redistributable code 
anyway) that an exception will work.

I must admit to my personal point of view, that the only adequate license 
for Lisp macros (and the preferable one for higher-order languages in 
general) is that they should be Public Domain. Though I acknowledge that 
may not be an available option in the case of proprietary Lisps. 

Thank you,
  Marc Santoro