[Zlib-devel] Re: deflate 64

[Mark Adler]

On Wednesday, August 27, 2003, at 06:04 AM, Cosmin Truta wrote:
> Deflate64 is hurtful for it does more harm than good: it is a weak gain
> in compression that diminishes the zip portability in return.

Indeed, it is one of several shots that PKWare has fired into its foot.

> The fact is that deflate64 exists, and I am neither sustaining, nor
> opposing its support in zlib. I just wanted to have the legal issues
> clarified.

As far as legal issues, I believe that reverse-engineering the 
deflate64 format falls under the "fair-use" clause of US copyright law, 
and the implementation of it would infringe on no patents (so long as 
the current zlib infringes on no patents, which we believe is the case).

There are some questions about the legality in general of 
reverse-engineering under the recently passed DMCA in the US.  However 
this legal uncertainty has no bearing whatsoever on my reluctance to 
implement deflate64 decoding.  I have already accepted such legal risks 
with the distribution of my "blast" code (in the contrib directory) 
which decodes the truly wretched PKWare Data Compression Library format 
using a reverse-engineered description of the format.  I did this as a 
courtesy to many people out there who have data "trapped" in files 
compressed by DCL that they want to liberate.

My refusal to implement deflate64 decoding in zlib remains.  This 
results from a) the fact that PKWare has abandoned their open format 
promise and so I do not want to assist them in this by supporting their 
undocumented formats, b) the benefit of deflate64 is minimal to 
negative, and so it just doesn't seem to be worth my time to bother 
with, and c) we would certainly never implement deflate64 compression 
in zlib, and so it's cleaner to have symmetric code and avoids the 
endless emails about why deflate64 compression is not implemented when 
decompression is.

If someone wants to write patches to zlib to support deflate64, I will 
include those in the contrib directory, but I do not want to support 
them in zlib.

mark