Re: LLGPL Clarification

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

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