httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Behlendorf <br...@hyperreal.org>
Subject Re: GNU Portable Threads (pth)
Date Tue, 06 Jul 1999 01:25:15 GMT

Let's talk about this sanely for a second.

The LGPL makes a distinction between "a work based on the Library"
and a "work that uses the Library".  "Work based on the library" is
defined as:

  either the Library or any derivative work under copyright law: that is
  to say, a work containing the Library or a portion of it, either
  verbatim or with modifications and/or translated straightforwardly into
  another language. (Hereinafter, translation is included without
  limitation in the term "modification".) 

Then it states:

  The act of running a program using the Library is not restricted.

By my reading of the LGPL (and Bill, correct me if you think IBM has a
different opinion), we can have the end-user link Apache against LGPL'd
libraries.  We can also (separately) distribute an LGPL'd package of all
the essential LGPL'd libraries Apache would require during compilation,
even with whatever mods we needed to make for whatever reason, all again
under the LGPL.

However, we *have* to treat (Apache & other non-LGPL code) and (LGPL'd
code) as separate "works" requiring separate distribution.  Where I think
IBM and other large institutions have a problem is with trusting Stallman
not to sue them over a differing idea of what a "work" is.  For example,
if the Apache "configure" program autonomously went to the net to fetch
the LGPL'd package, without prompt or explicit action from the end-user
compiling the software, is it still considered a separate "work"?

One essential sentence:

  In addition, mere aggregation of another work not based on the Library
  with the Library (or with a work based on the Library) on a volume of a
  storage or distribution medium does not bring the other work under the
  scope of this License."

Is placing these files in the same .tgz file considered "mere
aggregation"?  How about the same CVS tree?

Also note that, if we do decide to distribute a separate LGPL package,
we'd need to do binary builds of that package, with the resulting
libraries compiled as .o's, .so's, .dll's, whatever.

Now, section 6 tries to address this, but as Dirk noted, it has problems.
For example,

  As an exception to the Sections above, you may also combine or link a
  "work that uses the Library" with the Library to produce a work
  containing portions of the Library, and distribute that work under terms
  of your choice, provided that the terms permit modification of the work
  for the customer's own use and reverse engineering for debugging such
  modifications.

I would wonder how this would play against a clause which stated that
customers who modified source code ran the risk of invalidating their
warranties.   It's also humorous to see

  If the work during execution displays copyright notices, you must
  include the copyright notice for the Library among them, as well as a
  reference directing the user to the copy of this License.

given Stallman's comments on the advertising clause in the BSD license.

6a could also be stretched to mean that source code to the work as a whole
would need to be provided, and even though that wouldn't mean putting it
under the LGPL, it would still be an issue for companies who combine
proprietary code with Apache.

6b is a bit more reassuring, though.  It suggests that we might be able to
include LGPL'd code into the final tarball/binary build, *if* we use
shared object loading.  




So, there's the issues as I know them.  If others have any, please bring
them up.  I think there *is* a way to reconcile the use of LGPL'd
libraries with the commercial interests lined up behind Apache, although
it is somewhat inconvenient.  

	Brian




Mime
View raw message