
The GIF Controversy: A Software Developer's Perspective

Reference Section

    January 27, 1995 - Text revision 2 - March 31, 1995
    by Michael Console Battilana <mcb@cloanto.it>
    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 <gltext2@cloanto.it> 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 <gltext2@cloanto.it> 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]
-----------------------------------------------------------------------

<end>
