Fri, 31 May 2002 07:19:55 -0000
I think we may have to agree to disagree on this one.
Regardless, I do not believe that saying Section X is invalid is a proper
way to clarify anything.
Also, you are limiting the scope of the LGPL drastically by your
statements. Yet you claim to seek the spirit of the LGPL in the LLGPL. The
spirit of that particular snippet is to ensure that use of complex macros
and data structures by programs using a library give proper credit to the
use of the library in the program -- that a program using complex macros
and data structures contains a significant portion of Library code in it's
object files. That is the spirit that you fail completely to capture. How
powerful a macro system is does not matter -- what matters is that in the
end, [L]LGPL source code ends up in non-[L]LGPL routines that get compiled.
Take a look at Bison for an example of why this causes problems -- Bison
outputs it's own source code into generated code )doing what one could do
with significantly complex Lisp macros.) The FSF states (In the GPL FAQ)
that portions of Bison's source code in that respect were relicensed so
that the outputted source code could be included in anything
(unrestricted). They didn't LGPL the code because the LGPL is just as
restrictive in this case.
The LLGPL does not encompass that capability of Lisp. You do not mention
macros at all, and there are more problems than just macros, such as higher-
You ask me to understand the distinctions between Lisp and C, as if the
thing is very simple. But it is not: How Lisp "libraries" work could be
very complicated. One could claim that on certain systems a Lisp namespace
with a package system is somewhat like a "filesystem" and that intern'd
Lisp functions are like files -- and are therefore completely seperate
elements of something that even as a whole does not constitute a program
(in the same way that GNU + Linux does not constitute a program, it
constitutes an operating system and environment). The distinction between
Lisp and C is very variable, and depends highly on the setting and
particular Lisp used. What about a Lisp-to-C compiler that could in fact
use header files?
I could go on for pages (as I'm sure you could) about how complex Lisp is.
That complexity *is not captured* by the LLGPL, which exists only as an
ambiguous modification to an ambiguous license (ponder Section 6 of the
LGPL in relations to "debugging" copy protection code and the DMCA...)
As it stands, I would have to highly recommend free and non-ambiguous
methods of licensing, such as Public Domain and Bugroff, and not the LLGPL.
Both of these give you an extreme amount of control over your own source
code, and the ability to use source code other people have developed in any
way you wish. Isn't that what free software is all about?
I must point out that I don't believe many people understand the LGPL --
most people think they understand the spirit when they do not. The LGPL is
designed to be viral. It *is* designed to try and convince people to
release their code under the GPL/LGPL. It is not designed to simply protect