Francois-Rene Rideau <firstname.lastname@example.org>
Sat, 1 Jun 2002 14:32:19 +0200
Since Marc Santoro decided to cross-post to email@example.com,
here is my opinion on the the technical point:
* Yes, macros do create a "derivative work", but, as jkf pointed out,
not more so than functions: in both cases, the whole thing gets
mingled in the build image, anyway, and is never exported as source code
(btw, the result of macro expansion is NOT ansicl source-code;
it is ugly system-dependent things.)
* The original LGPL depends on separate compilation and separate distribution
of code: if it were common to distribute files as separately compiled fasl,
then the distinction between functions (distributed in a separate fasl)
and macro (having effect in the third party fasl) would apply.
But this is not how Lisp code is distributed anyway.
* Without modification, the LGPL would mean that all build images fall under
section 6: any build image could be distributed under any license that
allows reverse-engineering and non-distributed modification, provided that
a copy of the source code for the library as used by the derivative work,
and *you can relink*.
* This last restriction is very hard for many people, who'd like
to publish and use free software lisp code and its contributed patches,
yet use it in otherwise proprietary software.
* Note that the author and sole contributor of a library
may very well use it in proprietary code, or offer it under a different
license for third party to include it in proprietary code,
even though they also publish it under LLGPL
or any other free software license.
The problem is only when you use third-party free software libraries,
or code contributed from third parties to enhance your own libraries
(which is part of the point of publishing libraries as free software).
* The LLGPL preamble specifically modifies the LGPL so that
the obligation to allow for relinking doesn't happen:
it is clearly the letter of the LLGPL that section 5 is modified
so as to state that section 6 does not apply,
but the weaker requirement of publishing updates to the library does.
Alternatively, you could think of it as section 6 modified
so as not to require relinking -
and maybe wording it that way would have been better;
but then, a preamble might not have sufficed,
and that was what Franz wanted to avoid.
* Whether the wording of the LLGPL preamble is valid legalese,
I can't tell, because IANAL.
I don't think this email discussion can help untangle the issue,
unless lawyers step in to give their opinion;
and even then, their opinions won't be definitive
until a court takes a decision.
At least, Franz' lawyers have given their opinion.
* Again IANAL, but it seems to me that in courts, the original intent of Franz
(or the original licensor) would matter,
even if their wording was incorrect, ambiguous, or whatever.
Suffices it to say that Franz is confident that their legalese
means what it is meant to mean.
If you don't trust Franz and its legal department in this regard,
by all means, don't use the LLGPL for your own works.
If someone else than Franz uses the LLGPL for one's original libraries,
you will have to ask that someone about *their* opinion on that matter.
* If I wanted a license that have the same effect as the LLGPL,
maybe I would have chosen the MPL instead of patching the LGPL:
it doesn't impose restrictions on the executables made from the source code.
However, read it carefully before you reach the same conclusion as I.
* Possibly, Franz decided that the LGPL was better known, so that patching
the LGPL would be better than invoking a different license.
You may think it's confusing, and you may think it's a mistake,
particularly considering that there exist other well-known licenses
that already fit the purpose.
* I think the LLGPL is different from the LGPL and incompatible with it,
and that the courts would agree, so you can't mix freely LGPL and LLGPL code.
But this shouldn't matter, since there is no reason you'd have to mix them.
* Therefore, I think continuing all this nitpicking is pointless.
The point is taken that patching the LGPL with a preamble
is something that makes many people uncomfortable.
Let's agree to disagree about whether this uncomfort is justified.
* Personally, my preferred license is bugroff:
I understand that this license makes some people far more uncomfortable
than the LLGPL does - particularly Franz' lawyers.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[ TUNES project for a Free Reflective Computing System | http://tunes.org ]
So you think you know how to translate French into English? Now what if the
French meant something completely different than what the English understood,
only neither the French, nor the English, could figure out the difference?