Message-ID: <38208B1A.771D1D84@algroup.co.uk>
Date: Wed, 03 Nov 1999 19:20:58 +0000
From: Ben Laurie <ben@algroup.co.uk>
Organization: A.L. Group plc
MIME-Version: 1.0
To: new-httpd@apache.org
Subject: Re: faster malloc for multithreaded programs
References: <Pine.WNT.4.20.9911011509200.171-100000@rasmus.raleigh.ibm.com>
 <7qso2p7tnl.fsf@rehab.in.aventail.com>
 <003301bf24bb$764d87a0$064b2509@raleigh.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

Bill Stoddard wrote:
> 
> > Rasmus Lerdorf <rasmus@apache.org> writes:
> >
> > > Well, this discussion probably belongs on the license list, but I have
> > > been through the LGPL a few times now trying to figure out if I could
> > > include LGPL'ed stuff in PHP and it is much too vague in my opinion.
> > >
> > > Like this clause:
> > >
> > >   When a "work that uses the Library" uses material from a header file
> > >   that is part of the Library, the object code for the work may be a
> > >   derivative work of the Library even though the source code is not.
> > >   Whether this is true is especially significant if the work can be
> linked
> > >   without the Library, or if the work is itself a library. The threshold
> > >   for this to be true is not precisely defined by law.
> > >
> > > If Apache is deemed a derivative work because of the above, then all of
> > > Apache has to be LGPL'ed as per clauses that came before that
> > > one.  Without a clear defitnition of what is a derivative work and what
> > > isn't, I think this license is much too shaky.
> >
> > IIRC this is to prevent proprietary derivatives of an LGPL'd library. Like
> > using the header files to create a binary compatible API. Not to prevent
> > #include'ing header files.
> 
> I agree with Rasmus, the intent is not clear. Last I checked, IBM legal
> thought the license was vague in this regard as well (that could be changing
> though....). Why are we having this discussion? Apache uses pools and only
> infrequently uses malloc/free, primarily (exclusively) during
> startup/shutdown. But then again, maybe my head is in a box.

Speaking as chair of the license committee I think it is a useful
discussion. I'm somewhat upset that even LGPL is too dangerous (but if
that's really true, where are we with standard C headers and so forth?).

I'd be particularly interested to hear if IBM legal are changing their
opinion.

However, isn't the crux that the _object code_ may be derivative? Do we
care? Anyone wishing to avoid that problem can avoid the LGPLed stuff
(so long as we make it optional, of course).

Also, it has just occurred to me, as the owners of Apache, we are
actually permitted to publish under multiple licences. Hmm. Perhaps I
don't really want to go there.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
     - Indira Gandhi