In a message dated 01-09-02 19:34:47 EDT, Cliff Wooley wrote...
> On Sun, 2 Sep 2001 [EMAIL PROTECTED] wrote:
>
> > Correct... and for a while the reason was because everyone thought the
> > module was using ZLIB and there has been a long standing aversion to
> > including ANY version of GNU ZLIB ( or any other GNU stuff ) into the
> > Apache tree. We have personal emails from your board members stating
> > that to be the case. If that aversion has evaporated then there is a TON
of
> > GNU based stuff that is now 'eligible' for inclusion in the core
> > distribution, right?
>
> What Brian said. Are we talking about the same zlib? The one I know
> about is the one Brian linked to, which is NOT GPL and hence is eligible.
> No GPL code is eligible due to the "viral" effect of the GPL on code that
> uses it.
Cliff... you are right... It was a mistake for me to say that ZLIB is released
under the actual GNU/GPL license... it is not... it is released under the
less restrictive ZLIB/LIBPNG license. It is GZIP itself that is still under
GNU/GPL and since ZLIB is based on GZIP ( and both are based on
the deflate algorithm ) I still get the 2 mixed up.
Whether or not the same algorithm existing in the public domain under
2 different licenses means that the 'least' restrictive or the 'most'
restrictive
license actually applies under challenge is a matter for lawyers to decide
but in general the law usually says that when 2 disparate licenses cover
the same entity the 'least restrictive' license shall apply.
Speaking of which... I think I should point out that I am in no way opposed
to Apache adding ZLIB to the core distribution and it would just be too
weird for words to be characterized as such.
I was actually the one who submitted source code ( over a year ago ) that
required ZLIB and I was the one who 'tested the waters' and requested that
ZLIB be
added to the Apache source code tree right away not just for the code that
was submitted
( patches to ApacheBench which used ZLIB to accept/decode/verify IETF
Content-Encoding ) but for ANYTHING in the entire Apache package that
might benefit from ZLIB being available in the tree.
Both the code ( patches to ApacheBench ) and the idea of adding ZLIB
were rejected.
As we say here in Arkansas 'I have slept since then' so unless I am mistaken
the end result of the firestorm that took place over adding ZLIB to Apache
was still based on a reluctance to add any code that was not covered by
an actual 'Apache' license to the Apache source code tree.
I believe the objections were ( rightly ) based on the concerns surrounding
the 'least restrictive license' clause that actually casts an invisible pall
over much of Open source coding.
Most people reading/quoting OpenSource and/or GPL/GNU licenses don't really
understand this clause but lawyers do. What it means is that whenever you
start
'mixing' source code that is covered under different licenses there is always
the
chance that some legal entity could find ( for a plaintiff ) that the 'least
restrictive
license shall apply to the work as a whole'. If someone at Apache is still
afraid
that in the event the Apache license is ever challenged ( not likely but just
about
all of this IP based lawering is always based on 'what if' scenarios ) and
there
is other Non-Apache licensed OpenSource code included in the distribution
then the 'least restrictive license' clause could negate the Apache license.
It's a legitimate concern ( if your mind likes to mull these kinds of legal
issues )
and I suppose it's the basis for Apache always insisting that any code in the
Server
be 'donated' with the official Apache license and no other.
As Edward Albee wrote in Who's Afraid of Viginia Wolf... the only really
safe thing to do is 'Never mix... never worry'. I believe this has always
been the 'Apache way'.
If enough time has gone by and the need for ZLIB to be in Apache is
now great enough to render all this 'what if' stuff raw bullshit then let's
run that flag up the pole again...
I suggest (again) that the entire ZLIB source code package be IMMEDIATELY
added to the Apache source code tree. Like... TOMORROW.
It seems silly to discuss adding anything like mod_gz ( or our Enhanced
ApacheBench or any built-in IETF Content-encoding support ) unless it is
first determined if either the GZIP source code (GPL license) or ZLIB
( ZLIB/LIBPNG license) will ever make it into the Apache source tree.
Votes, anyone?
PS: Only Ian's mod_gz or our own Enhanced ApacheBench that can
support IETF Content-encoding would actually NEED any kind of ZLIB
support, AFAIK. Even our own Enhanced ApacheBench does not
require it because it can compile with/without ZLIB and in the
absence of ZLIB has it's own LZ77 + Huffman decoder. The only reason
we added the ability to use ZLIB was for client-side performance
testing of the decompression algorithms themselves. It (ZLIB) proved
to be inadequate and we don't recommend it being used as the decompressor
but the 'ifdef' statements to use are still there in the Enhanced ApacheBench.
mod_gzip, of course, does not require ANY other OpenSouce code
to be added to Apache. mod_gzip has never needed ZLIB at all but
that doesn't mean it couldn't use it ( as an option ) if it's available.
mod_gzip currently meets all of the Apache Group's 'requirements'
as we understood them to be following the previous firestorm about
adding ZLIB to Apache. It has it's own LZ77 + Huffman implementation
built-in and is already completely covered by an official Apache license.
It already completely avoids the 'mix and match' concerns regarding
2 disparate OpenSource licenses in the same codebase.
