Thu, 30 May 2002 17:11:08 -0000
John Foderaro <email@example.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.