🚀 go-pugleaf

david@wubios.wustl.edu (David J. Camp) writes:

>>   whatever changes were used in the work . . . and, if the work is an
>>   executable linked with the Library, with the complete machine-readable
>>   "work that uses the Library", as object code and/or source code, so
>                                                     ^^
>>   that the user can modify the Library and then relink to produce a
>>   modified executable containing the modified Library."
>>
>>Note it explicitly says one must either distribute (a) source or (b)
>>source and object.  This is source and object for the work, not just
>>for the library.

>You must ship the source for the library.  You must ship the source OR
>object for the work that uses the library.  The term and/or is
>interpreted by logicians as an inclusive or, which makes the "and"
>redundant except to distinguish it from an exclusive or.

>(It has been a while since I took logic, so please forgive any errors.)

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

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.

FYI -- this conversation got started in alt.sys.sun/comp.org.sun
because of Sun's decision to unbundle the C compiler (and presumably
libraries) from SunOS.  GCC was prompted touted as an alternative.  A
statement was attributed to John Gilmore that Cygnus would be willing
to consider writing a standard C library for $200,000, and would be
willing to accept the task on orders from 100 buyers at $2000 each.  I
said I'd push the idea at my clients, but thought they would find the
present library licence unacceptable.  Somebody asked why, and that got
us to this point.

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.
-- 
   ``They call to me to make a show of strength
    But I can't go out because my uniform is dirty.''
	"Dictator In A Polo Shirt", Gunnar Madsen/Richard Greene