------------------------------

ubject: 0. How can I email a graphics file?

Normally you would move a file around the Internet using a data transport
program that handles binary data, such as UUCP and FTP. If you only have
an ASCII-only data transport mechanism available to you, such as
electronic mail, you will need to convert your binary graphics files to an
ASCII format before sending them. This process is only necessary for
binary files.  ASCII-based file formats, such as DXF and PostScript, do
not require uuencoding before emailing.

On the Unix operating system you will use a program called uuencode to
convert the 8-bit data of a graphics file to a 7-bit ASCII data file. The
data file is then emailed and uudecoded on the receiving end.

To uuencode and email a file:

  % uuencode picture.img picture.img | Mail user@host.site

This command will pipe the output of the uuencode command to the input of
an email program. Realize that if your email program is set up to keep a
copy of all of the email you send, and you email a lot of uuencoded
graphics files, your outgoing email folder will grow quite large. You can
modify your .mailrc (or equivalent) file to route the copy of the outgoing
graphics file to /dev/null, or you can write-protect your outgoing mail
folder so the data can't be written:

  % chmod -w ~/Mail/mbox.out
  % uuencode picture.img picture.img | Mail user@host.site
  /home/Mail/mbox.out: Permission denied
  % chmod +w ~/Mail/mbox.out

Once the emailed data is received, you will need to strip off the mailing
header before you can uudecode it. The uuencoded data starts with the word
"begin" and is followed by the file mode, file name, and a series of
61-character lines. The file is ASCII, so you can use an editor such as vi
to do the stripping. Assuming the received data is saved to a file named
"file", the uudecoing process is thus:

  % uudecode file

The original graphics file is now in the current directory. You may delete
the uuencoded file if you wish to do so.

The uuencode and uudecode programs have been ported to other systems, such
as MS-DOS, MS Windows, OS/2, Amiga, and the Macintosh (the BinHex program
for the Mac does not produce the same ASCII data as uuencode), and may be
used in the same way.

For more information on accessing the Internet via email, please refer to
the FAQ "Accessing The Internet By E-Mail: Doctor Bob's Guide to Offline
Internet Access", found on the news.answers and alt.internet.services Usenet
newsgroups and your favorite FAQ archives.

------------------------------

ubject: 1. Where can I find graphics files on Usenet?

The vast majority of graphics files posted to Usenet will be found in the
alt.binaries.pictures.* newgroups. If you do not have access to Usenet,
then you will not be able to retrieve files posted to these groups.

For much more information on the alt.binaries.pictures.* newsgroups, please
consult the alt.binaries.pictures FAQ (pictures-faq/part[1-3]) posted to
news.answers and alt.binaries.pictures.d.

------------------------------

ubject: 2. How do I decode a graphics file posted to Usenet?

Graphics files are posted to Usenet as uuencoded binaries. Although you
may see files posted using BinHex or someother ASCII format, the uuencode
data format is the defacto standard of Usenet.

A graphics file may be contained in a single-part posting, which you will
save to a file, strip off the mailing header using a text editor, and use
the uudecode program to convert the data into the original graphics file.
Many online news readers will perform this operation for you.

Graphics files are usually quite large and uuencoding will increase the
file size by another 33%. For this reason, graphics files (and most binary
files) are split into 1000 line or 60KB chunks (multi-part postings) for
easier handling. If each chunk includes a shell wrapper (the string "[sh]"
usually appears in the Subject:  line of such postings), online news
readers, such as tin, can tag each part of the posting and decode it into
the original file for you. 

The most labor-intensive way to decode a multi-part uuencoded posting is to
save each part into a separate file, edit each file to remove the mailing
headers, concatenate them all into a single file, uudecode the file, and
delete the original parts:

  % vi picture.1 picture.2 picture.3
  % cat picture.1 picture.2 picture.3 | uudecode
  % rm picture.1 picture.2 picture.3

There are, of course, several utilities to decode single- and multi-part
binary posting for you without all this bother. Please refer to the
alt.binaries.pictures FAQ (pictures-faq/part[1-3]) posted to news.answers
and alt.binaries.pictures.d for more information on decoding graphics files
posted to Usenet.

------------------------------

ubject: 3. How can I post a graphics file to Usenet?

Posting a graphics file to a Usenet newsgroup is very similar to emailing
a graphics file, but there are some important extra steps you must take in
order to do so.

First, a graphics file must be uuencoded. That is, converted from 8-bit
binary data to 7-bit ASCII data. Second, the resulting uuencoded file must
be split into 60K chunks (1000 lines) for posting. And lastly, each chunk
posted must be given a description and a part number.

Under Unix we would use the uuencode, split, expr, and inews commands to
post a graphics (or any binary) file as such:

  % uuencode picture.img picture.img > picture.img.uue
  % split -1000 picture.img.uue picture.img.uue.
  % ls
  Total 535
  picture.img        picture.img.uue    picture.img.uue.1  
  picture.img.uue.2  picture.img.uue.3
  % sh
  $ i=1
  $ for j in picture.img.uue.*; do
  > (echo "Subject: picture.img [$i/3]"
  > echo "Newsgroups: news.test
  > echo
  > cat $j) | /usr/lib/news/inews
  > i=`expr "$i" + 1`
  > done
  $ rm picture.img.*
  $ exit
  %

In this example, we take a graphics file named picture.img, uuencode it,
and place the output in a file names picture.img.uue. This file is then
split into three chunks named picture.img.uue.1, picture.img.uue.2, and 
picture.img.uue.3.  We then loop through each file and create a Subject:
and Newsgroup: line for each of the file chunks and post them using inews.

There are, of course, programs which automate this process. One such
program is xmitBin, written by Jim Howard and availble via FTP from:

  ftp://ftp.cadence.com/utils
  http://mrcnext.cso.uiuc.edu/~deej/index.html

Refer to the alt.binaries.pictures FAQ (pictures-faq/part[1-3]) posted to
news.answers and alt.binaries.pictures.d for more information on posting
graphics files to Usenet.

------------------------------

ubject: 4. How do I submit a file format specification to an archive?

There are several FTP and WWW sites which act as archives for graphics
file format specifications (see the section "Graphics and Image File FTP
Archives and WWW Pages"). If you have a file format specification that is
legal to share with the rest of the world-wide Internet community, then
you may wish to submit it to one or more of these archives.

There are generally two ways to submit a file format specification to an
FTP archive:

  1) Upload (or "put") the file in the /incoming or /pub/incoming directory.
  2) Email the file to the archive maintainer (the email address is usually
     in the README or similar file in the root FTP directory).

Realize that most FTP sites don't allow unsolicited uploads and instead
require you to contact the archive maintainer to make a submission. Many
sites are simply mirrors for other archives and don't accepts any kind of
submissions at all. 

In any case, it's usually good form to include a description file with
your submission to describe in a few words what you have uploaded and
where it originated. If your upload is named foo.doc then the description
file should be named foo.txt. If your upload is named foo.txt, improvise.

------------------------------

ubject: 5. How can I make transparent and interlaced GIFs for a Web page?

Transparent GIFs are used to eliminate the typical rectangular borders
associated with most bitmapped images that appear on a Web page. The
creator of a GIF image may set certain pixels within the bitmap to a color
desiganted within the image file as "transparent". When this GIF image is
displayed by a Web browser the transparent pixels take on the color of the
user's display.  This is identical to the blue screen effect found in
chromakeying.

GIF89a files are made transparent by the use of graphics file editing
software (GIF87a files do not support transparency and must first be
converted to the GIF89a format). Such software will set the transparency
color flag and the transparent color index value of a Graphics Control
Extension block within the GIF89a file. Any pixel set to the specified
transparent color index value will take on the background color of the
display device when displayed.

Interlaced GIFs are used to give the user a idea of that an image looks
like before all of the bitmapped data has been received. Non-interlaced
images paint in a linear fashion from the top to the bottom of the
display. Over a slow link it make take several minutes for an image to
paint. When 50% of the bitmapped data is received only the top half of the
image is displayed.  The contents bottom half is still a mystery to the
user.

Interlaced GIFs paint quickly over the entire display first as a very low
resolution image. Only about 12.5% of the bitmap is displayed in this
first pass. The GIF image is then repainted in three more passes, with
each pass supplying more resolution until all of the data is received
(12.5%, 25%, and 50% respectively). A user can usually get a good idea of
what the entire image is when only 30-50% of the bitmapped data has been
received. This is very useful for knowing when to abort an image being
viewd via a slow link.

Interlacing is supported by both the GIF87a and GIF89a formats. Graphics
file editing software that supports interlaced GIF should not only be able
to display such GIF files, but also convert non-interlaced GIFs to the
interlaced format (and back again as well). This involves reading in the
GIF bitmap and writing it back out using the GIF 4-pass interlace scheme.
In a non-interlaced GIF the pixel lines are displayed in consecutive
order. For example, the lines of a 16-line non-interlaced GIF file are
stored as 0, 1, 2, 3, 4, 5...15. The lines of the same 16-line bitmap in
an interlaced GIF would be stored as 0, 8, 4, 12, 2, 6, 10, 14, 1, 3, 5,
7, 9, 11, 13, 15.

Graphics file format software packages for Unix which handles both
trasparent and interlaced GIFs include NETPBM and giftool.  For the
Macintosh:  Transparency, Graphic Converter, Imagery, and clip2gif

The Visioneering image manipulation page will allow you to convert your
GIFs to transparent and interlaced without having special software on your
system. Your GIF files will be read, converted, and written using the Web.
Visioneering's page is at:

  http://www.vrl.com/Imaging/

More detailed information on images used in Web pages can be found in the
FAQ for the newsgroup comp.infosystems.www.authoring.images found at:

  http://www.island.net/help/faq/www_faq/
  http://www.io.org/faq/www/index.html

A collection of links to a number of Web and FTP resources that store
information on transparent and interlaced GIFs for Unix, Macintosh, and
MS-DOS/Windows, including executable programs and tutorials, may be found
at:

  http://members.aol.com/htmlguru/transparent_images.html
  http://dragon.jpl.nasa.gov/~adam/transparent.html
  ftp://csi.jpl.nasa.gov/pub/graphics/

------------------------------

ubject: 6. How do I combine still images to make animations?

You might have a collection of imaes and drawings stored in a variety of
still-image formats (TIFF, BMP, IFF, and so forth) and want to combine them
into an animation or video file format that wil allow you to play them back.

Have a look at the following Web page:

  http://www.prism.uvsq.fr/public/wos/multimedia/

------------------------------


Subject: IV. Copyrights, Patents, and other Legalities of Graphics File
Formats

------------------------------

ubject: 0. Can a graphics file be copyrighted?

No. A graphics file cannot normally be copyrighted under United States
copyright laws (although the rulings of some judges may disagree on this).
The specification of a format and the contents of a graphics file,
however, are subject to copyright.

For anything to be copyrighted it must be:

  1) A work of authorship
  2) Fixed in a tangible medium of expression

The description of a graphics format does meet both of these criteria (it
is fixed in a medium and a work of authorship) and is therefore protected
under the copyright laws. A graphics file created using the format
description, however, meets the second criteria, but not the first (that
is, it is not considered to be a work of authorship). The format itself is
considered instead to be an idea or system, and is therefore not protected
by copyright.

So the description of a file format is copyrightable, but the format as it
exists in its medium is not. What about the graphics data that the file
contains?

If the graphical data written to a graphics file also meets the above two
criteria, then it is also protected by the copyright laws as intellectual
property. You will not wave your copyright protection by storing any
original information using a graphics file format.

For more information on copyright, please refer to the Copyright FAQ found
on the misc.legal, misc.legal.computing, misc.int-property, and
comp.patents newsgroups: 

  ftp://rtfm.mit.edu/pub/usenet/news.answers/law/Copyright-FAQ/
  ftp://rtfm.mit.edu/pub/usenet/news.answers/law/Copyright-FAQ/myths/

Apparently, quite a number of copyright discussions also occur on the
comp.infosystems.www.* newsgroups as well.

Information on patents, copyrights, and intellectual property may be found
at:

  http://www.questel.orbit.com/patents/readings.html
    Patent and trademark information

  http://www.uspto.gov
    U.S. Patent and Trademark Office

  http://www.spi.org
    Software Patent Institute

------------------------------

ubject: 1. Is it now illegal to use CompuServe's GIF format?

It is not illegal to own, transmit, or receive GIF files (provided that no
unlicensed compression and/or decompression of the files occurs). You must
realize, however, that GIF files are not the issue. The issue is, in fact,
the LZW data compression algorithm.

In 1984, while working for Sperry Corporation, Terry Welch modified the
Lempel-Ziv 78 (LZ78) compression algorithm for greater efficiency for
implementation in high-performance disk controllers. The result was the
LZW algorithm. The world was informed of the existence of LZW by the
following journal article, published by Mr. Welch after he left the
employment of Sperry:

  Welch, T. A., "A Technique for High Performance Data Compression,"
  IEEE Computer, Volume 17, Number 6, June 1984.

In 1985, Sperry Corporation was granted a patent (4,558,302) for the Welch
invention and implementation of the LZW data compression algorithm. Since
that time, this LZW patent has been publicly available for all to see in
the US Patent Office and many public libraries, and is available through
many on-line services.

In 1987, CompuServe Corporation created the GIF (Graphical Interchange
Format) file format to be used for the storage and on-line retrieval of
bitmapped graphical data. The GIF specification required the use the LZW
algorithm to compress the data stored in each GIF file. It is very
possible that CompuServe did not check the patent files to determine
whether the GIF format infringed on any patents. Such a check would have
found the Welch LZW patent, which was then owned by Unisys as a result of
their having purchased Sperry in 1986. At that time, Unisys also did not
know that LZW was the method of compression used by the very popular GIF
file format.

In 1988, Aldus Corporation released Revision 5 the TIFF file format. This
revision added a new feature giving TIFF the ability to store RGB
bitmapped data using either a raw format, or a compressed format using the
LZW algorithm. (Although the LZW algorithm used by TIFF is considered to
be "broken", it is still covered by the Unisys patent). Since 1991, in
accordance with their agreement with Unisys, Aldus has been required to
place a notice regarding the Unisys patent and its applicability to TIFF,
in Aldus documentation. The 1992 release of Revision 6 of the TIFF
specification includes this notice of the Unisys patent regarding LZW. The
TIFF Revision 6 specification also recommends against using LZW to
compress RGB bitmaps stored using the TIFF format.

In 1990, Unisys licensed Adobe for the use of the Unisys LZW patent for
PostScript.

In 1991, Unisys licensed Aldus for the use of the Unisys LZW patent in
TIFF.

In 1994, Unisys and CompuServe came to an understanding whereby the use of
the LZW algorithm would be licensed for the application of the GIF file
format in software. 

In 1995, America Online Services and Prodigy Services Company also entered
license agreements with Unisys for the utilization of LZW.  Published
information indicates that Unisys' licensing policies are as follows:

 1) Unisys considers all software created or modified before January 1,
    1995 that supports the GIF and/or TIFF-LZW formats to be
    inadvertently infringing upon its patent; Unisys will therefore not
    require a license for GIF software products delivered before January
    1, 1995. Unisys will therefore not pursue legal actions against such
    pre-1995 software products.

 2) However, Unisys expects developers of commercial or for-profit
    software to obtain a GIF-LZW license agreement from Unisys if, after
    December 31, 1994, the developer creates new software or updates or
    modifies existing software, or issues a new release of software that
    supports the GIF file format.

 3) Unisys does not require licensing of non-commercial, not-for-profit
    software applications that support the GIF file format.

 4) With respect to TIFF, if a license is entered before July 1, 1995, 
    there will be no liability for pre-1995 software with respect to
    that software's support of TIFF which uses LZW.

Unisys has drafted licenses for several different applications of the LZW
algorithm. The two license agreements of most interest in this FAQ are
applicable to software supporting the GIF file format alone and the
agreement applicable to software supporting both GIF and the TIFF file
format's LZW compression feature.


Realizing that you have many questions about GIF-LZW and TIFF-LZW
licensing, the remainder of this section is arranged in a Question/Answer
format to help convey information about this subject more clearly.

Q: Just what is this all about?
A: Unisys has asserted its claim to the ownership of the LZW compression 
   and decompression algorithm. If you wish to implement LZW in a software
   or firmware application, you must arrange to pay a small royalty to
   Unisys for every software package that you sell. You do this by applying
   to Unisys for an LZW license agreement for your software.

Q: What file formats are effected?
A: GIF, TIFF, PDF, and PostScript Level II. All of these formats use, or
   can use, LZW compression. For example, a TIFF or PostScript Level II
   file may or may not use the LZW algorithm to compress the data it
   contains. GIF files, and most PDF files, always store bitmap data that
   is compressed using LZW.

Q: How does this agreement affect my use of GIF and TIFF files?
A: It does not affect the ownership, transmission, or reception of GIF
   and TIFF-LZW files themselves. Only the software that performs 
   compression and/or decompression of GIF may be effected in any way
   by license agreements. You are free to store and transport GIF and
   TIFF-LZW files without fear of legalities or cost from the Unisys
   licenses provided that any compression and/or decompression on GIF
   files is performed by licensed software, or by software products
   delivered prior to 1995.

Q: Which agreement do I need?
A: If your software supports only GIF then you need the GIF-LZW agreement.
   If it supports TIFF-LZW or both GIF and TIFF-LZW then you need the 
   TIFF-LZW and GIF-LZW agreement.

Q: My software supports TIFF-LZW, but not GIF.
A: You still need to obtain the TIFF-LZW and GIF-LZW agreement.

Q: So if my software only supports non-LZW versions of TIFF and PostScript
   Level II I don't need to worry about obtaining a license agreement?
A: That is correct. Only software that is capable of using the LZW 
   algorithm requires an agreement. This includes all software that 
   supports the GIF file format.

Q: What about file compression programs such as compress, PKZIP, zoo, and
   lha? Don't they use LZW too?

A: Most file compression programs use the LZ77 algorithm for compressing
   text. The LZ77 compression algorithms (and several of its
   derivatives) predates LZW by several years and is covered by its own
   series of patents.  The predecessor to LZW, LZ78, is used primarily
   for compressing binary data and bitmaps. Any software that uses the
   LZ77 and/or LZ78 algorithms without the LZW improvement is not
   affected by the Unisys LZW patent.  Of the mentioned software
   packages, the Unix compress utility does use LZW and therefore
   requires a license.

Q: Doesn't IBM also hold a patent on LZW?
A: IBM was granted a patent (4,814,746) for use of LZW in disk drive 
   technology. This patent does not award ownership of LZW to IBM.

Q: Is there a chance that the Unisys patent is actually invalid?
A: In 1994, the U.S Patent Office reexamined the Welch patent and, on
   January 4th of that year, not only confirmed the patentability of the
   original 181 patent claims, but also confirmed that 51 claims added
   during the reexamination were also patentable.

Q: I have heard that the Welch patent only covers LZW compression and 
   not decompression. Is this true?
A: Many people who have read the patent claim that this is true. Unisys,
   of course, strongly maintains that the patent does cover LZW decompression,
   and will pursue legal action against unlicensed software which only
   performs LZW decompression. It is not clear (to the author of this text)
   if the 1994 patent reexamination specifically asserted the existence
   of the description of LZW decompression in the original Welch patent.

Q: But you can't patent a mathematical abstraction. Doesn't this also
   include algorithms implemented as computer software?
A: A patent grants the exclusive rights, title, or license to produce,
   use, or sell an invention or process. One or more algorithms may be
   applied using software to create an invention. It is this invention
   whose use is restricted by the patent and not the algorithm(s) involved.
   In the case of software, it seems that it is not very easy to separate
   the algorithm(s) from the invention itself. Use of the algorithm(s)
   would seem to imply use of the invention as well.

Q: I use LZW in my programs, but not for GIF or TIFF graphics. What should
   I do?
A: If you are not a business, and the programs are for your own personal
   non-commercial or not-for-profit use, Unisys does not require you to 
   obtain a license. If they are used as part of a business and/or you
   sell the programs for commercial or for-profit purposes, then you must
   contact the Welch Patent Licensing Department at Unisys and explain your 
   circumstances. They will have a license agreement for your application
   of their LZW algorithm.

Q: Where can I apply for a GIF-LZW, TIFF-LZW and GIF-LZW, PDF, PostScript 
   Level II, or any other LZW license?
A: You can write to:

     Welch Patent Licensing Department
     Unisys Corporation 
     Mail Stop C1SW19
     P.O. Box 500
     Blue Bell, PA 19424 USA

   Or fax:    215.986.3090

   Or email:  lzw_info@unisys.com

   General licensing information may also be obtained from the home page
   of the Unisys Web Server:

     http://www.unisys.com/
     http://www.unisys.com/ServerInformation/contact/contact.html
     http://www.unisys.com/LeadStory/lzwfaq.html

Q: How much does a license cost?
A: The terms and cost of the license policy has changed since its
   introduction in 1995. Contact Unisys for the latest LZW licensing terms.

Q: Do I need a separate license for each GIF-using software product I sell?
A: If you sell three products that all use the GIF format, for example,
   then you will need only one license. License fees must be paid for
   each product sold.

Q: Do I need to obtain a new license if I release a new version of my
   software?
A: No. However, a license fee is required for each update, improvement,
   or enhancement of your software that is sold.

Q: What if I give my software away?
A: If you distribute for free your product directly to end-users for their
   personal use and your distributing the software is non-commercial and
   not-for-profit use and you receive no financial gain (such as Shareware
   donations, royalties for CD-ROM distributions, or as advertising to 
   attract for-profit business), then you do not need a license.

Q: But what about Shareware donations?
A: Each Shareware "payment" you receive is considered the selling price of
   that unit. Whatever a user pays to you for your GIF-using software is
   required to be included in your quarterly license fee payment to Unisys.
   However, minimum license fees per unit must be always paid.

Q: My Shareware GIF software is being sold for-profit on a CD-ROM, but I do
   not make any profit from its sale. Can I get in trouble? Do I need a 
   license?
A: The person/business that is selling your program for profit on their
   CD-ROM is responsible for obtaining the proper license. You would only
   need a license if you received any payments from the CD-ROM vendor or
   from users of your Shareware.

Q: I do not live in the United States and my software is not available
   there. Do I still need to obtain a license agreement?
A: Yes, you do. The Unisys patent has many foreign counterparts and the
   legalities of using LZW apply to most other countries in addition
   the US.

Q: What will happen to me if I continue to revise my GIF-using software,
   sell it for profit, and yet not bother to obtain a license?
A: Most likely, when your unlicensed program is discovered by Unisys,
   you will be notified of your need to obtain a license for your product.
   If you then fail to obtain the proper license, Unisys may seek an 
   injunction against your product including damages. You could also be 
   charged with willful infringement, which could result in treble damages.

Q: On what Usenet newsgroups is this LZW agreement being discussed?
A: You will find threads appearing on comp.graphics.misc and other related
   graphical newsgroups. The official newsgroup where much discussion
   takes place is alt.gif-agreement. You might also find information on
   the misc.legal.computing, misc.int-property, and comp.patents newsgroups.

Q: Where can I get a copy of the Unisys patent?
A: Copies of patents may be found in public libraries or be obtained
   directly from the U.S. Patent Office. The patent is also available
   at many Internet sites, including:

     ftp://ftp.std.com/obi/USPatents/
     ftp://ftp.uu.net/doc/literary/obi/USPatents/lzw-patent.Z

Q: What are my alternatives to GIF and TIFF-LZW file formats?
A: A good alternative to LZW for compressing ASCII data is the LZ77
   algorithm used by the zip and PKZIP file archivers and the gzip
   (GNU zip) file compression program. The most popular alternative for
   multi-bit image data is the JPEG compression algorithm and the JFIF
   and SPIFF file formats. JFIF and SPIFF-JPEG files are smaller and
   store far more colors than GIF files.

   Another newer alternative is the PNG format, which is currently under
   development (see the section "PNG - Portable Network Graphics" in
   Part 3 of this FAQ). PNG is unencumbered by patent licenses and has
   much potential and promise in replacing GIF. But, most software that
   supports PNG will likely have been written after January 1, 1995, so
   make sure that your GIF-to-PNG conversion program has the proper
   Unisys license.

Q: Will Unisys' actions hurt the use of GIF?
A: Yes it will. People will continue to write software that supports GIF
   only if their customers demand it. The licensing will hasten the
   eventual demise of GIF, as both people and companies will be more
   motivated to standardize on "free" formats, such as JFIF, SPIFF, PNG, 
   BMP, and TGA.

Q: This agreement is bogus! I refuse to ever use GIF again!
A: As an end-user you are free never to read, write, or archive another
   LZW-encoded file as long as you live. As a developer you are only
   free of the legal implications of the Unisys patent if you remove any
   LZW code from your programs, including those shipped to your customers
   after 1994.

Q: Wait! I have more questions!
A: Contact the Welch Patent Licensing Department at the aforementioned
   addresses. I (the author of this FAQ) am not an employee nor legal
   representative of Unisys. You can also find this information on the
   Unisys web page:

   http://www.unisys.com/LeadStory/lzwfaq.html

   And in the following InfoWorld article:

   "Graphics file format patent Unisys seeks royalties from GIF developers",
   Karen Rodriguez, InfoWorld, Jan 09, 1995 (Vol.17, Issue 02, p3)

   And the following Web pages are devoted to this issue:

   http://www.lpf.org/Patents/Gif/unisys.html
   http://www.lpf.org/Patents/Gif/Gif.html
   http://www-cmpo.mit.edu/met_links/resources/LZW_patent.html
   http://www.webhaven.com/izivkov/scanfax/GIF.HTM
   http://rom.oit.gatech.edu/~willday/gif.html

Disclaimer: The information in this FAQ regarding the Unisys LZW
licensing agreement has been presented in an attempt to allow the
reader to understand some of the legalities they may face by the use
of the LZW algorithm. The author has rendered this explanation and
example questions using the most accurate information available to
him at the date of this FAQ. In no regard should this text be
considered an official publication of Unisys Corporation or a legal
representation of the policies of Unisys, or in any way obligating
Unisys to enter into a license agreement based upon the terms,
interpretations, and/or answers to question provided in this text.