[Zlib-devel] Re: deflate 64

[Gilles Vollant]

<<
AFAIK, PKWARE has not published deflate64, nor has it said anything about
the right to reverse engineer and re-implement it. Is it public domain or
not? I thought it doesn't hurt to check.>>
Yes, it is a good idea checking.

Three points (but this is not an answer to the questions)
- pkware describe Deflate 64 in their doc, so pehaps this can mean they
include it in open format. The problem is that their description is very
poor, and don't contain information needed for write compatible inflate
code.
- The legal problem is the same for unzip 5.5x
- and, do you remember the PKWare problem with ARC 15 year ago ?
PKWare made a ARC compatible software (PKARC). ARC was not open format. The
ARC maker company win a trial againt PKWare. So PKWare made a new format,
Zip, and decided publish full specification in a public file appnotes.txt.
After Infozip started working with this appnotes.txt

ZIP/Deflate live by replacing no-open format and compression scheme (ARC
first, and PNG is replacing GIF/LZW)

Unfortunatelly, Phil Katz had died. And the quality of new specification in
appnotes is not good. I've read the new encryption documentation is not
complete...

I'm angry againt PKWare who broke the open zipfile spirit. And it seem noone
has real contact at PKWare to ask them modify appnotes (they never
answer...).

ZIPformat is a very major format in the PC/Windows world. Breaking his
compatibility is bad...

-----Message d'origine-----
De : Zlib-devel-bounces at zlib.net [mailto:Zlib-devel-bounces at zlib.net] De la
part de Cosmin Truta
Envoyé : mercredi 27 août 2003 18:05
À : Zlib-devel at zlib.net
Objet : Re: [Zlib-devel] Re: deflate 64


On Wed, 27 Aug 2003, Greg Roelofs wrote:



AFAIK, PKWARE has not published deflate64, nor has it said anything about
the right to reverse engineer and re-implement it. Is it public domain or
not? I thought it doesn't hurt to check.


> FWIW, I'm perfectly fine with whatever Mark wants to do.  64 isn't a 
> major win for anything but marketing, and if only one application 
> really needs that support for compatibility reasons, then maybe the 
> best place to add the relevant routine is in the application itself.

Deflate64 is hurtful for it does more harm than good: it is a weak gain in
compression that diminishes the zip portability in return.

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.


Cosmin