Is ZIP in the public domain or not?

By Rick Jelliffe
June 22, 2010 | Comments: 7

What is the IP status of ZIP? This is a question of interest to standardizers and developers implementing standards, because so many new standards use ZIP. ODF and OOXML for example.

Here is what the current PKWARE site says (with my bolding):

Phil Katz founded PKWARE, Inc. in 1986 and was the author of the world-renowned PKZIP/UNZIP programs. He was born November 3, 1962 and passed away April 14, 2000. Phil was a graduate of the University of Wisconsin-Milwaukee's Computer Science Engineering program.

Phil's contributions to the computer industry were many, including work with Bulletin Board Systems, as well as many computer user groups and support forums. His decision to dedicate the .ZIP extension and file format specification to the public domain helped the .ZIP file format become a globally open standard.

PKWARE continues to honor Phil Katz's vision through continuing innovation and support of the ZIP standard.

And here is what the PKWARE FAQ said in 1996, according to the Wayback Machine (again with my bolding):

What platforms is PKZIP currently available for?
PKWARE currently supports PKZIP on MS-DOS, OS/2, Windows 3.1x, Windows 95, Windows NT 3.51+, and OpenVMS VAX and Alpha environments. PKWARE intends to support additional platforms and will announce these as they become available. Some of those platforms currently under consideration are UNIX and Macintosh.

Because PKWARE has dedicated the .ZIP file format to the public domain, it is possible for other people to write programs which can read .ZIP files.

NOTE THAT THE PKZIP, PKUNZIP, PKSFX PROGRAMS AND THEIR ASSOCIATED SOURCE CODE AND SUPPORT PROGRAMS ARE THE EXCLUSIVE PROPERTY OF PKWARE INC. AND ARE NOT PUBLIC DOMAIN SOFTWARE PROGRAMS.

We are currently aware of PKUNZIP compatible programs for a number of different platforms. A .ZIP file can be transferred to any platform for which you can find a compatible extraction program.

Extraction and Compression programs not developed by PKWARE may not be completely compatible with the .ZIP file standard.

Contact PKWARE for a list of platforms for which PKZIP and PKZIP compatible software is available.

Can you see the difference? In 1986, when Phil Katz was alive, the Public Domain grant was for the "format" while now in 2010 it is for the "extension and file format specification."

Does this make a difference? I am not a lawyer. But in Wikipedia it deals with Public Domain under three heads: Public Domain and Copyright, Public Domain and Patents, and Public Domain and Trademarks.

It seems to me that the current wording from PKWARE makes it sound like it is only the trademark (ZIP extension) and the copyright of the specification (appnote.txt) that is in the public domain. However, the original wording from PKWARE makes it clear that it is the format itself that is in the public domain. Phil Katz and PKWARE explicitly gave up any IP claims on the original version of ZIP. Indeed, Katz personally helped the open source InfoZIP implementation.

The reason that this is of interest is that I have heard that there is resistance to the idea of an ISO standard for ZIP because of some nebulous assertion that it might tread on PKWARE's IP.

But Katz gave the bloody thing away! That is why ZIP is popular, why it is even considered for use by ODF and OOXML and so on. If the plain and minimal form of ZIP as used by ODF and OOXML is actually encumbered in some way, then whoever owns that is not PKWARE. And they would need to have some pretty clever lawyers to have 1986 vintage patents still enforceable!

So if Katz/PKWARE put ZIP the format into public domain in 1989 (is that right), who is claiming it somehow isn't? (Round up the usual suspects: hmmm, name a couple of major corporations dedicated to talking about openness while amassing as many patents as fast as the ludicrous US patent system can print them? Companies who really don't want successful technologies they have bet on to be taken out of their effective guidance.)

I don't know if the PKWARE people are trying to have it both ways. [UPDATE] I have heard of a claim that no version of ZIP after 1990 has been public domain. However, that does not square with the comment on the PKWARE website still in 1996 that ZIP iwas then in the public domain: Because PKWARE has dedicated the .ZIP file format to the public domain, it is possible for other people to write programs which can read .ZIP files.[/UPDATE]

By 2001 (v4.5 introduced extensions for archives greater than 4 Gig) PKWARE were trying to position themselves at the centre

As steward of the .ZIP file format, PKWARE is committed to continuing to support the interoperability of ZIP products and to add value to the ubiquitous .ZIP file format for the benefit of users. Leveraging more than a dozen years of domain expertise and technology leadership, PKWARE has the knowledge and ability to guide the advancement of data compression industry standards and to continue to innovate the company's value-added ZIP software products.

When we look at the current text for the APPNOTE.TXT we find it has a copyright notice. Now how can a text be copyright and in the public domain at the same time? And here is what they currently say about the appnote:

This APPNOTE specification may be referenced in other specifications that may benefit from this technology providing the authors of those specifications work to ensure the on-going interoperability of this format. Some ZIP technology is covered by patents or pending patents. If your application requires use of ZIP technology that is covered under a patent, PKWARE does provide reasonable and non discriminatory licensing.

So putting it together in a conservative fashion, what do we come up with?

  • Regarding trademarks: the ZIP name is not trademark and was put in the public domain by Katz/PKWARE.
  • Regarding copyright: The initial version of the appnote.txt may have been put in the public domain, but it is not important. Additions are copyright PKWARE, however PKWARE have granted a general licence.
  • Regarding patents: The initial version of the format was put into the public domain by Katz/PKWARE. The initial version used a compression method (DEFLATE) that Katz designed to be implemented readily in a manner not covered by patents according to RFC 1951 which now defines DEFLATE. However, subsequent additions to the file format may be subject to patents, in particular regarding to more complex forms of compression and encruption.

So, an ISO standard for ZIP should be on solid ground if


  • It does not use any text directly from the APPNOTE.TXT but re-expresses it.

  • It only provides DEFLATE compression and no encryption, which prevents any patent traps.

  • It limits itself to features in APPNOTES before, say, 1995 (i.e. 2012 potential standardization date minus 17 years US patent time) or to features reasonably considered non-patentable.)

So what safe profile of ZIP would that give us? That would be approximately ZIP 2 (which is what everyone implements) plus support for UTF-8 names (unpatentable). The only thing that might need to be looked into is whether the ZIP64 (archives longer than 4gig feature of ZIP4.5) was included. I believe this is what the proponents of the proposed ISO ZIP effort have been thinking about.

I think it is useful to note that there is no suggestion that an ISO committee would take over stewardship of the development of the format. If PKWARE and industry are being responsive to their customer's requirements, then they can do that better. What an ISO ZIP specification would be is a ratification or endorsement of the most basic common subset of ZIP: it would reflect ZIP's primacy not threaten it.

However, it seems to me that if basic common ZIP is somehow not in the public domain encumbered (as I hear some US corporations are FUDding, though I would expect to see some evidence before I disbelieve the Wayback Machine!) then that would surely be a reason to disallow it from being used in any other open standards and develop some unencumbered technology!

Other issues

I have heard a couple of other reasons against a standard for ZIP. One is that ISO is not a good forum for this. I might agree, but since ISO SC34 is the only forum stepping up to the plate, that argument carries no weight.

Another is that there are other archiving formats at ISO that should be used, and that having a standard for ZIP would cause confusion with, say, the MPEG group's work. But the horse has bolted on that one: ODF and OOXML are already ISO standards. And the rule that a standard can only normatively reference another standard was set aside on the assurance that there would indeed be an effort to standardize ZIP. In any case, ZIP is so critical to many archiving and data interchange efforts, it deserves something a bit better than a little file tucked away on some companies website with conflicting copyright information!

The other comment I have heard is that having a separate specification from APPNOTE.TXT would necessarily create inconsistencies that would work against interoperability. This is an interesting and more substantial point. However, since the file format is not the subject of some complex algorithm (remembering that the compression is specified in an RFC), and only a handful of constants of interest, it is well within the capabilities of even a standards group to express them correctly in a different arrangement than the APPNOTE.TXT (with no disrespect to it.)

Of course, what would be easier would be for PKWARE to participate. I don't know why they don't. They could clearly state that they were not granting licenses to any of their compression and encryption or signing IP from the outset, and they would not have any risk there. The standard profile would comfortably be around ZIP 4.5 +UTF-8, you would expect.

As always, I welcome comments about where my logic is wrong. A standard for ZIP should be a simple small thing that just puts our current practice on a better footing: I don't see it would change any market dynamics. FUD against it on the grounds of PKWARE's IP needs to explain how a technology put into the public domain magically becomes proprietary again. FUD against it on the grounds of PKWARE's supposed faithful stewardship needs to consider that it is only a minimal standard being proposed with no technical or market-altering agenda.

Remember that Phil Katz started PKWARE and put ZIP into the public domain because of a previous dispute over IP. He wanted to have a format that developers could use without worrying about those encumbrances, it seems. It is surprising to me that people could be trying to backpedal his famous motivation and re-vest the file format IP in PKWARE by some imaginary method.

[UPDATE] Another argument I have heard is that the proposal for an ISO ZIP has come out of the blue. But the topic of the status of ZIP was discussed throughout the ODF and OOXML standardization efforts. At the SC34 plenary in IIRC, Kyoto 2008 2006, I was tasked with following up with PKWARE on the status of ZIP. They did not reply, and I later reported this at another plenary. I am not a real It is a dubious proposition that APPNOTE.TXT at PKWARE meets the requirements of JTC1 for a recognized external standard, since it does not come out of any formal process or have any formal QA mechanism but merely contains whatever PKWARE wants it too at the time. (And if it does, why bother to have any standards process at all for anything? Why not just kowtow to US vendors?)

If PKWARE wants to prevent a minimal profile of ZIP from being developed, it is too late: ODF and OOXML and the specifications already give rough indications of features not to be used and of how to use some other features. But I would have thought the FOSS community would be interested in an explicit safe profile, and PKWARE should not be surprised if the rest of us find PKWARE's apparant desire that the trumpeted "public domain" ZIP format should actually just be an onramp into licensed technologies for the unwary unconvincing.

There has been a lot of talk over recent times of the dangers of submarine patents: and yet with broad ZIP that seems to be the risk: a company proclaims a technology to be an 'open standard' or 'public domain', people adopt on this basis, but then find out in the fine print that it is not the case. A safe profile would not be a bad idea, I think.

If PKWARE wants to be constructive, let then form an OASIS group and put the development of APPNOTE.TXT into its hands. Be explicit about what is being contributed or royalty-free licensed etc. Mark encumbered and icenseable portions clearly, so that people can cross out parts they don't want (and come up with the safe profile in a DIY fashion.)


You might also be interested in:

7 Comments

In APPNOTE.txt, PKWARE now says:

... However, the use or implementation in a product of certain technological aspects set forth in the current APPNOTE, including those with regard to strong encryption, patching, or extended tape operations requires a license from PKWARE. Please contact PKWARE with regard to acquiring a license.

I believe that specs (e.g., EPUB) based
on ZIP avoid strong encryption and patching.
But extended tape operations (i.e., ZIP64)
are different. If we omit ZIP64, we cannot
handle some gigantic archives. Is ZIP64
really protected by a patent?

Muratasensei:

In 1993, the ZIP 2 format came out. It supported DEFLATE and spanning archives to multiple disks.

In 2001, ZIP 4.5 format came out. It supports ZIP64, which allowed more than 65535 files per ZIP archives, and storing files larger than 4 gigabytes into .ZIP archive. The patent of interest seems to be http://www.patentstorm.us/patents/7624132/fulltext.html which is a revision of http://www.patentstorm.us/patents/6879988/fulltext.html (It would be useful for someone to check them to see exactly what is being covered.)

Since the aim of an ISO ZIP would be to support ODF and OOXML, etc, I do not see that it is a high priority for the initial version to support either very large files (which would be video or binaries). There may be better formats for these: the MPEG people should perhaps be looking after that: all SC34 needs to do is support office applications.

The ability to support larger numbers of files is certainly useful, however, I do not believe it is a showstopper for support for a limited standard. What the ISO ZIP would give would be a profile with known IP status suitable for the lion's share of actual documents. The 65535 file limit is most likely to be exceeded by documents with 65520 images: are these really such an important use case?

If ZIP64 is encumbered, and therefore the FOSS community needs to get licenses from a non-participant in the standards process to use it, they should indeed be warned that ZIP is not an Open Standard, and that ODF and OOXML, if they use these, may have an unacceptable base.

Note, ZIP64 and DEFLATE64 have a TM sign on the PKWARE site. From http://www.binaryessence.com/dct/imp/en000225.htm

"Besides PKWARE and a large number of commercial application some freeware and open source projects support Deflate64™:

7-Zip

Info-ZIP (Zip, UnZip)

The zlib project does not support Deflate64™. According to the zlib FAQ, this is due to the low improvements and the decision of PKWARE to handle Deflate64™ as a proprietary format."

According to http://www.spiritus-temporis.com/pkware-inc/patents.html

"Phil Katz was granted a patent in September, 1991 for his efficient search functions used in the PKZIP compression process.Patent 5,051,745

~ ~ ~ ~ ~ ~ ~ ~ ~ ~

In 2001 and 2005, PKWARE was awarded patents for patching technology used within PKZIP products.Patent 6,289,509 and Patent 6,952,823 In 2005, PKWARE was awarded a patent for methods used to manage .ZIP files within the Windows file manager and Outlook.Patent 6,879,988 In total PKWARE holds four patents, has over fourteen pending patents and is referenced in over eighty patents."

I am confused.
ZIP (all caps) is a registered trademark of the USPS. It is not in the public domain.

Dave: A trademark on ZIP used for USPS says nothing about ZIP for other uses: see Harvard Law http://cyber.law.harvard.edu/metaschool/fisher/domain/tm.htm

"On the other end of the spectrum, using the same term on a completely unrelated product will not likely give rise to an infringement claim. Thus, Apple Computer and Apple Records can peacefully co-exist, since consumers are not likely to think that the computers are being made by the record company, or vice versa."

ZIP probably could not be trademarked now in any case due to genericity: "A word will be considered generic when, in the minds of a substantial majority of the public, the word denotes a broad genus or type of product and not a specific source or manufacturer. So, for example, the term "thermos" has become a generic term and is no longer entitled to trademark protection. Although it once denoted a specific manufacturer, the term now stands for the general type of product."

Nice and fantastic hair style.

The ZIP archive format is also used in XPS, following the OOXML container spec. In the print industry, jobs requiring more than 65535 files (e.g large bill of materials, end of month account statements), an archive more than 4GiB (many high res contone 4 color images that don't compress well), or even a single part larger then 4GiB are common (large format high res color image). ZIP4.5 is required for XPS to be practical (UTF-8 file name support is not needed).

Yes. Software businesses who may want to implement XPS systems need to know exactly what the licensing status of ZIP is. Ditto for governments or others who may want to add XPS to lists of allowed open formats.

It seems that XPS with ZIP64 (ZIP 4.5) could not be an open standard, while XPS using the smaller file size could be (if ZIP was actually documented through a standards body). Consequently, any file format which builds on top of ZIP64 cannot be considered an open format. Very regrettable.

News Topics

Recommended for You

Got a Question?