🚀 go-pugleaf

I originally wrote the library license, and then RMS and some others
worked on it, so perhaps I can "clarify" authoritatively.

   Date: 1 Jan 92 01:24:21 GMT
   From: scs@lokkur.dexter.mi.us (Steve Simmons)

   Your logic looks good.  Unfortunately, the document was written for
   lawyers, not logicians.  What is the *legal* meaning of "and/or"?  In
   the paragraph David added emphasis to above, a much clearer statement
   could have been made by changing "as object code and/or source code" to
   "as object code, source code, or both".

   Another area in which the licence might be better written is by use
   of the term "work".  Section 5 takes pains to define an application
   linked with the library as a "work" which is derived from the library,
   but section 6 seems to use the term "work" both for the library and
   for the linked application.  Section 5 should define the term "linked
   application" as a derived work of the library, then use "work" for the
   library and "linked application" for the application.  Heck, why not
   call the library "library" rather than "work"?

No lawyer I've dealt with has a problem with either/or.  The term
"Work" is used because lawyers are used to it, with the meaning in the
license.  It's a little ambiguous because there are two "works" under
discussion, but less ambiguity than you might have by introducing
unfamiliar terms (it also isn't as wordy, which a lot of people
complain about in re legal documents).

Fortunately for the hair-splitters, both terms are well understood in
case law.  (case law applies hysteresis to legal interpretation.  It's
one reason law isn't a theorem-proving system, which is how a lot of
hackers think of it).

   To all those who wrote you to clarify intent of the original authors,
   many thanks.  There's been pretty clear concensus among them that the
   intent was *not* to force application developers to put the application
   out in such a way that it'd be easy to steal.  But none of them seem
   to speak for FSF.

I don't speak for the FSF either, but I can speak for my original
intent.  That concensus is correct (although I personally wouldn't use
the word "steal" in this context.)  I agree that the wording isn't
always a paragon of clarity, but in the end it had to be that way in
order to get it correct (some clearer earlier drafts also ended up
putting unfortunate restrictions on writers of works using the
library).

   According to the correspondants, the intent of sections 5 and 6 was to
   let the end user enhance the functionality of the application by enhancing
   the library.  Since doing this would require some reverse-engineering
   of the application to figure out how it makes use of the library, my
   guess is that the language of section 6 was added to explicitly permit
   this.  The actual text seems to lead to a much broader capability to 
   the end purchaser.  Two solutions seem possible.  One could insert some
   text into the "reverse-engineering" clause adding "for the purpose of
   enhancing the application by enhancing the library".  Or one could
   simply drop the clause.

The clause cannot be dropped, since the EC was considering/may have
passed legislation forbidding reverse-engineering.  Adding a "purpose"
clause like that would probably be unenfocable and could screw
legitimate use.

Don't forget that this clause protects software _consumers_.  Even if
a supplier has vanished, or desupported a product, consumers ought to
have a better chance of continuing to use software with new OS
releases, new toolkits, or whatever.  If they can't do it, perhaps the
OS-supplier, or a consultant, or whoever, will.