LLGPL Clarification

[Francois-Rene Rideau]

Since Marc Santoro decided to cross-post to cybernethics@tunes.org,
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*.
	http://opensource.franz.com/license.html

* 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.
	http://opensource.franz.com/preamble.html

* 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.
	http://www.mozilla.org/MPL/MPL-1.1.html
 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:
	http://www.geocities.com/SoHo/Cafe/5947/bugroff.html
 I understand that this license makes some people far more uncomfortable
 than the LLGPL does - particularly Franz' lawyers.

Yours freely,

[ 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?