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
Other issuesI 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.)