LLGPL Clarification
John Foderaro
jkf@franz.com
Thu, 30 May 2002 21:38:16 -0700
>> Notice the use of "When" instead of "If and only if". When you murder
>> someone, you go to jail.
OJ Simpson murdered two people and he's not in jail.
>> When you use macros, you create a derivative work.
This is always false in the LLGPL and possibily false in the LGPL (it
depends on the size of the macro).
Your misunderstanding of the LLGPL is due to your misunderstanding
of the end of section 5 of the LGPL. Let's go through it sentence
by sentence and I'll explain what it means
I'll number the sentences.
=====
1. When a "work that uses the Library" uses material from a header file
that is part of the Library, the object code for the work may be a
derivative work of the Library even though the source code is not.
2. Whether this is true is especially significant if the work can be
linked without the Library, or if the work is itself a library.
3. The threshold for this to be true is not precisely defined by law.
4. If such an object file uses only numerical parameters, data
structure layouts and accessors, and small macros and small inline
functions (ten lines or less in length), then the use of the object
file is unrestricted, regardless of whether it is legally a derivative
work.
5. (Executables containing this object code plus portions of the
Library will still fall under Section 6.)
====
In sentence 1 the theme of the paragraph is introduced: how header files
are treated by the LGPL. Sentence 3 is odd, it just leaves you hanging
when in fact you are looking to this document for guidance on this threshold
Skip to the next paragraph and the word 'such' in sentence 4 tells you
that the point of this sentence is to clarify this notion of a threshold
mentioned in sentence 3. Thus (and this is the key point) sentence
4 is talking macros found in *header files*.
Lisp doesn't have header files. Sentence 4 does not apply to Lisp.
I don't see how this can be any clearer.
I'm not sure of your programming background. If you've never programmed
in C and don't know what a C header file is then I can see how you would
be confused by the LGPL. You may actually think that C macros have
something in common with Lisp macros. Remember that Lisp macros
are not simple text substitutions. A lisp macro is a full fledged
function stored as data and/or executable code within the Lisp image.
It is wrong to claim that the result of a Lisp macro running is the same as
pasting in source from the original program. It just isn't so.
But it does matter anyway since the LLGPL allows lisp libraries to contain
macros as well as functions. So that's two strikes against your objections.
I believe your confusion about the LGPL stems from you not understanding
the point of the LGPL and how everything in the document falls from that.
If you knew about the C language you would understand why explicitly protecting
the derivations of macros in header files was important but that protecting macros in
source files was not important (since they were protected anyway by the
other provisions of the LGPL).
So my suggestion to you is to first grasp the idea behind the LGPL
and then try to understand why each section of the LGPL backs up that basic idea.
Don't try to understand the sections independent of the big idea.
Then to understand the LLGPL consider the difference between a library
of Lisp code and a library of C code. Consider how Lisp programs are built.
Consider how Lisp macros work. Then the LLGPL will make sense.
Whether the LGPL or the LLGPL make sense for your unnamed language is
something I can't say.