httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Apache license and GZIP
Date Fri, 15 Oct 1999 01:44:38 GMT

In a message dated 99-10-15 00:46:14 EDT, Dirk-Willem van Gulik writes...

> To the best of my knowledge, ZLib was under a more 'reasonable' licence
>  (from an apache licence point of view) that pure GPL. In fact to my
>  eye it looks just like the apache licence.

Thanks for taking the time to paste the
ZLIB header copyright notice. I really
do appreciate the mouse clicks.

I am very familiar with that header copyright.

What I still have not heard or seen
that would be really helpful is a
a straight admission from ASF representative
that any patches containing most, if not all,
of the ZLIB code would be readily accepted by
the Apache Group/ASF. Yea or nay?

The reason I was assuming ZLIB is under the
GNU public license is that despite what
they say about it they freely admit it
is 'derived' from 'gzip' ( Which it just
so happens was written by the same 2 people
so it's hard to imagine it is not based on gzip').

GZIP is about as GNU as you can get. That's what
the 'G' actually stands for.

The official home page for GZIP is actually right on the GNU server itself.

There is also this admission about GPL GZIP and ZLIB
which comes right from ZLIB's own home page...

> Not surprisingly, the compression algorithm used in zlib
> is essentially the same as that in gzip and Zip, namely,
> the 'deflate' method that originated in PKWARE's PKZIP 2.x.

See the paragraph down below for more information
about the legal quagmire that is 'deflate'.

I am not doubting anything the ZLIB folks might
personally believe about how 'safe' their
implementation is or is not... I am
confused about how a product which freely
admits it is based on another GPL product can
say that it is not subject to the GPL. I
thought that was the essence of GPL. If you
include GPL then you yourself are GPL no
matter what you might think. As long as
all the source is free I guess no one is
going to get rich suing anyone but a
reluctance to sue does not mean either
product loses it's actual legal identity.

Is there anyone at Apache who is concerned about this?

I guess I am looking for an actual 'position'
statement from the organization as to the
suitability of ZLIB for it's product(s).


Both MSIE 5.0 and most recent version of
Netscape and Lynx are putting out the
'Accept-encoding: gzip, compress' fields.

Everyone knows that UNIX compress contains the
deadly LZW algorithms that have always been
patented by IBM and UNISYS and anyone using it
these days actually owes them money.

Lynx is assuming it can shell it in the BASH
or something so I guess the Lynx folks think
they are 'safe' but how both recent versions of
MSIE and NS are getting away with performing
'Accept-encoding: compress' is beyond me.
I could find no public evidence of any licensing
agreements on the part of either company with
the holders of the LZW patent(s) ( IBM/UNISYS ).

'compress' is IN both browsers... yet 'compress'
has known patented algorithms in it.

Anyone know the score there?

Even if MS and Netscape are simply 'getting away'
with having 'compress' code onboard and IBM/UNISYS
simply haven't decided to cash in just yet I really
doubt Apache Group would want to go that route as
well... so unless the 'BASH it' approach for 'compress'
is actually legal it's safe to say we won't be seeing
any 'compress' code in the Apache CVS tree any time soon.

GZIP entered the picture when Jean G. and M. Adler
saw the whole emerging IBM/USNISYS thing and unless
someone can tell me what else the 'G' in 'GZIP' stands
for... GZIP is GNU/GPL.

The official home page for gzip is actually right on the GNU server.

This page on the same official GNU foundation site...

is a list of 'Official GNU software packages'.

If you scroll down a ways you will sure enough find 'gzip' listed.

If you click on the 'gzip' link in the list
you will then go to this page at the official GNU site...

Where you will see this little gem...

> gzip
> gzip (GNU zip) is a popular data compression program written by
> Jean-Loup Gailly <> for the GNU project.
> WE developed this program as a replacement for compress because of the
> UNISYS and IBM patents covering the LZW algorithm used by compress.
> These patents made it impossible for us to use compress, and we
> needed a replacement. The superior compression ratio of GZIP is
> just a bonus.

There it is again... 'impossible to use compress'... yet all
modern browsers do.

They openly state that a 'legal exit ramp' was one of their
primary goals but the real question is... did they make it?

So then Mark and Jean got hooked up with the .PNG
folks and cranked out ZLIB which also says it is 'completely
unencumbered by patents' yet the home page for ZLIB goes to
lengths to admit it is all based on 'gzip' and 'deflate'.

Obviously the confusion is whether or not there really are patents
on this stuff and even if there are not... if the GNU project claims
ownership of it on their own page does that mean it falls under
the GNU license, or not?

If you run GZIP from any command line you won't find it
saying anything about (C) and/or GPL. Is this just
intentional silence or does that really mean there is nothing
to worry about?


If you have any doubts from reading the page that the THEY
don't think the first list is, in fact, a comprehensive
list of 'GPL' licensed packages then just look at the
start of the next section...

> Descriptions of Other GPL-Covered Free Software
> These are some additional GPL or LGPL-covered free programs which
> wethink it is useful to mention.

Keyword is 'Other'. Semantics time? Does that mean LIST 1 is
definitely 'GPL' and the LIST 2 is 'more' of same... or does
it mean LIST 1 is questionable but LIST 2 is definite?
Hard to say what they really mean.

I certainly read it this way...
'LIST 1 is all GPL and LIST 2 is other GPL we wanted to mention.'


Home page:

> zlib is designed to be a free, general-purpose, legally unencumbered --
> that is, not covered by any patents -- lossless data-compression library
> for use on virtually any computer hardware and operating system. The
> zlib data format is itself portable across platforms. Unlike the LZW
> compression method used in Unix compress(1), the compression method
> currently used in zlib essentially never expands the data. (LZW can
> double or triple the file size in extreme cases.) zlib's memory
> footprint is also independent of the input data and can be reduced, if
> necessary, at some cost in compression. A more precise, technical
> discussion of both points is available on another page.

> zlib was written by Jean-loup Gailly (compression) and Mark Adler
> (decompression). Jean-loup is also the primary author/maintainer of
> gzip(1), the author of the comp.compression FAQ list and the former
> maintainer of Info-ZIP's Zip; Mark is also the author of gzip's and
> UnZip's main decompression routines and was the original author of Zip.
> Not surprisingly, the compression algorithm used in zlib is essentially
> the same as that in gzip and Zip, namely, the > deflate' method that
> originated in PKWARE's PKZIP 2.x.
Since the ZLIB origins are freely admitted the important issue
becomes 'Is there anything in there that's going to bite
you in the butt down the road'.

Let's see...


The actual 'RFC' defining the 'deflate' spec upon which the
all of the supposedly 'free' compressors is based can
be viewed at...

> Abstract
> This specification defines a lossless compressed data format that
> compresses data using a combination of the LZ77 algorithm and Huffman
> coding, with efficiency comparable to the best currently available
> general-purpose compression methods. The data can be produced or
> consumed, even for an arbitrarily long sequentially presented input data
> stream, using only an a priori bounded amount of intermediate storage.
> The format can be implemented readily in a manner not covered by
> patents.

The document details the risky LZ77 and Huffman details and
then suddenly it stops cold and makes this pronouncement...

> While it is the intent of this document to define the "deflate"
> compressed data format without reference to any particular compression
> algorithm, the format is related to the compressed formats produced by
> LZ77 (Lempel-Ziv 1977, see reference [2] below); since many variations
> of LZ77 are patented, it is strongly recommended that the implementor of
> a compressor follow the general algorithm presented here, which is known
> not to be patented per se. The material in this section is not part of
> the definition of the specification per se, and a compressor need not
> follow it in order to be compliant.

What that seems to mean at that point in the document is that "up until
now we think we are safe but we are so 'not sure' about it that we can't
even require the rest of the spec to be officially part of the spec."

It's the upcoming 'hashing' that leads to dark waters.

The rest of the document then describes how to finish the LZ77 and
Huffman compression passes but whether or not any particular implementation
of deflate 'crosses the line' into intellectual property is largely a
matter of interpretation of existing patents and licenses.

If the writers of the specification were so unsure of the second
phase that they decided they couldn't even actually require it
to be part of the spec then the confidence meter with regards to
exclusion from challenge is not running very high.

If this RFC is what gzip and zlib are really 'based' on then the
situation is actually a little shakier than anyone realizes.

Never challenged does not mean always safe.


There is no question that deflate ( base for gzip and zlib )
is itself based on a Huffman pass and some LZ77. The jury is
actually still out about all the little ways that LZ77 can
be 'tweaked' and this URL shows just some of the dozens of
patents ( and lawsuits ) surrounding LZ77...

Latest round in the bout was just a few years ago and Stac, Inc.
won a judgement of $120 MILLION dollars from Microsoft regarding
the use of LZ77 in MSDOS 6.0.

What is significant about that judgement is that Microsoft
did, in fact, spend a lot of time, money and energy making SURE
they had a version of LZ77 that no one could lay claim to
yet they still got slapped with the 120 MILLION fine.

IBM's LZ77 patent kicks in the moment you simply add any
kind of 'history' buffer during the hashing. I think that
one alone has paid for the landscaping bills at Armonk for
going on a decade now.

LZW kicked in AFTER LZ77 and that was when the 'danger'
flags went up because the addition of the 'windowing'
approach was obviously owned by IBM and UNISYS.

LZ78 was very questionable ( That's when Lempel, Ziv, Cohn,
Eastman and UNISYS got involved ) so everyone fell back to LZ77
and thought they were 'safe' from old Ziv and Lempel's
territorial leanings.

As a side note... IBM and UNISYS hold the patents on the
LZW compression being used in the V.42bis modem compression that
everyone seems to have so much faith in. No modem manufacturer
has been sued as of yet... even though It's pretty likely not
all of them have signed the proper documents.

IBM holds all the cookies with arithmetic encoding. There is
no JPEG file on earth that does not use the patented schemes.

The other fascinating legal issue for compressing data on
the Internet is that most of these patents are not 'worlwide'.
If a server sitting in France does the compression for users
in the U.S. then it is debatable whether certain patents
even apply because even though you are 'getting' the
international data compressed ( as well you should ) the
compression itself was not actually 'performed' within
U.S. borders.

Any international lawyers out there watching?

If so... any opinions on that one?

Kevin Kiley
CTO, Remote Communications, Inc.
RCPTDS real-time online document compression server

View raw message