The GIF Controversy: A Software Developer's Perspective Reference Section January 27, 1995 - Text revision 2 - March 31, 1995 by Michael Console Battilana Copyright (c) 1995 Cloanto Italia srl, All rights reserved Parts are quoted with permission from CompuServe Information Service Parts are excerpted from the PNG specification Permission granted for non-profit electronic distribution Suggested file name: "giflzw2.txt" Keywords: GIF PNG LZW WELCH COMPRESSION UNISYS PATENT HISTORY TEXT Free by mailing before April 30, 1995 This article was written with great care. It may reflect personal opinions of the author, which are not necessarily shared by the publishers, who cannot assume any responsibility for mistakes or misprints. Nothing in this article should be regarded as legal counsel. If you require legal or other expert assistance, you should consult a professional advisor. Many of the designations used by manufacturers and sellers to distinguish their products are trademarks. The author of this article has made every attempt to supply trademark information about manufacturers and their products. GIF and Graphics Interchange Format are service marks of CompuServe Inc., an H&R Block Company. PostScript is a registered trademark of Adobe Systems Inc. TIFF is a trademark of Aldus Corp. The main article text should be available in another file accompanying this text (suggested file name: "giflzw1.txt"). It can also be requested via E-mail to before April 30, 1995. Reference Section [search key: #1] ----------------------------------------------------------------------- Excerpts from the PNG (Portable Network Graphics) Specification, Ninth Draft - Revision date: 7 March, 1995 0. Status This is the ninth draft of the PNG specification. All future drafts will be backward-compatible with the graphics file format described by this document. Implementations are invited, and a reference implementation is under development; see below. [...] Reference Implementation It is anticipated that a finished standard and reference implementation will be available by the end of March [1995]. The reference implementation will be freely usable in all applications, including commercial applications. 1. Introduction The PNG format is intended to provide a portable, legally unencumbered, well-compressed, well-specified standard for lossless bitmapped image files. Although the initial motivation for developing PNG was to replace GIF, the design provides some useful new features not available in GIF, with minimal cost to developers. GIF features retained in PNG include: Palette-mapped images of up to 256 colors. Streamability: files can be read and written strictly serially, thus allowing the file format to be used as a communications protocol for on-the-fly generation and display of images. Progressive display: a suitably prepared image file can be displayed as it is received over a communications link, yielding a low-resolution image very quickly with gradual improvement of detail thereafter. Transparency: portions of the image can be marked as transparent, allowing the effect of a nonrectangular image area to be achieved. Ancillary information: textual comments and other data can be stored within the image file. Complete hardware and platform independence. Effective, 100% lossless compression. Important new features of PNG, not available in GIF, include: Truecolor images of up to 48 bits per pixel. Grayscale images of up to 16 bits per pixel. Full alpha channel (general transparency masks). Gamma (brightness) indication, allowing automatic brightness adjustment. Early and straightforward detection of file corruption. Faster initial presentation in progressive display mode. PNG is intended to be: Simple and portable: PNG should be widely implementable with reasonably small effort for developers. Legally unencumbered: to the best of the knowledge of the PNG authors, no algorithms under legal challenge are used. Well compressed: both palette-mapped and truecolor images are compressed as effectively as in any other widely used lossless format, and in most cases more effectively. Interchangeable: any standard-conforming PNG decoder will read all conforming PNG files. Flexible: the format allows for future extensions and private add-ons, without compromising interchangeability of basic PNG. Robust: the design supports full file integrity checking as well as simple, quick detection of common transmission errors. [...] Pronunciation PNG is pronounced "ping". [...] 10. Appendix: Rationale (This appendix is not part of the formal PNG specification.) This appendix gives the reasoning behind some of the design decisions in PNG. Many of these decisions were the subject of considerable debate. The authors freely admit that another group might have made different decisions; however, we believe that our choices are defensible and consistent. Why a new file format? Does the world really need yet another graphics format? We believe so. GIF is no longer freely usable, but no other commonly used format can directly replace it, as is discussed in more detail below. We might have used an adaptation of an existing format, for example GIF with an unpatented compression scheme. But this would require new code anyway; it would not be all that much easier to implement than a whole new file format. (PNG is deliberately designed so that it is very simple to implement, with the exception of the compression engine, which would be needed in any case.) We feel that this is an excellent opportunity to design a new format that fixes some of the known limitations of GIF. Why these features? The features chosen for PNG are intended to address the needs of applications that previously used the special strengths of GIF. In particular, GIF is well adapted for on-line communications because of its streamability and progressive display capability. PNG shares those attributes. We have also addressed some of the widely known shortcomings of GIF. In particular, PNG supports truecolor images. We know of no widely used image format that losslessly compresses truecolor images as effectively as PNG does. We hope that PNG will make use of truecolor images more practical and widespread. Some form of transparency control is desirable for applications in which images are displayed against a background or together with other images. GIF provided a simple transparent-color specification for this purpose. PNG supports a full alpha channel as well as transparent-color specifications. This allows both highly flexible transparency and compression efficiency. Robustness against transmission errors has been an important consideration. For example, images transferred across Internet are often mistakenly processed as text, leading to file corruption. PNG is designed so that such errors can be detected quickly and reliably. PNG has been expressly designed not to be completely dependent on a single compression technique. Although inflate/deflate compression is mentioned in this document, PNG would still exist without it. Why not these features? Some features have been deliberately omitted from PNG. These choices were made to simplify implementation of PNG, promote portability and interchangeability, and make the format as simple and foolproof as possible for users. In particular: There is no uncompressed variant of PNG. This would merely create another case for decoders to worry about, and it would make the format appear more complex for users. ("Why did my 60K file suddenly become 300K?") There is no lossy compression in PNG. Existing formats such as JFIF already handle lossy compression well. Furthermore, available lossy compression methods (eg, JPEG) are far from foolproof to use --- a poor choice of quality level can ruin an image. To avoid user confusion and unintentional loss of information, we feel it is best to keep lossy and lossless formats strictly separate. Also, lossy compression is complex to implement. Adding JPEG support to a PNG decoder might increase its size by an order of magnitude. This would certainly cause some decoders to omit support for the feature, which would destroy our goal of interchangeability. There is no support for CMYK or other unusual color spaces. Again, this is in the name of promoting portability. CMYK, in particular, is far too device-dependent to be useful as a portable image representation. There is no standard chunk for thumbnail views of images. In discussions with software vendors who use thumbnails in their products, it has become clear that most would not use a "standard" thumbnail chunk. This is partly because every vendor has a distinct idea of what the dimensions and characteristics of a thumbnail should be, and partly because vendors who keep thumbnails in separate files to accommodate varied image formats are not going to stop doing that simply because of a thumbnail chunk in one new format. Proprietary chunks containing vendor-specific thumbnails appear to be more practical than a common thumbnail format. It is worth noting that private extensions to PNG could easily add these features. We will not, however, admit them as part of the basic PNG standard. Basic PNG also does not support multiple images in one file. This restriction is a reflection of the reality that many applications do not need and will not support multiple images per file. (While the GIF standard nominally allows multiple images per file, few applications actually support it.) In any case, single images are a fundamentally different sort of object from sequences of images. Rather than make false promises of interchangeability, we have drawn a clear distinction between single-image and multi-image formats. PNG is a single-image format. Why not use format XYZ? Numerous existing formats were considered before deciding to develop PNG. None could meet the requirements we felt were important for PNG. GIF is no longer suitable as a universal standard because of legal entanglements. Although just replacing GIF's compression method would avoid that problem, GIF does not support truecolor images, alpha channels, or gamma correction. The spec has more subtle problems too. Only a small subset of the GIF89 spec is actually portable across a variety of implementations, but there is no codification of the most portable part of the spec. TIFF is far too complex to meet our goals of simplicity and interchangeability. Defining a TIFF subset would meet that objection, but would frustrate users making the reasonable assumption that a file saved as TIFF from Software XYZ would load into a program supporting our flavor of TIFF. Furthermore, TIFF is not designed for stream processing, has no provision for progressive display, and does not currently provide any good, legally unencumbered, lossless compression method. IFF has also been suggested, but is not suitable in detail: available image representations are too machine-specific or not adequately compressed. The overall "chunk" structure of IFF is a useful concept which PNG has liberally borrowed from, but we did not attempt to be bit-for-bit compatible with IFF chunk structure. Again this is due to detailed issues, notably the fact that IFF FORMs are not designed to be serially writable. Lossless JPEG is not suitable because it does not provide for the storage of palette-color images. Furthermore, its lossless truecolor compression is often inferior to that of PNG. Byte order It has been asked why PNG uses network byte order. We have selected one byte ordering and used it consistently. Which order in particular is of little relevance, but network byte order has the advantage that routines to convert to and from it are already available on any platform that supports TCP/IP networking, including all PC platforms. The functions are trivial and will be included in the reference implementation. Interlacing PNG's two-dimensional interlacing scheme is slightly more complex to implement than GIF's line-wise interlacing. It also costs a little more in file size. However, it yields an initial image eight times faster than GIF (the first pass transmits only 1/64th of the pixels, compared to 1/8th for GIF). Although this initial image is coarse, it is useful in many situations. For example, if the image is a World Wide Web imagemap which the user has seen before, PNG's first pass is enough to determine where to click. The PNG scheme also looks better than GIF's, because horizontal and vertical resolution never differ by more than a factor of two; this avoids the odd "stretched" look seen when interlaced GIFs are filled in by replicating scanlines. Why gamma correction? Although gamma 1.0 (linear brightness response) might seem a natural standard, it is common for images to have a gamma of less than 1. There are two good reasons for this: CRT hardware typically has a gamma between 2 and 3. Hence, "gamma correction" is a standard part of all video signals. The transmitted image usually has a gamma of 0.45 (NTSC) or 0.36 (PAL/SECAM), so images obtained by frame-grabbing video already have this value of gamma. An image gamma less than 1 allocates more of the available pixel codes or voltage range to darker areas of the image. This allows photographic-quality images to be stored in only 24 bits/pixel without banding artifacts in the darker areas (in most cases). This makes "gamma encoding" a much better way of storing digital images than the simpler linear encoding. In practice, image gamma values around 1.0 and around 0.45 are both widely found. Older image standards such as GIF often do not account for this fact, leading to widespread problems with images coming out too dark or too light. PNG expects viewers to compensate for image gamma at the time that the image is displayed. Another possible approach is to expect encoders to convert all images to a uniform gamma at encoding time. While that method would speed viewers slightly, it has fundamental flaws: Gamma correction is inherently lossy due to roundoff error. Requiring conversion at encoding time thus causes irreversible loss. Since PNG is intended to be a lossless storage format, this is undesirable; we should store unmodified source data. The encoder might not know the image gamma. If the decoder does gamma correction at viewing time, it can adjust the gamma (correct the displayed brightness) in response to feedback from a human user. The encoder has no such option. Whatever "standard" gamma we settled on would be wrong for some displays. Hence viewers would still need gamma correction capability. Since there will always be images with no gamma or an incorrect recorded gamma, good viewers will need to incorporate gamma correction logic anyway. Gamma correction at viewing time is thus the right way to go. Filtering PNG includes filtering capability because filtering can significantly reduce the compressed size of truecolor and grayscale images. Filtering is also sometimes of value on palette images, although this is less common. The filter algorithms are defined to operate on bytes, rather than pixels, for simplicity and speed. Tests have shown that filtering is ineffective for images with fewer than 8 bits per pixel. The filters will most often be used on 8-bit-precision data. A final reason for not using pixel-based filtering is that if an 8-bit decoder plans to discard the low order byte of 16-bit data, it can do so before reversing the filter, boosting decoder speed. The encoder is allowed to change filters for each new scanline. This creates no additional complexity for decoders, since a decoder is required to contain unfiltering logic for every filter type anyway. The only cost is an extra byte per scanline in the pre-compression data stream. Our tests showed that when the same filter is selected for all scanlines, this extra byte compresses away to almost nothing, so there is little storage cost compared to a fixed filter specified for the whole image. And the potential benefits of adaptive filtering are too great to ignore. Even with the simplistic filter-choice heuristics so far discovered, adaptive filtering usually outperforms fixed filters. In particular, an adaptive filter can change behavior for successive passes of an interlaced image; a fixed filter cannot. The basic filters offered by PNG have been chosen on both theoretical and experimental grounds. In particular, it is worth noting that all the filters (except "none" and "average") operate by encoding the difference between a pixel and one of its neighboring pixels. This is usually superior to conventional linear prediction equations because the prediction is certain to be one of the possible pixel values. When the source data is not full depth (such as 5-bit data scaled up to 8-bit depth), this restriction ensures that the number of prediction delta values is no more than the number of distinct pixel values present in the source data. A linear equation can produce intermediate values not actually present in the source data, and thus reduce compression efficiency. Text strings Most graphics file formats include the ability to store some textual information along with the image. But many applications need more than that: they want to be able to store several identifiable pieces of text. For example, a database using PNG files to store medical X-rays would likely want to include patient's name, doctor's name, etc. A simple way to do this in PNG would be to invent new proprietary chunks holding text. The disadvantage of such an approach is that other applications would have no idea what was in those chunks, and would simply ignore them. Instead, we recommend that text information be stored in standard tEXt chunks with suitable keywords. Use of tEXt tells any PNG viewer that the chunk contains text that may be of interest to a human user. Thus, a person looking at the file with another viewer will still be able to see the text, and even understand what it is if the keywords are reasonably self-explanatory. (For the same reason, we recommend spelled-out keywords, not abbreviations that will be hard for a person to understand. Saving a few bytes on a keyword is false economy.) The ISO 8859-1 (Latin-1) character set was chosen as a compromise between functionality and portability. Some platforms cannot display anything more than 7-bit ASCII characters, while others can handle characters beyond the Latin-1 set. We felt that Latin-1 represents a widely useful and reasonably portable character set. There is at present no provision for text employing character sets other than the ISO 8859-1 (Latin-1) character set. It is recognized that the need for other character sets will increase. However, PNG already requires that programmers implement a number of new and unfamiliar features, and text representation is not PNG's primary purpose. Since PNG provides for the creation and public registration of new ancillary chunks of general interest, it is expected that chunks for other character sets, such as Unicode, will be registered and increase gradually in popularity. PNG file signature The first eight bytes of a PNG file always contain the following values: (decimal) 137 80 78 71 13 10 26 10 (hex) 89 50 4e 47 0d 0a 1a 0a (C notation) \211 P N G \r \n \032 \n The first two bytes distinguish PNG files on systems that expect the first two bytes to identify the file type uniquely. The first byte is chosen as a non-ASCII value to reduce the probability that a text file may be misrecognized as a PNG file; also, it catches bad file transfers that clear bit 7. Bytes two through four (overlap with the first two intentional) name the format. The CR-LF sequence catches bad file transfers that alter these characters. The control-Z character stops file display under MS-DOS. The final line feed checks for the inverse of the CR-LF translation problem. Note that there is no version number in the signature, nor indeed anywhere in the file. This is intentional: the chunk mechanism provides a better, more flexible way to handle format extensions, as is described below. Chunk layout The chunk design allows decoders to skip unrecognized or uninteresting chunks: it is simply necessary to skip the appropriate number of bytes, as determined from the length field. Limiting chunk length to (2^31)-1 bytes avoids possible problems for implementations that cannot conveniently handle 4-byte unsigned values. In practice, chunks will usually be much shorter than that anyway. A separate CRC is provided for each chunk in order to detect badly-transferred images as quickly as possible. In particular, critical data such as the image dimensions can be validated before being used. The chunk length is excluded in order to permit CRC calculation while data is generated (possibly before the length is known, in the case of variable-length chunks); this may avoid an extra pass over the data. Excluding the length from the CRC does not create any extra risk of failing to discover file corruption, since if the length is wrong, the CRC check will fail (the CRC will be computed on the wrong bytes and tested against the wrong value from the file besides). Chunk naming conventions The chunk naming conventions allow safe, flexible extension of the PNG format. This mechanism is much better than a format version number, because it works on a feature-by-feature basis rather than being an overall indicator. Decoders can process newer files if and only if the files use no unknown critical features (as indicated by finding unknown critical chunks). Unknown ancillary chunks can be safely ignored. Experience has shown that version numbers tend to be set unnecessarily high, leading to older decoders rejecting files that they could in fact process (this was a serious problem for several years after the GIF89 spec came out, for example). Furthermore, private extensions can be either critical or ancillary, and standard decoders will react appropriately; version numbers are no help for private extensions. A hypothetical chunk for vector graphics would be a critical chunk, since if ignored, important parts of the intended image would be missing. A chunk carrying the Mandelbrot set coordinates for a fractal image would be ancillary, since other applications could display the image without understanding what it was. In general, a chunk type should be made critical only if it is impossible to display a reasonable representation of the intended image without interpreting that chunk. The public/private property bit ensures that any newly defined public chunk types cannot conflict with proprietary chunks that may be in use somewhere. However, it does not protect users of private chunks from the possibility that someone else may re-use the same chunk name for a different purpose. It is a good idea to put additional identifying information at the start of the data for any private chunk type. When a PNG file is modified, certain ancillary chunks may need to be changed to reflect changes in other chunks. For example, a histogram chunk needs to be changed if the image data changes. If the encoder does not recognize histogram chunks, copying them blindly to a new output file is incorrect; such chunks should be dropped. The safe/unsafe property bit allows ancillary chunks to be marked appropriately. Not all possible modification scenarios are covered by the safe/unsafe semantics; in particular, chunks that are dependent on the total file contents are not supported. (An example of such a chunk is an index of IDAT chunk locations within the file: adding a comment chunk would inadvertently break the index.) Definition of such chunks is discouraged. If absolutely necessary for a particular application, such chunks may be made critical chunks, with consequent loss of portability to other applications. In general, ancillary chunks may depend on critical chunks but not on other ancillary chunks. It is expected that mutually dependent information should be put into a single chunk. In some situations it may be unavoidable to make one ancillary chunk dependent on another. Although the chunk property bits do not allow this case to be represented, a simple solution is available: in the dependent chunk, record the CRC of the chunk depended on. It can then be determined whether that chunk has been changed by some other program. The same technique may be useful for other purposes. For example, if a program relies on the palette being in a particular order, it may store a private chunk containing the CRC of the PLTE chunk. If this value matches when the file is again read in, then it provides high confidence that the palette has not been tampered with. Note that it is not necessary to mark the private chunk unsafe-to-copy. Palette histograms A viewer may not be able to provide as many colors as are listed in the image's palette. (For example, some colors may be reserved by a window system.) To produce the best results in this situation, it is helpful to have information on the frequency with which each palette index actually appears, in order to choose the best palette for dithering or drop the least-used colors. Since images are often created once and viewed many times, it makes sense to calculate this information in the encoder, although it is not mandatory for the encoder to provide it. The same rationale holds good for palettes which are suggested quantizations of truecolor images. In this situation, it is recommended that the histogram values represent "nearest neighbor" counts, that is, the approximate usage of each palette entry if no dithering is applied. (These counts will often be available for free as a consequence of developing the suggested palette.) [...] ----------------------------------------------------------------------- [search key: #2] ----------------------------------------------------------------------- AGREEMENT FOR USE OF GRAPHICS INTERCHANGE FORMAT(SM) [The text of the Graphics Interchange Format (GIF) Developer Agreement, released by CompuServe on December 29, 1994 is not included here. It became obsolete when Unisys announced its new licensing policies regarding "The Welch Patent" on January 27, 1995. The text remains available from the author.] ----------------------------------------------------------------------- ----------------------------------------------------------------------- %: 174559 S19/GIF/LZW Discussion [GRAPHSUP] 04-Jan-95 17:07:50 Sb: #GIF/LZW Clarification Fm: Larry Wood 76703,704 To: All Gang, I have been asked by CompuServe to post the following comments: From: Tim Oren, CompuServe In 1987, CompuServe designed the Graphics Interchange Format (GIF) specification for graphics files. The GIF specification incorporated the Lempel Ziv Welch (LZW) compression technology. In early 1993, Unisys Corporation notified CompuServe of patent rights granted to LZW. At that time, CompuServe began negotiating with Unisys to secure a licensing agreement. This agreement was reached in mid-1994, and CompuServe then initiated a process to secure a similar license that would benefit its GIF developer community. Following the agreement reached between CompuServe and Unisys, CompuServe announced the Graphics Interchange Format (GIF) Developer Agreement, shortly after its completion, on December 29, 1994. This agreement is aimed at GIF developers who are developing programs and shareware primarily for use in conjunction with CompuServe. The service offers a license to these developers to use LZW technology in programs written to the GIF specification. CompuServe remains committed to keeping open the GIF 89a specification both within CompuServe and in areas outside CompuServe. CompuServe continues to strongly support the use of the GIF specification in the entire online community including the Internet and World Wide Web. This agreement will be transparent to end-users and will not result in any charges for people using viewers or transmitting GIF images. The agreement offers software and shareware developers who use the LZW technology in their GIF programs protection under a software license that CompuServe is authorized to grant under the agreement with Unisys. Developers who choose to take advantage of this service would acquire the rights to use the LZW technology in certain software and shareware developed primarily for use in conjunction with CompuServe. Developers who choose to participate in this agreement within the implementation period will also benefit in that Unisys has agreed not to pursue royalty claims for past use of the LZW technology in GIF. The implementation period has been extended to January 31, 1995. CompuServe has presented this new agreement as a service to its GIF developer community. Cost to developers will be a $1.00 one-time licensing fee and a royalty payment of 1.5 percent or $0.15, whichever is greater, per registered copy of a program containing the LZW technology. CompuServe will not profit from this service. CompuServe encourages developers to work with Unisys directly if the GIF Developer Agreement does not meet their needs. Unisys is continuing to make the LZW technology available to any interested parties under reasonable and non-discriminatory terms. Developers are not required to register with CompuServe. Registering with CompuServe is simply one option for addressing the Unisys LZW patent issue. Developers may want to consider consulting with legal counsel. CompuServe is committed to keeping the GIF 89A specification as an open, fully-supported, non-proprietary specification for the entire online community including the World Wide Web. Whether they choose to register with CompuServe or not, developers are encouraged to continue use the GIF specification within their products. A copy of the GIF Developer Agreement is available in the Library section of the CompuServe Graphics Support Forum (GO GRAPHSUP) and will shortly be posted to CompuServe's World Wide Web page (HTTP://WWW.COMPUSERVE.COM). Developers who are not developing software primarily for use in conjunction with CompuServe should contact Unisys directly at: Welch Patent Desk, Unisys Corp., P.O. Box 500, Bluebell, PA 19424 Mailcode C SW 19. Sincerely, Original Signed By Tim Oren Tim Oren, CompuServe Vice President, Future Technology ----------------------------------------------------------------------- ----------------------------------------------------------------------- #: 181065 S3/Hot News and Rumor 07-Jan-95 19:12:19 Sb: #Unisys GIF Clarification Fm: Steve Ahlstrom/SYSOP 76703,2006 To: All Unisys Clarifies Policy Regarding Patent Use in On-Line Service Offerings The concerns, inquiries and some apparent confusion that have resulted from the December CompuServe advisory clearly indicate that we need to clarify our policy concerning the use of the Unisys Lev Zempel Welch [note of the author: should be "Lempel Ziv Welch"] (LZW) patent by software developers for the major on-line services. We want to reiterate earlier communications that the issue of patent licenses is not focused on the end users of on-line networks, including the Internet. We encourage end users to continue to take full advantage of the outstanding benefits of a rapidly growing on-line community. Unisys was awarded the patent in 1985. We became aware of the increasing interest in our LZW patent beginning in 1990 when many companies approached us to license the patent for their hardware and software products. The growth in the use of compression technology was mushrooming in order to meet the demands for transmitting increased amounts of data. To date, more than 100 companies, including hardware, software and on-line information services, have licensed the Unisys LZW technology. Two years ago, Unisys learned that the LZW method was incorporated in the GIF specification and immediately began negotiations with CompuServe in January of 1993. We reached agreement with CompuServe on licensing the technology in June 1994, which calls for CompuServe to pay Unisys a royalty of 1% of the average selling price it charges for its software. This represents approximately 11 cents for each copy sold and connected to its information service. Under the agreement, CompuServe, at its discretion, could relicense the LZW technology to commercial developers using the GIF specification in software that connected directly to the CompuServe information service. With the agreement completed on June 21, 1994, CompuServe was given six months to implement the terms of its license. CompuServe later asked for a one-month extension, which we granted. Unisys did not require CompuServe to pass on any fee to its sublicensees or end users. Such a decision, and the content and timing of CompuServe's advisory, was at their discretion. Consistent with the entire information industry's desire to protect intellectual property, Unisys will expect all of the major commercial on-line information services companies employing the LZW patent to license the technology from Unisys at a reasonable rate. The on-line service companies are not required to sublicense the technology to developers producing software for the commercial on-line services. It will be, as it is today, at the on-line service's discretion as to whether it charges a license fee to developers or chooses an alternative method to account for its licensing fees payable to Unisys. We recognize and are concerned -- thanks in large part to the recent and very active use of the on-line network -- that developers did not understand that the patented technology was resident in GIF. Taking that into account, Unisys does not intend to pursue previous inadvertent infringement by versions of GIF-based software products marketed prior to 1995. Concerning all future software product development and enhancement of existing products for accessing on-line services, Unisys expects developers of commercial, for-profit software to secure a license from Unisys, or through the licensed on-line service, for the use of the patented technology. The very reasonable terms should prove no financial barrier to the introduction of product into the on-line network. Unisys does not require licensing, or fees to be paid, for non-commercial, non-profit GIF-based applications, including those for use on the on-line services. Concerning developers of software for the Internet network, the same principle applies. Unisys will not pursue previous inadvertent infringement by developers producing versions of software products for the Internet prior to 1995. The company does not require licensing, or fees to be paid for non-commercial, non-profit offerings on the Internet, including 'Freeware'. Commercial developers of GIF-based software for the Internet are expected to secure a licensing agreement with Unisys for software products introduced beginning in 1995, or enhancements of products that were introduced prior to 1995. Again, terms should not preclude the entry by these firms into the marketplace. For organizations introducing World Wide Web servers and 'Home Page' offerings, most will not be required to secure a license from Unisys. Most organizations acquire software from other developers to create their offerings on their servers. Therefore, only the software firms who sell the enabling software for profit would be expected to secure a licensing agreement from Unisys. Unisys understands that this issue has caused concern. We want to reassure all users and developers that we are strong proponents of the on-line industry. We're proud that this important Unisys technology has played a role in the introduction of innovative products and services, many of which are fueling the explosive growth of the information superhighway. As members of the information community we want to strike the appropriate balance between information access and the rights of all information companies, including the developers of software, to protect their intellectual property rights. Patent information: Contact Welch Patent Licensing Department; Unisys; Mail Stop C1SW19; P.O. Box 500, Blue Bell, PA 19424. Or via Internet, send E-mail to LZW_INFO@UNISYS.COM, or use a form available on the Home Page of the Unisys Web Server (http:\\www.unisys.com) to request follow-up information. Media contacts: Unisys Public Relations -- Bob O'Leary (215) 986-6413 or Oliver Picher (215) 986-5367 ----------------------------------------------------------------------- ----------------------------------------------------------------------- From: rmarks@ecdcsvr.tredydev.unisys.com (Richard Marks) Date: Fri, 6 Jan 1995 22:09:14 GMT Unisys LZW Patent FREQUENTLY ASKED QUESTIONS January 6, 1995 Since we released our statement this morning clarifying the terms of our LZW patent licensing agreement, we have received several questions from both the press and the on-line community at large. We thought we would share with you some of the most frequently asked questions -- and our answers. We hope this may help answer some similar questions you have. What is the LZW patent? The LZW patent covers methods and apparatus for lossless compression and decompression of digital data. Unisys holds a U.S. patent (number 4,558,302) as well as equivalent patents on the technology in Canada, France, Germany, U.K. and Italy. Equivalent patents are also pending in Japan. How did Unisys get the patent? Data compression and decompression is a critical aspect of data transmission and storage and is very much of interest to Unisys and the industry. The patent is the result of research done by Terry Welch at Sperry Corporation in the early 1980s that extended previous work by researchers Lempel and Ziv. Sperry Corporation was granted the U.S. patent in 1985. Sperry and Burroughs merged in 1986 to form Unisys, thus Unisys became the owner of the Sperry patents. Why is LZW so widely used? It is a very efficient compression method and a highly advantageous way of compressing and decompressing data for a wide variety of purposes. It is easy to implement, operates at high speed and results in high compression ratios without loss of data (that is, it significantly shrinks the file size). GIF has been in use since 1987. Why is Unisys enforcing its rights now? Unisys only became aware of the use of LZW in the GIF specification two years ago. We immediately began negotiations with CompuServe at that time and reached an agreement in June, 1994. The existence of the patent has never been a secret. In fact, we have completed licensing agreements for LZW technology with over 100 companies since 1990, for products including hardware, software and on-line information services. With most of these companies, it was the licensees who approached Unisys, not Unisys forcing the taking of a license. Why did it take you so long -- almost five years -- to figure out that GIF was infringing on your patent? As is common in industry, we don't have massive people resources devoted to searching and finding products which may be infringing and then undertaking the complex task of reverse engineering the products to determine whether or not they have infringed on the patent. In the case of GIF, as soon as we became aware we immediately sought to protect the patent through a license to CompuServe. Is this part of a larger campaign to enhance your revenues? No. The actual revenue derived from this particular patent is not significant. However, Unisys has invested hundreds of millions of dollars in overall technology development and has protected its investments in the form of thousands of patents. We have a responsibility to our shareholders to ensure that we protect these valuable company assets. Why have you targeted the on-line industry now? Unisys has not specifically targeted the on-line industry, evidenced by the fact that we have licensed this technology to hardware, software and information services companies over the past several years. We became aware of the applicability of our patent to the GIF specification and we simply undertook negotiations with CompuServe as the primary stakeholder in this specification. The announcement content and timing of CompuServe's action was solely a CompuServe business decision. The agreement with CompuServe says I can only use GIF in accessing CompuServe? What about other on-line services? Our relicensing agreement with CompuServe allows CompuServe to relicense the technology only for use in accessing the CompuServe information network. However, commercial, for-profit developers are free to contact us to secure a license for LZW. Non-commercial, non-profit users aren't required to secure a license to use the technology. Is Unisys willing to negotiate with other developers? Absolutely. Unisys wants to encourage the use of its patented technology and is therefore continuing to make licenses available under the patent at reasonable and non-discriminatory terms and conditions to any interested party. Keep in mind that Unisys can only license the patented LZW technology. Unisys has no other stake in GIF (other than using it for our own graphics transmission). What do you consider "reasonable terms"? While we will conduct negotiations with each applying developer, the CompuServe royalty rate is somewhat indicative of the terms that should cause no financial barrier to product entry into the on-line marketplace, or anywhere else. The CompuServe agreement calls for the company to pay Unisys a royalty of approximately 1% of the selling cost of the product for each product sold and connected to the on-line service. Given the calculation of the average price of CompuServe products, this came out to about 11 cents per product sold and connected. GIF is used extensively on the World Wide Web. What does Unisys intend to do there? Unisys in no way wants to discourage end users and developers from making use of this technology. We intend to license commercial software developers. However, non-commercial, non-profit products, including freeware, need not pay license fees. Organizations introducing a World Wide Web server and home page to the Internet are not expected to license the technology if they used a third-party software application to develop their server offering. Only the commercial third-party developer in that case should secure a license. What about Internet browsers? Again, our focus is on the developers and not on the end user. Also, our action is primarily focused on for-profit developers. If a developer intends to make a profit or provide a product for commercial use, they should negotiate a license from Unisys. Will this hurt the use of GIF? We certainly hope not. GIF has been outstanding for handling graphics files and its use of LZW technology is one of the factors in its success. Again, the licensing terms are very modest and should not be a barrier to its use. Will users of CompuServe have to pay a royalty to Unisys every time they upload or download a GIF file? No. Revenue to Unisys under the CompuServe license is independent of the number of files transferred. What will be the impact on end users and commercial software developers? There should be no impact on individual end users. We encourage them to take full advantage of GIF. For developers, the impact should be minimal. Again, Unisys continues to make licenses under the patent available to any interested party at reasonable and non-discriminatory terms and conditions. License fees for this technology should not be a barrier to any software developer. Why did you announce the changes during the Christmas holiday? We concluded the license with CompuServe on June 21, 1994. CompuServe was given six months to implement the terms of the license agreement. CompuServe asked for, and we granted, a one-month extension. The timing and content of the announcement, and for that matter, the need for the announcement, were entirely of CompuServe's choosing and without Unisys knowledge or approval. I'm using freeware or shareware that can manipulate GIF files. Can I still use it? Yes. What about freeware developers? Our focus is on commercial, for-profit developers. Freeware is exempted from licensing fees. And shareware developers? Shareware developers that intend to make a profit from their software should negotiate a license with Unisys. Alternatively, if their software is intended to access CompuServe only, they might want to take advantage of CompuServe's relicensing agreement with us. Was the Unisys patent ever challenged? The Unisys LZW patent was challenged in 1993, re-examined by the United States Patent and Trademark Office, and the patentability of all claims was reconfirmed in January of 1994. This is a valid and fully enforceable patent. Via Internet, send E-mail to LZW_INFO@UNISYS.COM, or use a form available on the Home Page of the Unisys Web Server (http:\\www.unisys.com) to request follow-up information. Media contacts: Unisys Public Relations -- Bob O'Leary (215) 986-6413 or Oliver Picher (215) 986-5367 ----------------------------------------------------------------------- [search key: #3] ----------------------------------------------------------------------- From Cloanto/Unisys - November 6, 1992 [salutation] Thank you for your kind reply. I don't want this matter to take you more time than necessary. I'll try to concentrate on a few very practical points, confident that Unisys understands the position of thousands of developers like us, and will maybe increase both its popularity and its profits by applying more diversified policies. Let's suppose we added the Welch algorithm for data compression in our low end paint program and word processor, sold at $ 99 and $ 49 list, with a 75% distributor discount. Data compression is clearly not one of the major reasons why one would buy such a product. Also, there are more efficient and specific algorithms than Lempel-Ziv-Welch. A 1 $ royalty (as in your standard proposal) would increase our costs by more than 25%. The book-keeping overhead alone would be a good reason for us to employ different compression algorithms. So, why would we use LZW? Ever since the original 1984 article on data compression by Terry Welch, this algorithm's diffusion was boosted by an incredible number of publications, "public domain" source code and de-facto standards. Just look at the TIFF and GIF image file formats and the many LZW based file archivers no BBS or PC-user could do without. Nobody (and here I must include Unisys) has ever done anything practical in order to let reasonably informed programmers know that Unisys Corporation could some day ask 1 $ for each product sold. Given the success of the algorithm, not taking a strong position was equivalent to encouraging people to use it. On the other hand, it is not quite clear to what degree and in which countries the Unisys patent should be relevant to pure software applications. (I was asking you something similar in my first letter.) At the same time, while public discussions rise awareness of these issues, many opinion leaders are warning about possible degenerations of a system which accepts "software patents". I understand that in this complex and potentially unstable situation Unisys may prefer prudent and diplomatic moves. Adobe Systems' developer support material says that "Unisys has agreed that ISVs may obtain such a license for a modest one-time fee." A una tantum solution seems to be very appropriate to me (in the 50 to 250 $ range?) I know and work with several companies with similar standards. No doubt that, excluding hardware applications and compression-oriented software (which is what I expect you to be more interested in protecting), such a policy would allow to Unisys to address the smaller developers and software vendors with more success and less bureaucracy. In the case of your proposed license agreement, I would have no problem paying the required advance (i.e. one time fee) and signing for a 0 $ royalty (and at the same time becoming a strong Unisys supporter). Reconsidering Adobe's note quoted above, maybe I just received the wrong contract proposal. [regards] ----------------------------------------------------------------------- ----------------------------------------------------------------------- From Cloanto/Unisys - November 12, 1992 [salutation] I appreciated receiving your second letter. As far as my case is concerned, I would only like to repeat one simple question. Beyond this, I am very interested in the various aspects of the matter, and would like to provide you with some stimuli from my point of view (corporate developer support programs, developers, developer conferences, specialized press, etc.) My question: If we implemented a software GIF or TIFF image file loader and saver (both formats are based on the LZW algorithm), would we need a license from Unisys Corp., as far as U.S. Patent 4 558 302 is concerned? If I were on your side, and had to start from scratch, I would consider different groups of LZW implementors. In the first group, I would put everybody who developed an interface to handle the very popular PC standards for file formats (e.g. GIF, TIFF, ZIP, ARC, ZOO, LHA, LZH, IFF-C1C0/C1K0, Compress, etc. - mainly bitmap graphics files and file archiving formats) which derived from the 1984 article by Terry Welch. In the second group, I would target all those interested in hardware implementations of the algorithm, and software which depends heavily on the use of the algorithm. I don't know enough about your business or the Patent to define more groups. Maybe all the above names of file formats do not mean much to you. If you have a friend who enjoys PC graphics, he or she certainly uses (knowing it or not) those formats, and has several files ending with ".GIF" or ".TIF" on the hard disk. If you also know somebody who has a modem connected to the PC, all the archives he has ever transferred probably had one of the other suffixes mentioned. A bitmap file format specifies how images you use on your PCs should be stored on disk for future reuse, or exchange with other software. An archiving program merges several different files, belonging to the same collection (e.g. a piece of software and its support files), into a single file, which is easier to store and transfer. Right now, LZW is certainly not the most space efficient way for compressing an image or another type of file for archiving purposes, but all this started back in 1984, and has now become a standard. There was a big boom in 1985. Back then, only Huffman and run-length compression were widely used. Ancestors of LZW, like LZ77, LZSS, LZH and LZ78, were blurry defined and had not encountered much success. The programs I mentioned in the first group do not even depend on LZW because of its run-time speed (one of the key aspects of LZW), but because it was supported and documented everywhere. It's a bit like the history of VHS videotapes (Beta was the better format, but VHS somehow became the leader). There are hundreds of publications explaining LZW without a single reference to Unisys. I see new articles every few weeks on very popular magazines. There are CD-ROMs sold for less than 50 $, each containing hundreds of references to LZW. The applications of the first group are not "broader than simply driving PostScript printers". I write PostScript drivers and can assure you that only very few companies and people will ever have to handle LZW for this purpose. PostScript is a very specific case, and it is not simple. File formats, instead, are everywhere. The reason why I put hardware and software in the same second group is that the distinction between the two is becoming more and more faint. For example, on many PCs equipped with a Digital Signal Processor, a modem featuring the V.42bis standard you mentioned can be emulated in software. I know of several modem manufacturers who distribute new releases of their microcode on private or public electronic bulletin boards, so that users can either reprogram their modems automatically, or burn a new EPROM and install it into the modem. If it were difficult to decide whether LZW is strategic to a piece of software which cannot immediately be classified as belonging to the first group, the usual royalty agreement could be applied. However, I wouldn't expect this formula to encounter much popular success. Once a solution had been found for settling the de facto situation, defining which file formats fall into the first group, and a clear policy for approaching those implementing the formats, one would have to start advertising, contacting all magazines, publishers, BBSs, etc. Somebody would have to be hired to keep track of all the new material which is published every day, attend conferences, etc. The royalty solution will not work with the first group. It will even be hard to convince them to accept that there is a patent involved (is it relevant, after all?) People would find solutions for not paying royalties (like writing a paint program and then releasing public domain external modules to handle GIF and TIFF). Of all the solutions I have seen companies adopting, I feel that only a one time, 50 $ to 250 $ fee, would be accepted. It could be bundled with a package of technical documentation on LZW, and a dissertation on the patent, so that people could better appreciate what they receive in change. It would have to become a popular solution, something the small developer would be proud paying for because "He has licensed a patent from Unisys Corporation". You could even authorize everybody to use LZW for free for applications in the first group (possibly starting with us), but you cannot afford to have the public against you. [regards] -----------------------------------------------------------------------