PROTEST OF NEW COMPUSERVE-UNISYS GIF USAGE TAX !!
Pat Clawson
An Open Letter to Our Colleagues In the Online Communications
Community:
The announcement by CompuServe and Unisys that users of the GIF image
format must register by January 10 and pay a royalty or face lawsuits for
their past usage, is the online communications community's equivalent of
the sneak attack at Pearl Harbor.
The announcement of the CompuServe-Unisys GIF Tax on December 29,
during the lull between Christmas and New Year's Day, was clearly timed
to cause maximum damage while an unsuspecting public celebrated the
holidays.
We at TeleGrafix Communications have no quarrel with those who seek to
protect their intellectual property and profit from it. Indeed, we are in
business to do the same. We believe those who develop software are
entitled to reap financial rewards from their labors.
But in our opinion, the timing and circumstances of the
CompuServe-Unisys action indicates this is a shakedown of the online
communications community by two powerful corporations, rather than a
reasonable effort to protect intellectual property.
The GIF format has been in widespread public use since 1987. Its
widespread use and royalty-free licensing has been encouraged by
CompuServe for years. Neither CompuServe or Unisys have made any
significant improvements to GIF or its underlying LZW algorithm and
compression process to justify charging for what has been free.
Giving GIF users only 14 days to comply with sudden, unexpected demands
to pay the private CompuServe-Unisys GIF Tax or face prosecution for past
usage of what had been promoted for seven years as free, open standard
software is unconscionable. It is especially outrageous since CompuServe
and Unisys admit in writing that they decided to require licensing SIX
MONTHS AGO in June, and didn't announce it to the public until now.
According to the CompuServe-Unisys GIF licensing agreement, the
settlement of the patent dispute was executed on June 21, 1994.
CompuServe agreed to implement the agreement "as soon as reasonably
practicable and in no case later than six (6) months after the date this
Agreement is executed..." That six month period ended on December 21,
1994 -- but CompuServe did not make the licensing terms public until
December 28. Indeed, CompuServe appears to have violated the terms of
its own settlement agreement with Unisys.
While many of the messages we have read online in reaction to the
CompuServe-Unisys GIF Tax decree express both dismay and disbelief,
virtually none have analyzed the actual provisions of the licensing
agreement. It is in this area that TeleGrafix Communications wishes to
contribute to the dialogue.
In our opinion, the CompuServe-Unisys licensing agreement is both
illogical and overly broad. Let's examine some of its key provisions. All
quotes cited are directly from the agreement.
1. CompuServe will license Developers who want to use GIF technology.
The term "developer" is defined as "the other undersigned party to the
agreement," and it seems to apply to ANYONE who contemplates
distributing any product that uses the GIF format.
2. Developers will be licensed to sell or distribute "Products" that "use
and exploit GIF...solely within the Field of Use." The term "Field of Use"
is defined as "primarily for accessing the CompuServe Information Service
and for manipulating and viewing data received through the CompuServe
Information Service." The licensing agreement further defines the term
"Products" as being "software that is developed or distributed...which is
designed for and used primarily for accessing the CompuServe Information
Service and for manipulating and viewing data received through the
CompuServe Information Service." IT APPEARS THAT THE ONLY LAWFUL
USE OF GIF WILL BE FOR COMPUSERVE-RELATED PRODUCTS. Using GIF
images in any other manner, such as on CD-ROMs or bulletin board
systems, is prohibited. Most of the thousands of products that have used
GIF in some manner are henceforth contraband.
3. Developers may no longer "use, copy, modify or distribute the GIF
specification, except as expressly permitted by CompuServe." This states
that the GIF specification can no longer be shared, published or uploaded in
any manner without the express consent of CompuServe.
4. Members of the public are prohibited from using any software product
containing GIF until they have become a REGISTERED user of the product.
The customer also must agree to use the product "primarily for accessing
the CompuServe Information Service and for manipulating and viewing
data received through the CompuServe Information Service." This
virtually eliminates the concept of freeware or shareware containing GIF
capabilities, since prospective customers can no longer try out these
software products without registering them first.
5. Software developers must pay $1.00 for a license to use GIF, PLUS a fee
equal to the GREATER of 1.5% of the selling price of the product, or $0.15
per "Disposition." Disposition is defined as "the sale, lease or license or
any other grant of rights to a Product or any new Product." All royalties
must be paid quarterly. Noncommercial and freeware usage of GIF
technology is NOT exempted from the royalty requirement. Because the
royalty provisions and definition of "Disposition" are so broad in scope, it
appears that a GIF Tax payment may be due to CompuServe-Unisys each
time a GIF image is transmitted via BBS or Internet. The operators of a
BBS or World Wide Web site with hundreds or thousands of GIF images
online could easily be bankrupted by these licensing requirements.
6. CompuServe must be notified of ANY new product using GIF when it is
first offered to customers.
7. Persons using GIF must keep records of its use, and CompuServe has the
right to audit those records every year upon seven days notice. Persons
using GIF must pay the cost of the audit if a royalty underpayment of 10%
or more is discovered, along with 12% interest on any underpaid royalties.
8. Even if the patent is later found by the courts or the U.S. Patent Office
to be invalid and unenforcable, or if the patent expires, any developer
must "return all copies of the GIF specification and any confidential
information of CompuServe then in its possession or control to
CompuServe, (ii) stop using the Licensed Technology, and (iii) stop
distributing Products." This states that EVEN IF THE PATENT IS
OVERTURNED OR EXPIRES, YOU MUST STOP USING OR DISTRIBUTING GIF.
9. Even though CompuServe has publicly disseminated the text of the
agreement it wants GIF users to sign, the terms of the agreement are to
remain confidential. This is illogical, to say the least, since they have
posted it for public download on their own system.
10. Developers have to indemnify and hold CompuServe harmless for any
damages if their CUSTOMERS somehow use GIF technology in a way not
permitted by the licensing agreement.
11. Unisys has the right to enforce the agreement, as well as CompuServe.
Further, Unisys has the right to pursue legal action or seek damages
against Developers even after the agreement has terminated.
TeleGrafix Communicatons Inc. will not sign such a licensing agreement.
We think most other software developers, BBS sysops and Web site
operators also will refuse to sign.
We encourage our colleagues in the online communications community to
evaluate the CompuServe-Unisys action, and to lodge appropriate protests
directly with those companies.
We believe that the CompuServe-Unisys GIF Tax drives a stake through the
heart of Internet development. It will cripple the World Wide Web, NCSA
Mosaic, and other Internet multimedia technologies that rely heavily on
GIF imaging.
Fortunately, we at TeleGrafix Communications do not depend on GIF
imaging in our new RIPscrip 2.0 online multimedia technologies. We chose
to implement the JPEG image format and only recently decided to add GIF
support as a convienience to our customers. Due to the restrictive
conditions of the CompuServe-Unisys GIF Tax and licensing agreement, we
must now reevaluate our plans for supporting GIF use in the upcoming
release of RIPscrip 2.0.
While our company hopes to profit financially from our advanced RIPscrip
2.0 technology, we will not demand royalties from those who have used
the freeware versions of our earlier RIPscrip 1.54 products and/or
technical specifications. The RIPscrip 2.0 specification also will be made
public for third-party use after it is finalized.
We expect that the CompuServe-Unisys action will spell the death of GIF
as a commercially viable technology, shifting the attention of the online
communications community to JPEG imaging.
Sincerely,
Pat Clawson
President & Chief Executive Officer
TeleGrafix Communications Inc.
Huntington Beach, CA
Voice: (714) 379-2140
Fax: (714) 379-2132
BBS: (714) 379-2133
Internet: rip.s...@telegrafix.com
Phillip Burgess
[A big protest letter, finishing off with...]
>We expect that the CompuServe-Unisys action will spell the death of GIF
>as a commercially viable technology, shifting the attention of the online
>communications community to JPEG imaging.
Why protest it? It should have been killed off YEARS ago!
--
Phillip Burgess (pbur...@netcom.com) >belch<
/* Happy 1995, plus four dollars for shipping and handling! */
Charles Eicher
<patcl...@delphi.com> wrote:
> January 2, 1995
>
> An Open Letter to Our Colleagues In the Online Communications
> Community:
>
> The announcement by CompuServe and Unisys that users of the GIF image
> format must register by January 10 and pay a royalty or face lawsuits for
> their past usage, is the online communications community's equivalent of
> the sneak attack at Pearl Harbor.
[snip]
> We expect that the CompuServe-Unisys action will spell the death of GIF
> as a commercially viable technology, shifting the attention of the online
> communications community to JPEG imaging.
This is a joke, right? What does Unisys have to do with GIF?
-----------------------
Charles Eicher
cei...@ins.infonet.net
-----------------------
Paul Bruggeman
>Pat Clawson <patcl...@delphi.com> writes:
>
>[A big protest letter, finishing off with...]
>>We expect that the CompuServe-Unisys action will spell the death of GIF
>>as a commercially viable technology, shifting the attention of the online
>>communications community to JPEG imaging.
>
>Why protest it? It should have been killed off YEARS ago!
Hopefully it will help kill off CompuSlave to boot!
Paul
brug...@netcom.com
Jon Mittelhauser
>
> In article <JY064nB.p...@delphi.com>, Pat Clawson
> <patcl...@delphi.com> wrote:
>
> > January 2, 1995
> >
> > An Open Letter to Our Colleagues In the Online Communications
> > Community:
> >
> > The announcement by CompuServe and Unisys that users of the GIF image
> > format must register by January 10 and pay a royalty or face lawsuits for
> > their past usage, is the online communications community's equivalent of
> > the sneak attack at Pearl Harbor.
> [snip]
> > We expect that the CompuServe-Unisys action will spell the death of GIF
> > as a commercially viable technology, shifting the attention of the online
> > communications community to JPEG imaging.
>
> This is a joke, right? What does Unisys have to do with GIF?
Unfortunately, way too much: (this just went around internally
here at Netscape)...
The following just recently showed up in the GRAPHSUPPORT forum on
compuserve.
All you GIF developers read up:
COMPUSERVE ANNOUNCES GIF DEVELOPER LICENSE PROGRAM
On May 28th, 1987, CompuServe introduced the Graphics Interchange Format
(GIF) specification, subsequently revising the specification on August 8,
1990. Since that time, CompuServe has worked extensively with developers
to license GIF and make it the worldwide graphics standard that it
currently is. GIF uses LZW compression and decompression methods that
CompuServe originally thought to be public domain. However, Unisys
Corporation claims patent rights to the LZW algorithm and compression
process. This has caused some confusion as to whether developers need to
license LZW from Unisys.
CompuServe recently negotiated and secured a patent license for LZW
technology from Unisys. Through this license, CompuServe is able to
provide a sub-license to GIF developers. This CompuServe GIF license
agreement grants the developer lawful use of GIF and the LZW algorithm
for certain uses. This relieves licensees from the obligation to license
LZW directly from Unisys and extends to them other benefits of the terms
negotiated by CompuServe. The CompuServe GIF license is based upon terms
established with Unisys by CompuServe. This includes a requirement that
the developer's software be used primarily with the CompuServe
Information Service or use information obtained through the CompuServe
Information Service. This license is subject to a reasonable royalty.
GIF developers who register prior to January 10, 1995 can obtain the
benefit of a clause in the CompuServe-Unisys agreement that states that
Unisys will not pursue royalty claims for past use of LZW. The CompuServe
GIF developer agreement, including compliance requirements, is available
on the CompuServe Information Service in the Standards and Spec's section
of the Graphics Support Forum. A new specification will be finalized
which will become a part of the license agreement.
Additional information and hard copies of the agreement can be obtained
by contacting Larry Wood of Go Graphics at CIS ID# 76703,704, or by phone
at 407-658-2687.
Tom Lane
consider just who to lynch here.
IMHO the bad guy is not CompuServe, but Unisys. The LZW patent in
question is owned by Unisys. It was granted in 1981, if memory serves
--- quite a few years before anyone thought that patents applied to
software. While modem manufacturers have been paying royalties to
Unisys for years (because all the standard modem compression methods use
LZW), Unisys is on record as stating that they would not pursue LZW
patent claims against software implementations not embedded in hardware
devices.
It appears that Unisys has decided that in the current legal climate,
they might win claims against software implementations of LZW. This
includes GIF encoders and versions of Unix "compress". Depressingly,
they may well be right. (But I seem to recall that the patent is worded
so as to apply only to compressors/encoders, *not* decompressors/decoders.
Anyone know for sure?) Their prior promises are, of course, of no
concern compared to the possibility of making some money.
Compuserve has evidently decided that cutting a deal is a better bet
than standing firm against ex post facto piracy. The deal they cut gave
protection only to CIS-associated developers, and none at all to the
larger Internet community. I condemn CIS for their lack of community
spirit, but at the same time, I recognize the true enemy: Unisys.
If you want to organize a boycott, make sure you are boycotting the
right target. Refusing to buy any Unisys product might be a good
start.
regards, tom lane
organizer, Independent JPEG Group
David Farley
this do for LZW-compressed files in other formats, such as TIFF?
David
Achille Hui, the Day Dreamer
| t...@netcom.com (Tom Lane) writes...
+---------
| Um, folks, before we break out the rope and shotguns, we should stop and
| consider just who to lynch here.
|
| IMHO the bad guy is not CompuServe, but Unisys. The LZW patent in
| question is owned by Unisys. It was granted in 1981, if memory serves
| --- quite a few years before anyone thought that patents applied to
| software. While modem manufacturers have been paying royalties to
One thing come to mind. I thought IBM also hold a patent on the LZW
algorithm. Has that issue settled?
-------------------------------------achille (eill...@drizzle.stanford.edu)
Paul Schmidt
writes:
..
>LZW), Unisys is on record as stating that they would not pursue LZW
>patent claims against software implementations not embedded in hardware
>devices.
..
> regards, tom lane
> organizer, Independent JPEG Group
I'd like to note, Tom, that a patent holder must show a nominal level of
effort to defend a patent in order to win a suit. If Unisys is on
record stating that they will not pursue infringements of this patent
for software for seven years, then I'd say their patent is pretty dead.
Of course, I'm no attorney, but given the sequence of events, I'd be
amazed if this goes through to fruition for Unisys.
It's also interesting to note that Unisys just layed off 4000 employees
and filed for bankruptcy. They're still a very large organization, but
they are also the combination of two earlier failing giants: Sperry and
Burroughs.
Paul Schmidt (GDS)
Photodex Corporation
Andy Key
I can't say I'd be concerned.
The only thing about GIF is that that it is :-
a) prevalent
b) compact (due to the LZW)
So perhaps the online community (us) should invent a comparible format with
no legal restrictions based on public domain techniques. Sample code for
compressors and decompressors could be posted all over the net, and all
software houses with email addresses could be sent copies, thus encouraging
support for the new notGIF format. GIF-to-notGIF converters could be
posted around too.
The only concern is compactness. Perhaps we could utilise the Yabba coding
scheme (which is a few % better than GIF), assuming of course, its legally ok.
If the TIFF people were to negotiate a better deal than Compu$erve, then
perhaps we could all benefit from LZW by simply switching to LZW TIFF.
{{{ Andy Key
Speaking for myself, not my employer
Zbigniew Fiedorowicz
AGREEMENT FOR USE OF GRAPHICS INTERCHANGE FORMAT(SM)
This Agreement is entered into as of the effective date set forth below
between CompuServe Incorporated, an Ohio corporation ("CompuServe"), and the
other undersigned party to this Agreement ("Developer").
Section 1. Grant of Rights.
1.1. Effective upon Developer's payment of the initial license fee
described in Section 2, CompuServe hereby grants to Developer a non-exclusive,
worldwide: (a) license to use and exploit GIF(SM) to make, have made, use and
sell Products solely within the Field of Use; and (b) sublicense to use and
exploit the Licensed Patent to make, have made, use and sell Products solely
within the Field of Use.
1.2. CompuServe will provide Developer with a single copy of the most
recent specification for GIF(SM) and any updates to such specification that
are released by CompuServe during the term of this Agreement. Once an updated
version of the GIF(SM) specification has been released by CompuServe,
Developer should incorporate the updates contained in the new specification
into its Products as part of Developer's ordinary release cycle.
1.3. Developer understands that CompuServe and Unysis Corporation are the
owners of all patents, copyrights, service marks and other intellectual
property embodied in the Licensed Technology. In connection with its use of
the Licensed Technology, Developer shall take all steps reasonably required
by CompuServe and/or Unysis Corporation to acknowledge and protect their
respective ownership interests in the patents, copyrights, service marks and
other intellectual property interests embodied in the Licensed Technology.
Developer further agrees not to take any action that would impair the
respective interests of CompuServe and/or Unysis Corporation in the Licensed
Technology.
1.4. Developer may not use, copy, modify or distribute the GIF(SM)
specification, except as expressly permitted by CompuServe. Developer may
make three copies of the GIF(SM) specification for back-up purposes only,
provided CompuServe's service mark, copyright and other notices and legends
are included in such copy. Developer shall not alter or delete any of the
notices or legends contained in the GIFSM specification and any updates
thereto. Developer agrees to provide the following notice on Products or in
any Product documentation: "LZW compression and decompression methods are
licensed under Unysis Corporation's U.S. Patent 4,558,302 and equivalent
foreign patents. Additional technology embodied in GIF(SM) is licensed from
CompuServe Incorporated. Graphics Interchange Format and GIF are service
marks of CompuServe Incorporated."
1.5. Developer shall not grant any customer the right to use a Product
until such customer has been registered by Developer as a user of the Product
and customer's rights to use such Product are governed by an agreement with
Developer providing that (a) the customer's use of such Product will be
primarily for accessing the CompuServe Information Service and for
manipulating and viewing data received through the CompuServe Information
Service, and (b) the customer will not alter, enhance or redistribute any
Product.
1.6. This Agreement does not provide Developer with title to or ownership
of the Licensed Technology or any service mark of CompuServe, but only the
license granted herein. Developer may only grant its customers a limited
right to use Products.
Section 2. License Fees.
2.1. In payment for the licenses granted herein, Developer shall pay
CompuServe a one-time initial license fee of $ 1.00 which is due in full upon
the execution of this Agreement and a fee per Disposition equal to the
greater of (a) 1.5 percent of the selling price per Disposition or (b) $.15
per Disposition. Unless otherwise provided herein, all license fees and
other amounts payable hereunder by Developer shall be paid to CompuServe in
U.S. Dollars within ten (10) days after the end of each quarter. Quarterly
periods may be defined at CompuServe's discretion.
2.2. Developer is solely responsible for payment of any taxes resulting
from Developer's use of the Licensed Technology, except for taxes based on
the income of CompuServe or Unysis Corporation. Developer agrees to hold
CompuServe harmless from all claims and liability arising from Developer's
failure to report or pay such taxes. This paragraph shall survive any
termination of this Agreement.
Section 3. New Products.
Developer shall have the right to add additional Products solely within the
Field of Use by providing notice to CompuServe of the existence of each new
Product at the time such new Product is first offered to Developer's customers.
Section 4. Reports.
Developer shall keep adequate records to accurately determine the payments
due under this Agreement. Each payment hereunder shall be made and
accompanied by a report in such manner and form as requested by CompuServe
setting forth the number of Dispositions of each Product occurring hereunder
and any other information reasonably necessary to calculate payments due
hereunder. Developer shall not enter into any arrangement under which copies
of Products will be prepared or the Licensed Technology used, unless
Developer has taken steps to ensure that it can account for and pay the
royalties required hereunder.
Section 5. Audits.
CompuServe shall have the right, no more than once during any calendar year,
to have an independent certified public accountant inspect the relevant
records of Developer on seven business days notice and during regular
business hours to verify the reports and payments required to be made
hereunder. Should an underpayment in excess of 10 percent be discovered,
Developer shall pay the cost of the audit. In any event, Developer shall
promptly pay any underpayment together with interest at the annual rate of 12
percent.
Section 6. Assignment.
This Agreement and the licenses granted herein may not be assigned by
Developer without the prior written consent of CompuServe.
Section 7. License Term.
The initial term of this Agreement shall commence on the effective date of
this Agreement and shall expire at midnight (EST) on the first anniversary of
such date. This Agreement shall automatically renew for additional
consecutive one year periods, unless either party delivers a written notice
of termination to the other party not later than 30 days before the
expiration of the then current term.
Section 8. Termination for Cause.
This Agreement may be terminated by CompuServe: (a) upon 30 days prior
written notice, if Developer is in breach of any of its material obligations
hereunder and the breach is not remedied within such 30 day period; or (b)
upon reasonable written notice, if the Licensed Patent expires or is found
invalid or unenforceable in any proceeding before the U.S. Patent and
Trademark Office or in a U.S. court of law, after all appropriate appeals
have been finally decided. Promptly following any termination of this
Agreement, Developer shall (i) return all copies of the GIF(SM) specification
and any confidential information of CompuServe then in its possession or
control to CompuServe, (ii) stop using the Licensed Technology, and (iii)
stop distributing Products.
Section 9. Notices.
All notices or other communications required or permitted under this Agreement
shall be in writing and shall be delivered by personal delivery, registered
mail return receipt requested, a "Next Day Air" delivery service or by
customary electronic means, addressed as indicated on the signature page of
this Agreement.
Section 10. Miscellaneous.
10.1. CompuServe represents that it has executed an agreement with Unysis
Corporation dated June 21, 1994, pursuant to which Unisys Corporation (a)
granted to CompuServe a license to sublicense the technology covered by the
Licensed Patent to make, have made, use and sell Products in the Field of
Use, provided such Products are identified to Unysis Corporation as required
by such agreement, and (b) agreed as follows: "Unysis hereby releases any and
all claims of any nature based upon any use of the technology of the Licensed
Patent by Licensee in the Products, internal use in offering the CompuServe
Information Service, or use by its licensees in derivatives of the Products,
which have occurred to date and during the period of implementation of this
Agreement, provided that Licensee shall exercise commercially diligent
efforts to implement this Agreement as soon as reasonably practicable and in
no case later than six (6) months after the date this Agreement is executed
by Licensee."
10.2. EXCEPT AS SET FORTH IN THIS AGREEMENT, COMPUSERVE DISCLAIMS ANY AND
ALL EXPRESS AND IMPLIED PROMISES, REPRESENTATIONS AND WARRANTIES WITH RESPECT
TO THE LICENSED TECHNOLOGY, INCLUDING ITS CONFORMITY TO ANY REPRESENTATION OR
DESCRIPTION, THE EXISTENCE OF ANY LATENT OR PATENT DEFECTS, OR ITS
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. This paragraph shall
survive any termination of this Agreement.
10.3. The cumulative liability of CompuServe for all claims arising out of
or relating to this Agreement shall not exceed the total amount of all
license fees paid to CompuServe hereunder. In no event shall CompuServe be
liable for any lost profits or incidental, special, exemplary or consequential
damages for any claims arising out of or relating to this Agreement. This
paragraph shall survive any termination of this Agreement.
10.4. Nothing in this Agreement shall be construed as: (a) requiring the
maintenance of the Licensed Technology; (b) a warranty as to the validity or
scope of the Licensed Technology; (c) a warranty or representation that any
Product will be free from infringement of patents, copyrights, trademarks or
other similar intellectual property interests of third parties; (d) an
agreement to bring or prosecute actions against third party infringers of the
Licensed Technology; (e) conferring any license or right under any patent
other than the Licensed Patent; or (f) conferring any right to use the
Licensed Technology outside the Field of Use.
10.5. This Agreement contains the complete and final agreement between the
parties, and supersedes all previous understandings related to the subject
matter hereof whether oral or written. This Agreement may only be modified
by a written agreement signed by duly authorized representatives of the
parties.
10.6. The validity and interpretation of this Agreement shall be governed
by Ohio law, without regard to conflict of laws principles. The parties
further consent to the exclusive jurisdiction of the state and federal courts
located in the City of Columbus, Ohio. Process may be served on either party
by U.S. Mail, postage prepaid, certified or registered, return receipt
requested, and addressed as indicated on the signature page of this Agreement.
This paragraph shall survive any termination of this Agreement.
10.7. Developer shall not disclose to anyone for any reason the terms of
this Agreement or any information provided to Developer by CompuServe that is
marked as being confidential information of CompuServe, except with
CompuServe's prior written consent. Developer shall protect the
confidentiality of such information with at least the same degree of care it
employs to protect its own similar confidential information. Developer may
use such confidential information of CompuServe solely for purposes of
exercising its rights under this Agreement, and shall make no other use of
such information. This paragraph shall survive any termination of this
Agreement.
10.8. Developer acknowledges and agrees that Unisys Corporation is an
intended third party beneficiary of each and every provision of this
Agreement, other than Section 2 hereof, and may enforce any rights it may
have under such provisions to the fullest extent permitted by law as if it
were a party to this Agreement. This paragraph shall survive any termination
of this Agreement.
10.9. Developer shall indemnify and hold CompuServe, and its officers,
directors, agents, employees and affiliates, harmless against any damage,
loss, claim, action, liability, cost or expense suffered by or brought against
any of the foregoing indemnified parties arising out of or relating to any
breach or violation of this Agreement by Developer or its customers or any
conduct of Developer or its customers relating to their use of the Licensed
Technology. This paragraph shall survive any termination of this Agreement.
Section 11. Definitions. As used herein:
11.1. "Disposition" means the sale, lease or license or any other grant of
rights to a Product or any new Product as may be added pursuant to Section 3
of this Agreement.
11.2. "Field of Use" means software provided by CompuServe or Developer and
used by subscribers to the CompuServe Information Service to access the
CompuServe Information Service or use information obtained over the
CompuServe Information Service which utilizes the technology of the Licensed
Patent.
11.3. "GIF(SM)" means CompuServe's copyright and other intellectual property
embodied in the Graphics Interchange Format(SM) as described in the most
recent release of the specification for the Graphics Interchange Format(SM),
as the same may be updated from time to time during the term of this Agreement,
but (for purposes of this Agreement) does not include the technology covered
by the Licensed Patent or CompuServe's service marks for the Graphics
Interchange Format or GIF.
11.4. "Licensed Patent" means U.S. Patent 4,558,302 registered in the name
of Unisys Corporation relating to digital data compression and decompression,
and all foreign counterparts.
11.5. "Licensed Technology" means, collectively, GIF(SM) and the Licensed
Patent.
11.6. "Products" means software that is developed or distributed under this
Agreement which is designed for and used primarily for accessing the
CompuServe Information Service and for manipulating and viewing data received
through the CompuServe Information Service, and any new Products as may be
added pursuant to Section 3 of this Agreement.
Signatures:
CompuServe Incorporated Developer
By____________________ By_______________________________________
Name: Kent D. Stuckey Name:____________________________________
Title: Secretary Title:___________________________________
Address: 5000 Arlington Centre Blvd. Address:_________________
____________________________________
Columbus, Ohio 43220 ____________________________________
Phone: (614) 457-8600 Phone:___________________________________
Fax: (614) 457-9665 Fax:_____________________________________
Effective Date: __________________________________
Michael Dillon
awoo...@ucs.indiana.edu (Andrew Wooldridge) wrote:
> Don Thaxton (tha...@ptgroup.com) wrote:
> If we wish to be good citizens and quietly switch to jpeg, then would
> that not give fuel to the litigation fires and let other sharks out there
> think again about their "free" software? If we get up in arms and
> refuse to comply, will that brand the internet as a bunch of anarchists?
> I for one do not think so. I believe that there should be some kind of
> immediate, coherent, and unified responce to this legalized attack on the
> internet community. Just what that response would be is something I
> do not know, but if someone of a respected position on the internet
> offered a resonable course of action, I know that I would rally behind them
> to defend, especially, the Web.
When UNISYS started bringing out their legal guns against LZW users
a couple of years back, the GNU folks at the Free Software Foundation
came up with an algorithm and compression format that was FREE of
the UNISYS patents. This was the gzip format. Up to that time, GNU
software had been distributed in archives compressed with "compress"
which uses LZW.
The clear answer to this problem is to once again use the GZIP technology
to create a similar format to GIF and to make the source code freely
available to other programmers to include in their applications
whether commercial or otherwise. This code should be free of the GPL since
it is to be an image format standard and therefore is not likely to
be improved or changed anyway. If people don't agree that the code
is likely to stay frozen, then at least the first reference standard
implementation could be GPL free to allow it to be quickly and widely
implemented.
I suggest that this format be called WIF or Web Image Format since
the World Wide Web is the major victim of this attack by UNISYS and
it will be the major beneficiary of a new format.
---------------------------------------------------------------------
Cool cats, brick bats, bad boys wearin' big hats
Surf's up, my cup, floating, flying, rising up.
Michael Dillon mpdi...@halcyon.com
C-4 Powerhouse, RR #2 mic...@junction.net
Armstrong, BC V0E 1B0 Fido: 1:353/350
Canada BBS: +1-604-546-2705
Kimberley Burchett
if you release it and make the GIF encoder/decoder a plug-in? In that
case, it's up to the user whether the format is actually used so does
that mean that they're the one who infringed the copyright? :)
--
Kimberley <OK...@max.tiac.net>
Markku Savela
This may be too early, but would it help any, if we keep the GIF
general structure, but replace the LZW stream in it with whatever GNU
gzip is using? Would this still infringe CompuServe?
Am just about to release my next version of Xew widgets and it also
contains a decoder for GIF. Am I supposed to rip this off from the
code now? I am extremely interested whether the "problem" issue covers
decoder-only applications too?
--
Markku Savela (m...@hemuli.tte.vtt.fi), Technical Research Centre of Finland
Multimedia Systems, P.O.Box 1203, FIN-02044 VTT, http://www.funet.fi/~savela
jim frost
>Markku Savela (Markku...@tte.vtt.fi) wrote:
>: Am just about to release my next version of Xew widgets and it also
>: contains a decoder for GIF. Am I supposed to rip this off from the
>: code now? I am extremely interested whether the "problem" issue covers
>: decoder-only applications too?
>I'd wait and see. Surely there will be quite a protest over this. I
>sincerely doubt Compuserve and Unisys will have their way.
I believe that the CIS licensing restrictions only apply if you decide
to license LZW from them rather than Unisys. Unless you license LZW
from CIS, CIS cannot prosecute you for using the GIF format based on
their previous terms:
-- cut here --
G I F (tm)
Graphics Interchange Format (tm)
A standard defining a mechanism
for the storage and transmission
of raster-based graphics information
June 15, 1987
(c) CompuServe Incorporated, 1987
All rights reserved
While this document is copyrighted, the information
contained within is made available for use in computer
software without royalties, or licensing restrictions.
GIF and 'Graphics Interchange Format' are trademarks of
CompuServe, Incorporated.
an H&R Block Company
5000 Arlington Centre Blvd.
Columbus, Ohio 43220
(614) 457-8600
-- cut here --
Unisys could sue people using GIF without a license from either CIS or
Unisys, but CIS cannot as they explicitly gave away rights to the
format.
I'm not a lawyer, but that much seems pretty clear, if not the
validity of the LZW patent in the first place.
jim frost
ji...@worlds.std.com
--
http://www.std.com/homepages/jimf
Jay Farrell
> [I'm crossposting to gnu.misc.discuss because some people there may be
> interested. For those joining in this discussion late, you might want
> to see the start of this thread in comp.graphics with the above subject
> line].
And be sure to drop by comp.infosystems.www.users -- a real firestorm
raging there!
--
Jay Farrell http://www.netaxs.com/~jayfar/
jay...@netaxs.com
Philadelphia, Pennsylvania, U.S.A.
---------------------------------------------------------------------
"Wonder How A Po' M*ther F*cker Feel"
-- Joshua Jordan (1919-1993)
Jay Farrell
pa...@casper.med.uth.tmc.edu (Cameron Payne) wrote:
> In article <fiedorow-030...@slip1-12.acs.ohio-state.edu>
fied...@math.mps.ohio-state.edu (Zbigniew Fiedorowicz) writes:
> >Here is the text of the CIS license:
>
> >AGREEMENT FOR USE OF GRAPHICS INTERCHANGE FORMAT(SM)
>
> [text deleted]
>
> Hold a second. If this is the official agreement, how come Unisys is
> mis-spelled throughout the document as Unysis?
>
> This is starting to sound more like a hoax...
>
Yeah, but no word yet from Compuserve and we've been eMailing 'em stuff
from these threads since last evening.
Elizabeth M. Phillips
In a previous article, ra...@sunpool.cs.tu-magdeburg.de (Andreas Raab) says:
>This would be a really funny idea but I think GNU gzip uses LZW, too.
Correction it DOESN'T use LZW. it's uses something called
LZ77 <shrug> which is superior to it.
--
Bill Davidson
>If you want to organize a boycott, make sure you are boycotting the
>right target. Refusing to buy any Unisys product might be a good
>start.
I agree. Persuading others not to buy Unisys products can help too.
I've already quit using compress (gzip is better anyway).
It's not a big deal for me to quit using GIF either. Gzip'd raster
files are usually smaller.
Patents can kill standards. This is one that's not really worth saving
anyway.
--Bill Davidson
Cameron Payne
>AGREEMENT FOR USE OF GRAPHICS INTERCHANGE FORMAT(SM)
[text deleted]
Hold a second. If this is the official agreement, how come Unisys is
mis-spelled throughout the document as Unysis?
This is starting to sound more like a hoax...
---------------------
Cameron Payne
pa...@casper.med.uth.tmc.edu
"If I neither say that a thing exists, nor deny it, nor neither, nor both,
then it will take a very long time to dispute me" -- Sherpan philosopher
Andreas Raab
: This may be too early, but would it help any, if we keep the GIF
: general structure, but replace the LZW stream in it with whatever GNU
: gzip is using? Would this still infringe CompuServe?
This would be a really funny idea but I think GNU gzip uses LZW, too.
The main problem is (to my mind) that because LZW is a really easy
and quite fast algorithm, it is the most popular compression scheme used
(In the TIFF specification they needed about 20 lines of pseudo code
to describe it).
Bye,
Andreas
--
+------------------------------------------+--------------------------+
I Andreas Raab I I
I Department of Simulation and Graphics I Phone: +49 391 5592 3065 I
I University "Otto von Guericke" Magdeburg I Fax: +49 391 5592 2447 I
I Email: ra...@sunpool.cs.tu-magdeburg.de I I
+------------------------------------------+--------------------------+
Bill Davidson
>I'd like to note, Tom, that a patent holder must show a nominal level of
>effort to defend a patent in order to win a suit. If Unisys is on
>record stating that they will not pursue infringements of this patent
>for software for seven years, then I'd say their patent is pretty dead.
>Of course, I'm no attorney, but given the sequence of events, I'd be
>amazed if this goes through to fruition for Unisys.
The problem is, who is willing to go to court over it. Patent court
costs literally millions of dollars per case. It's especially
expensive when hotly contested over grey areas (software patents are
still relatively grey). Remember when some company patented using XOR
to move cursors across a screen? That patent had no merit but the
slimeballs who held it charged a relatively affordable fee and nobody
was willing to spend the megabucks in court to shoot it down because
it was so much cheaper to settle.
>It's also interesting to note that Unisys just layed off 4000 employees
>and filed for bankruptcy. They're still a very large organization, but
>they are also the combination of two earlier failing giants: Sperry and
>Burroughs.
This explains a lot. Lawyers get a lot more power in these kinds of
situations and so things like this are more likly to happen. In the
case of GIF, and LZW in general, this attitude will kill it in the
freeware and shareware market which will in turn reduce its appeal to
the commercial market.
As an example, note that the Independant JPEG Group chose not to make
arithmetic coding available due to patent restrictions and so
arithmetic coding, while clearly superior to huffman coding, is almost
unheard of in the JPEG world. If a commercial vendor pays the fee and
implements it, his files won't be compatible with everybody else's.
Freeware is a major driving force behind these types of standards.
Killing lawyers in wholesale fashion keeps on seeming more and more
necessary to the health of society.
--Bill Davidson
Major Disclaimer: These are my opinions and not necessarily those of my
employer.
Bill Davidson
>This may be too early, but would it help any, if we keep the GIF
>general structure, but replace the LZW stream in it with whatever GNU
>gzip is using? Would this still infringe CompuServe?
It would if you called it GIF. There's nothing to stop you or a
consortium from coming up with their own patent free format.
In article <3ecfhs$h...@pappel.cs.tu-magdeburg.de>, Andreas Raab <ra...@sunpool.cs.tu-magdeburg.de> wrote:
>This would be a really funny idea but I think GNU gzip uses LZW, too.
>The main problem is (to my mind) that because LZW is a really easy
>and quite fast algorithm, it is the most popular compression scheme used
>(In the TIFF specification they needed about 20 lines of pseudo code
>to describe it).
To quote gzip's README (apologies if my gzip is out of date):
This is the file README for the gzip distribution, version 1.2.4.
gzip (GNU zip) is a compression utility designed to be a replacement
for 'compress'. Its main advantages over compress are much better
compression and freedom from patented algorithms. The GNU Project
uses it as the standard compression program for its system.
In fact, it is a variant of LZ77 (*not* LZW). Apparently, the GNU
people believe at least their variant to be patent free.
--Bill Davidson
da...@freeside.fc.net
: This may be too early, but would it help any, if we keep the GIF
: general structure, but replace the LZW stream in it with whatever GNU
: gzip is using? Would this still infringe CompuServe?
gzip uses a Lempel Ziv algorithm from 1977, they say in the doc that
it is a variant of lzw, but I do not know anything about the legalities
involved.
: Am just about to release my next version of Xew widgets and it also
: contains a decoder for GIF. Am I supposed to rip this off from the
: code now? I am extremely interested whether the "problem" issue covers
: decoder-only applications too?
I'd wait and see. Surely there will be quite a protest over this. I
sincerely doubt Compuserve and Unisys will have their way.
[I'm crossposting to gnu.misc.discuss because some people there may be
interested. For those joining in this discussion late, you might want
to see the start of this thread in comp.graphics with the above subject
line].
-Doug
S. Keith Graham
>This may be too early, but would it help any, if we keep the GIF
>general structure, but replace the LZW stream in it with whatever GNU
>gzip is using? Would this still infringe CompuServe?
>Am just about to release my next version of Xew widgets and it also
>contains a decoder for GIF. Am I supposed to rip this off from the
>code now? I am extremely interested whether the "problem" issue covers
>decoder-only applications too?
For whatever its worth, their patent doesn't cover decompression..
Keith Graham
vap...@cad.gatech.edu
Per Jacobsen
> However, let's all wait a few days. We saw what the net did to Intel,
> when far less was at stake. What will the net do to Compuserve and
> Unisys?
Something unpleasant I shouldn't wonder :)
Per Jacobsen
> Killing lawyers in wholesale fashion keeps on seeming more and more
> necessary to the health of society.
As Shakespeare would agree..
Mr Aardvark
comp.infosystems.www.providers......i think thats
the full name. I just posted an article there but i
dont think i crossposted it.
Can we have one newsgroup either comp.graphics
or www.providers for this topic. ?
phil
Mark Koennecke
is there actually a real issue? What about the ANARCHY solution for the problem. There are
GIF's using up hard disk space on millions of machines, thousands of copies of GIF related
software are installed and floating around in netland. The task of tracking all this down
and suing everyone for license fees is gigantic and cannot (to my humble opinion) been
done. What, if Compuserve has been legally obliged to publish its statement but is not willing
to prosecute it. You need both: a law and a prosecuter, and I think the latter is missing!
Cheers,
Mark
Chuck Divine
Actually he wouldn't. The line, "First thing, let's kill all the
lawyers" was spoken by a minor villain, a rather nasty revolutionary
who wanted to destroy society as it then was. Shakespeare was
actually praising lawyers for being a bulwark against tyranny, among
other things.
Of course, all this doesn't mean I'm not in favor of killing all the
lawyers :-)
Phil Howard
/---
| IMHO the bad guy is not CompuServe, but Unisys. The LZW patent in
| question is owned by Unisys. It was granted in 1981, if memory serves
\---
LZW is also a lousy way to compress image data. It works fine for text
where things that are the same are exactly the same. Images are very
different than that things that are the same are just close. LZW will
totally miss similarity.
LZW based GIF should die a sudden death as soon as possible.
/---
| It appears that Unisys has decided that in the current legal climate,
| they might win claims against software implementations of LZW. This
| includes GIF encoders and versions of Unix "compress". Depressingly,
| they may well be right. (But I seem to recall that the patent is worded
| so as to apply only to compressors/encoders, *not* decompressors/decoders.
| Anyone know for sure?) Their prior promises are, of course, of no
| concern compared to the possibility of making some money.
\---
And maybe next year they will decide they can pursue decoders as well.
LZW based GIF should die a sudden death as soon as possible.
/---
| If you want to organize a boycott, make sure you are boycotting the
| right target. Refusing to buy any Unisys product might be a good
| start.
\---
I fully agree. I also plan to now boycott GIF. Users of CIS (I am not
one of them) should start using more .JPG files on CompuServe.
Actually, I'm even suspecting that CIS might well have intended to kill
off GIF by doing this. GIF did do a good job of getting things going in
exchanging graphics and enhancing CompuServe's business. Surely they can
recognize that their competitors benefit as well, and that JPEG is just
as usable (well actually more usable since the files are smaller and take
less time to upload) on CompuServe.
LZW based GIF should die a sudden death as soon as possible.
--
Phil Howard KA9WGN | The drive spec says the capacity is 600mb unformatted
Unix/Internet/Sys Admin | and 525mb formatted. So where do I find an unformat
CLR/Fast-Tax | utility?
ph...@fasttax.com |
Joe Buck
>Markku Savela (Markku...@tte.vtt.fi) wrote:
>: Am just about to release my next version of Xew widgets and it also
>: contains a decoder for GIF. Am I supposed to rip this off from the
>: code now? I am extremely interested whether the "problem" issue covers
>: decoder-only applications too?
da...@freeside.fc.net () writes:
>I'd wait and see. Surely there will be quite a protest over this. I
>sincerely doubt Compuserve and Unisys will have their way.
The Unisys patent covers only compression, not decompression, so software
that only decompresses and displays GIF images can't violate the patent
(assuming it is valid). For more on this, see the discussion in the gzip
documentation. Whether Compuserve can make claims about *their*
intellectual property stick are another matter.
However, let's all wait a few days. We saw what the net did to Intel,
when far less was at stake. What will the net do to Compuserve and
Unisys?
--
-- Joe Buck <jb...@synopsys.com> (not speaking for Synopsys, Inc)
Phone: +1 415 694 1729
Chris Lilley
>
> Markku Savela (Markku...@tte.vtt.fi) wrote:
>
> : This may be too early, but would it help any, if we keep the GIF
> : general structure, but replace the LZW stream in it with whatever GNU
> : gzip is using? Would this still infringe CompuServe?
>
> This would be a really funny idea but I think GNU gzip uses LZW, too
Ah. I thought the main reason .gz files were proliferating was because they
avoided the lzw-issue.
> The main problem is (to my mind) that because LZW is a really easy
> and quite fast algorithm, it is the most popular compression scheme used
> (In the TIFF specification they needed about 20 lines of pseudo code
> to describe it).
I note that LZW compression was part of the baseline TIFF 5 spec but
was moved to the TIFF Extensions section in TIFF 6 (meaning that
previous baseline TIFFs were no longer baseline!). The relevant
section has a disclaimer saying that "Unisys believes that one or
more of their patents covers any and all uses of LZW ...We
therefore do not encourage the use of LZW within TIFF files."
This is taken from the draft TIFF 6 spec (Feb 1992) which is all I
seem to be able to find right now. The full spec is on SGI's FTP
server.
SO - if LZW is to be avoided for TIFF images, what does that leave?
Baseline TIFF is supposed to support Packbits and Huffman
compression. TIFF Extensions also has support for JPEG compression.
I would be interested in hearing about people's experiences of
decompression speed for these methods. I work on an HP workstation
which is rather above the average net.cpu but I would like images
I put on the Web to be usable on low-end systems too.
--
Chris Lilley
+-------------------------------------------------------------------------+
| Technical Author, Manchester and North HPC Training & Education Centre |
+-------------------------------------------------------------------------+
| Computer Graphics Unit, | Email: Chris....@mcc.ac.uk |
| Manchester Computing Centre, | Voice: +44 61 275 6045 |
| Oxford Road, | Fax: +44 61 275 6040 |
| Manchester, UK. M13 9PL | X400: /I=c /S=lilley |
| /O=manchester-computing-centre /PRMD=UK.AC /ADMD= /C=GB/|
|<A HREF="http://info.mcc.ac.uk/CGU/staff/lilley/lilley.html">my page</A> |
+-------------------------------------------------------------------------+
|This is supposed to be data transfer, not artificial intelligence. M VanH|
+-------------------------------------------------------------------------+
Chris Lilley
> In article <D1v3B...@cray.com>, bi...@cray.com (Bill Davidson) wrote:
> > Patents can kill standards. This is one that's not really worth saving
> > anyway.
> Quite true, but many of us on the WWW like the fade in effect that
> interlaced GIF's provide in the leading browse. Can we extend some other
> format to provide interlacing?
TIFF already has strips, and variable numbers of rows per strip. So you
can have an interlaced effect if you want. The image data does not have
to be in sequential order.
Gary Schrock
>1.5. Developer shall not grant any customer the right to use a Product
>until such customer has been registered by Developer as a user of the Product
>and customer's rights to use such Product are governed by an agreement with
>Developer providing that (a) the customer's use of such Product will be
>primarily for accessing the CompuServe Information Service and for
>manipulating and viewing data received through the CompuServe Information
>Service, and (b) the customer will not alter, enhance or redistribute any
>Product.
Hmm....correct me if I'm reading this wrong, but I get the impression
that someone who has developed a graphics viewer would fall under
this paragraph. It also seems to me that this prevents said viewer from
being distributed as shareware or freeware since the developer would
have no way of registering them prior to their use of the product. PLUS,
the user would only be able to use it in viewing data received off
of CompuServe (such that you couldn't view a gif that you downloaded
off the internet).
Here's hoping the gif format dies.
Gary Schrock
gary.s...@ssc.msu.edu
Wallace Roberts
[ ...megasnip(tm)... ]
>This is a joke, right?
unfortunately, no.
>What does Unisys have to do with GIF?
unisys owns the lzw patent; gif uses lzw to compress the image data.
gears,
ye wilde ryder
--
robe...@agcs.com | 86 cr250 "dirt devil" 83 v65 magna "animal"
"E Pluribus Unix" | 79 it250 "mr. reliable" 82 v45 magna "elliot"
"Criminals (especially tyrants) prefer unarmed victims."
"...sunlight on chrome, the blur of the landscape, every nerve aware."
Scott Elliott
> > interlaced GIF's provide in the leading browse. Can we extend some other
> > format to provide interlacing?
>
> TIFF already has strips, and variable numbers of rows per strip. So you
> can have an interlaced effect if you want. The image data does not have
> to be in sequential order.
In order to store TIFF strips in an order resembling interlacing, it
would be necessary to reduce strips to one scanline--which would be
terribly inefficient and produce poor compression (if compression was
used). Further, it wouldn't accomplish the desired purpose, since a
typical reader would still display the lines sequentially, ignoring
the peculiar order in which they were recorded in the file. The
purpose behind interlacing GIF files is to give a rough picture of the
entire image after only 1/8th of the data has arrived. While it would
be possible for a TIFF reader to take advantage of data which arrives
out-of-order, I know of no TIFF reader which exploits this capability.
Paul Bruggeman
>necessary to the health of society.
Paul
my views represent my employer-
ME Inc.
Jay Farrell
Quite true, but many of us on the WWW like the fade in effect that
interlaced GIF's provide in the leading browse. Can we extend some other
format to provide interlacing?
--
Kent Borg
hoog...@purcell.ecn.purdue.edu (Bob Hoogland) wrote:
> CIS's guilt lies primarily in their handling of it, waiting silently and
> then announcing a two-week deadline in the middle of the holiday lull (as
> expressed eloquently by Pat Clawson). This was obviously in the works for
> more than the six months since the pact was actually signed, too. CIS thus
> deserves the label of international information terrorist as much as Unisys.
Actually, I think that CI$ either procrastinated and avoided the
unpleasantness or they *intentionally* did this in a way designed to be as
unworkable as possible.
Think about it. Compu$erve spends its spare time looking for spare parts
for their DEC 10s, they were not exactly happy when the greedy Unisys
lawyers came knocking.
What can they do? Well, take advantage of their size to do this in a way
which is as likely to fail as possible. The idea of finding high tech
folks who are not mostly all on vacation the week between Christmas and
New Years is silly. And little happens the first week after New Years as
the hangovers clear.
Compu$erve managed to set a deadline no one could match. It was too silly
so they had to extend it trivially, currently at the end of the month as I
last saw.
The best way to kill the LZW patent is to somehow create massive
non-compliance. Compu$serve might just have done that.
I am no great fan of GIF or the GNU folks, but I am firmly opposed to
software patents. This might kill them. Or it might not.
-kb
--
Kent Borg +1 (617) 776-6899
kent...@borg.org
kent...@aol.com
Boycot Unisys.
Daniel R. Kegel
Newsgroups: jpl.www,jpl.general
Subject: An Alternative to the GIF Format
Date: 4 Jan 1995 22:18 UT
Organization: Jet Propulsion Laboratory
Message-ID: <4JAN1995...@kelvin.jpl.nasa.gov>
Because of recent actions taken by Unisys and Compuserve, there is strong
possibility that the GIF format may no longer be widely supported
and fall out of fashion. If this is the case, there is an alternative
lossless image format that currently exists that may be used in place of
the GIF format. This image format is called PDS and was developed at the
Jet Propulsion Lab in Pasadena, California.
The PDS (Planetary Data System) format was created to be a general data
format to store data collected from NASA planetary missions, astronomical
observations and Earth orbiting spacecraft. The PDS format is the defacto
standard used on the NASA CD-ROMs, which includes the Voyager, Galileo,
Viking and Magellan CD-ROMs.
The PDS format has the following features:
o No color limitation (meaning 8, 16, 24 and 32 bits are supported)
o Optional Huffman compression (patent free)
o No image size limitation
o Multiple images per file supported
o Supports additional data sets in addition to images.
o Is portable to all computer platforms.
o Software that currently supports the PDS format includes xv, xloadimage,
pbmplus, IMDISP and NIH Image
Specifications for the PDS format may be obtained from JPL by sending email
to pds_op...@jplpds.jpl.nasa.gov. Also, the following home page is
available on the World Wide Web about PDS group at JPL:
Examples of the PDS format used for the Voyager, Magellan and Viking
images on CD-ROMs are available using ftp to
ftp://explorer.arc.nasa.gov/cdrom
The PDS format currently does not support a lossy compression, but this
could be added if there is a demand for it. Its only real
drawback is that it not widely used outside of NASA. This could change
if the GIF format is no longer widely supported.
___ _____ ___
/_ /| /____/ \ /_ /| Ron Baalke | baa...@kelvin.jpl.nasa.gov
| | | | __ \ /| | | | JPL/Telos |
___| | | | |__) |/ | | |__ Galileo S-Band | Nothing travels faster than
/___| | | | ___/ | |/__ /| Pasadena, CA | the speed of light except,
|_____|/ |_|/ |_____|/ | of course, bad news.
Vladimir Malukh \beard\
following question:
Does anybody knows what I suppose to do with all software I've
already got, not from Compuserve but from other providers such:
CorelDraw
AutoCAD
3D Studio
MS-Word for Windows
All those packages are dealing somehow ( importing at least )
GIF images. what I have to do with all CDs I purchased, which
are containing hundreds images? I (and I'm anot alone )have already
paid a lot for all of this, and I can't see any LEGAL reason to pay
again!
Do CompuServe/Unisys suggest me to ask Autodesk and Microsoft to
remove GIF maintaining facilities from their products and replace
my copies with newest LEGAL ones?
Vladimir Malukh
ProProGroup Ltd. Novosibirsk RUSSIA
pulse
<tim oren speaking for compuserve>
Good evening. Someone from CompuServe is watching, and I hope I can
clear up a few things. I'm Vice President of Future Technology at
CompuServe. I'm involved in this because the inventor of GIF
currently works for me. Jon Shemitz (j...@armory.com) who posted
earlier in this thread, can authenticate me. [Jon: Your first born
is named Samuel Dashiell, and we first met on Stuart II.]
First, some clarifications:
1. CompuServe is not asserting proprietary rights in the GIF spec.
As pointed out earlier in the thread, this has long been publicly
available.
2. GIF was originally developed using the LZW algorithm which was
found in the open literature, and which was not know to us to be a
subject of patent filing at that point. We found this out, to our
displeasure, after the GIF spec was widely disseminated and used.
3. CompuServe at that point found it necessary to take a license to
the patent. Since a number of our developers had used GIF in good
faith, we also negotiated a pass through license for their benefit.
Parts of this license, with a poor interpretation, have been widely
distributed outside of their original context, which was to
developers of CompuServe related products alone. GIF is included in
this license because we are unable to pass through a general license
to practice LZW.
4. It is not the intent of CompuServe to attempt to enforce
proprietary rights in GIF against users or developers, including
those of Web technology. As sponsors of CommerceNet and new
entrants to the Internet access business, we intend to assist in the
development of the Web, not to sabotage it. We cannot and do not
speak for Unisys' intent in this matter.
Second, please don't mailbomb Sam or the postmaster or webmaster.
They have enough work to do without having to write mail 'bots.
We're watching this news group and others, and will be interested in
creative comments on how we can be respond to the situation,
considering the legal constraint we've been placed under. Please
think about how we can add some benefits for our end users if we
find it necessary to put them through a standards transition.
Finally, there will be a more formal statement along shortly.
Tim Oren
CompuServe, Inc.
70004...@compuserve.com
Non-disclaimer: I do speak for the company.
-
/* pulse (lu-zer) adj. feelings of nausea, vomit, a puking sensation */
Rik Heywood
freely owned for several years then I can see no good reason why
I should not start charging them for the space WinCim etc uses on
my hard drive. My rates will be outrageous and they have till 7pm
on Monday to start paying.
Rik, assuming it must be a joke, as no-one can be that stupid.
:-)
Daniel Glazman
What is the real validity of a such change ? All of us, we acquired
algorithms, codes, software and so at a time GIF was public, right ?
I don't think laws or contracts can be retroactive anywhere in the
world...
</Daniel>
Bob Hoogland
CIS's guilt lies primarily in their handling of it, waiting silently and
then announcing a two-week deadline in the middle of the holiday lull (as
expressed eloquently by Pat Clawson). This was obviously in the works for
more than the six months since the pact was actually signed, too. CIS thus
deserves the label of international information terrorist as much as Unisys.
BH [opinions my own, etc.]
---------------------------------------------
t...@netcom.com (Tom Lane) writes:
>Um, folks, before we break out the rope and shotguns, we should stop and
>consider just who to lynch here.
>IMHO the bad guy is not CompuServe, but Unisys. The LZW patent in
>question is owned by Unisys. It was granted in 1981, if memory serves
[...]
>Compuserve has evidently decided that cutting a deal is a better bet
>than standing firm against ex post facto piracy. The deal they cut gave
>protection only to CIS-associated developers, and none at all to the
>larger Internet community. I condemn CIS for their lack of community
>spirit, but at the same time, I recognize the true enemy: Unisys.
Matthew D. Healy
Lane) wrote:
...
> If you want to organize a boycott, make sure you are boycotting the
> right target. Refusing to buy any Unisys product might be a good
> start. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Uhh, WHAT unisys product? Two dying dinosaurs mated to form
UNISYS, which is now almost dead precisely because so few people
buy their products today.
I rather suspect that the dire condition of their firm is, in fact,
their real motivation: they see a means of extracting big bucks
from the fast-growing online community and perhaps salvage their
company...I fervently hope the negative public reaction to this
move becomes the final nail in their coffin.
--
"The Psalm today is #131, on page 107 of my dissertation.
Please read responsively by half-verses, divided at the star."
Matthew D. Healy matthe...@yale.edu
Postdoc,Yale School of Medicine, Genetics & Medical Informatics,
SHM I-148, 333 Cedar St, New Haven, CT 06510
ahti heinla
> This may be too early, but would it help any, if we keep the GIF
> general structure, but replace the LZW stream in it with whatever GNU
> gzip is using? Would this still infringe CompuServe?
is shouldn't infringe unisys nor compuserve. the practical value
of such modification would be questionable, though, since it would
essentially be still yet another new format.
as for the exact stream coding scheme to use (gzip or something
else), this isn't that important in the first place.
Andreas Raab <ra...@sunpool.cs.tu-magdeburg.de> replied:
> The main problem is (to my mind) that because LZW is a really easy
> and quite fast algorithm, it is the most popular compression scheme used
> (In the TIFF specification they needed about 20 lines of pseudo code
> to describe it).
on the other hand, i don't think it's a big problem for new
applications. there are several textual substitution algorithms (storer's term), lzw (aka lz78)
and lzss (aka lz77) are only the two most well-known.
once i needed a image compression scheme for a game. first i thought
of using some known format, like gif. 'why reinvent the wheel', you know.
but then i thought a while and said:
lzw needs about 10..20kb of memory.
lzss needs 300 bytes of memory for decompression and 1kb..x mb
for compression (megabytes are for speed; if you don't need speed, take
only 1kb).
lzss is faster for both decompression and compression.
i chose lzss, obviously, and have been happy with it since then. the
compression ratios for these game images were slightly better than these
of gif, but that was probably because with custom-coded algorithm, i had
the opportunity to tweak compression parameters (codebook size etc.) for
each image.
by the way, _any_ of the textual substitution algorithms would
take 20 lines to describe in the tiff-spec manner. the actual code would
still be 300..1000 lines of c.
ah...@win.goodwin.ee
--
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Launchpad is an experimental internet BBS. The views of its users do not
necessarily represent those of UNC-Chapel Hill, OIT, or the SysOps.
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Keith Stone
cei...@ins.infonet.net (Charles Eicher) wrote:
>
> This is a joke, right? What does Unisys have to do with GIF?
Compuserve used the LZW compression algorithm, patented by Unisys, in the
GIF format. Compuserve was not aware it was patented until Unisys found
out it was used and notified them.
--
--------- Keith Stone | Voice: (910) 777-0511
|\\\ ///| Crewstone Consulting ltd. | FAX: (910) 777-1191
|/// \\\| 1001 South Marshall Suite 118 | "Welcome to the Jurassic;
--------- Winston-Salem, NC 27101 | less talk, more rock"
Keith Stone
(Paul Schmidt) wrote:
>
> I'd like to note, Tom, that a patent holder must show a nominal level of
> effort to defend a patent in order to win a suit. If Unisys is on
> record stating that they will not pursue infringements of this patent
> for software for seven years, then I'd say their patent is pretty dead.
> Of course, I'm no attorney, but given the sequence of events, I'd be
> amazed if this goes through to fruition for Unisys.
I've never seen a reference to Unisys not enforcing the patent in
software. They've been activity enforced KNOWN implementations. I've even
seen references in texts (the Data Compression Book comes to mind) stating
it was a patented algorithm.
> It's also interesting to note that Unisys just layed off 4000 employees
> and filed for bankruptcy. They're still a very large organization, but
> they are also the combination of two earlier failing giants: Sperry and
> Burroughs.
They are laying off employees, but them filing for backruptcy is patently
false. That stupid bankruptcy/going out of business rumor has been going
around since the merger, and is nothing but hogwash. Anyone realize that
Unisys is the only major manufactorer of large scale systems that had been
PROFITABLE the last two years? This is during a time DEC and IBM were
posting LOSSES!
Keith Stone
pa...@casper.med.uth.tmc.edu (Cameron Payne) wrote:
>
> >AGREEMENT FOR USE OF GRAPHICS INTERCHANGE FORMAT(SM)
>
> [text deleted]
>
> Hold a second. If this is the official agreement, how come Unisys is
> mis-spelled throughout the document as Unysis?
The agreement is between Compuserve is it's liciencees. Unisys was not
made aware of the licience (including the misspelling) before it was sent
to Compuserve's developers.
From internal Unisys sources I have found out this much so far:
Yes, there is a licensing agreement between CIS and Unisys, no it isn't
about GIF.
Unisys has been protecting its patent on the LZW algorithm through
negotiations with commercial users who have mistakenly believed that
LZW was in the public domain. CIS was one of those companies that
was using LZW without a license from Unisys. At the request of CIS
Unisys agreed to allow CIS to sub-license the LZW algorithm to
developers who wished to license the GIF spec. Unisys will get
a royalty on those sub-licenses but only due to the inclusion of
LZW in GIF. The amount of the royalty is not being released.
The announcement made by CIS and the contract text (with the misspelled
"Unysis") was not presented to Unisys prior to release by CIS.
Unisys is preparing a press release response but it has not yet
been approved for release.
As Unisys understands the text that CIS has published only those who
wish to develop commercial, for-profit applications using GIF are
affected. CIS is not creating a fee for end users of GIF or for creating
GIF files, only a licensing fee for including GIF in a program.
Keith Stone
> Patents can kill standards. This is one that's not really worth saving
> anyway.
I wouldn't say that. The V.42bis standard is built on the SAME LZW
algorithm is dispute here. Modem vendors pay a licience fee to Unisys to
use the technology.
Keith Stone
> >It's also interesting to note that Unisys just layed off 4000 employees
> >and filed for bankruptcy. They're still a very large organization, but
> >they are also the combination of two earlier failing giants: Sperry and
> >Burroughs.
>
It's about time that this bankruptcy hooey is put to death. Unisys has
been profitable for the past two years, something DEC and IBM can't claim.
Laying off people doesn't mean you're going bankrupt, it can also mean it
doesn't take as many people to manufacture modern computers.
Keith Stone
he...@seviche.med.yale.edu (Matthew D. Healy) wrote:
>
> Uhh, WHAT unisys product? Two dying dinosaurs mated to form
> UNISYS, which is now almost dead precisely because so few people
> buy their products today.
The old dying dinosaur myth, how quaint. Not only are they nowhere close
to dead, they are profitable. The next Unix system you buy may be using
their multi-processor technology.
Keith Stone
<b...@iisnw.iis.nsk.su> wrote:
> Do CompuServe/Unisys suggest me to ask Autodesk and Microsoft to
> remove GIF maintaining facilities from their products and replace
> my copies with newest LEGAL ones?
No, Unisys suggests that the developers of that packages you mentioned
that don't already have a licience for LZW (many already do) get one. You
need do nothing.
NOEL_GIFFIN
>In article <paul.russell...@daytonoh.ncr.com>,
>paul.r...@daytonoh.ncr.com (Paul G. Russell) wrote:
>
>> 2. To Unisys, for waiting so long to bring the patent infringement to
>light.
>> (Don't tell me no one at Unisys knew LZW was being used by CompuServe!).
>
>It's completely believable. How many people, until this flap came up, even
>knew LZW was being using in GIF format? If Compuserve didn't notify
>Unisys, how were they supposed to find out except by accident?
>
If you believe that Unisys wasn't aware that GIF used LZW for compression
then you are either very gullible or are being paid to believe it. Your
volumes of protest in Unisys's defence leads me to believe the latter.
I have known about LZW in GIF for at least 4 years and I'm not even
particularly interested in graphics compression formats. It was no secret.
Compuserve made the spec for GIF freely available to anyone who wanted it
in order to proliferate the standard. I was even vaguely aware of some
possible conflict by reading about gzip and the choice for jpeg. Many
people I'm sure were aware of the problem. They just assumed as I did
that if noone was acting on it then it must be defacto in the public domain.
At least as far as software implemetations go.
If you really think that a company the size of Unisys had no one who was aware
of this until 1993 then I smile at your ingenuous nature. They knew about the
unix compress application and GIF format is far more ubiquitous than that. A
company like that who presumably has an interest in compression, even if only
a monatary one, would have been aware of the problem long before 1993. They
may only have wished to appear ignorant until they were ready to act.
They acted six months ago. Why has it taken so long to hit the street?
Jim Nitchals
you're into such things, read on.
Ahti....@launchpad.unc.edu (ahti heinla) writes:
> lzss needs 300 bytes of memory for decompression and 1kb..x mb
>for compression (megabytes are for speed; if you don't need speed, take
>only 1kb).
> lzss is faster for both decompression and compression.
I like LZSS too.
> i chose lzss, obviously, and have been happy with it since then. the
>compression ratios for these game images were slightly better than these
>of gif, but that was probably because with custom-coded algorithm, i had
>the opportunity to tweak compression parameters (codebook size etc.) for
>each image.
Let's see. I don't know if LZSS per se is patented. But let's look at
a (IMHO obvious) way to improve it. LZSS uses an address displacement
and byte count to identify redundant strings for copying. Short strings
occur more often than larger ones, so what about using smaller bit patterns
for short runs, and larger bit patterns to describe large runs. Likewise,
the further away from the current location a string is, the less likely it
is to be found there. So consider the use of smaller bit patterns to
represent shorter address displacements.
Whoops. If you're using a single bit flag to mark whether the next item
in the compressed stream is a string or an uncompressed byte, you may have
just infringed STAC's patent!
But we're focused on indexed color images. They're two dimensional, so..
why not describe address displacements by their X-Y distance from the current
pixel location, and preferentially assign shorter bit strings to describe
horizontal and near-vertical offsets. This results in a definite win in
efficiency versus LZSS-compressed image data.
BTW, I didn't pursue it because, although it appeared that this method
would yield better efficiency than GIF files, the GIF standard had become
so well accepted that an incremental improvement in design seemed pointless.
Now, obviously, there may be reasons to reconsider that decision.
It seems this encoding scheme is different enough from LZSS, in any case,
to sidestep a slew of patent claims. Neither address displacements nor
hash table entries are encoded; it's a representation of the 2-D distance
to the string being copied. Since I'm not a patent attorney (and don't
even play one on TV!) I strongly encourage anyone with a background in
compression patents to comment on the likelihood that this invention might
be free of infringement, and whether it might be useful in the context of
replacing GIF's compression engine.
If it's free of infringement, should I just patent it myself? I did invent
it before joining my current employer (provably so) but haven't made any
improvements to it since 1991.
This is my first public disclosure of the invention.
Again, all comments/flames are welcome from either technical or legal
perspectives.
[DIATRIBE ALERT]
Those of us who were hacking in the 70's missed a great opportunity.
While we were innovating, we were told the patent office didn't issue
patents on software. We missed out on countless opportunities to patent
XOR cursors, RLE compression, and whatnot. We could ALL be living like
kings because WE FILED FIRST.
- Jim "although the patents would be expiring by now" Nitchals
Disclaimer: I'm only expressing my opinion, and not attempting to
disparage anyone's patent claims, that some of the techniques I
described herein appear "obvious." I'm of this opinion because all
of these techniques seem obvious from first principles to ME, and
I consider myself to be a typical engineer in the art.
--
-----------------------------------------------------------------------------
Jim Nitchals ji...@netcom.com
Trolling the ancient yuletide carol "I DO NOT LIKE green eggs and spam..."
Daniel J Barkalow
>In article <TGL.95Ja...@netcom19.netcom.com>, t...@netcom.com (Tom
>Lane) wrote:
>...
>> If you want to organize a boycott, make sure you are boycotting the
>> right target. Refusing to buy any Unisys product might be a good
>> start. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>Uhh, WHAT unisys product? Two dying dinosaurs mated to form
>UNISYS, which is now almost dead precisely because so few people
>buy their products today.
>I rather suspect that the dire condition of their firm is, in fact,
>their real motivation: they see a means of extracting big bucks
>from the fast-growing online community and perhaps salvage their
>company...I fervently hope the negative public reaction to this
>move becomes the final nail in their coffin.
The only place I've seen the ugly face of UNISYS is my school cafeteria.
If it's the same corp, perhaps we could boycott them, and get some edible
food to boot!
-Daniel
*This .sig left intentionally blank*
Jeff Mercer
: The problem is, who is willing to go to court over it. Patent court
: costs literally millions of dollars per case. It's especially
: expensive when hotly contested over grey areas (software patents are
: still relatively grey). Remember when some company patented using XOR
: to move cursors across a screen? That patent had no merit but the
: slimeballs who held it charged a relatively affordable fee and nobody
: was willing to spend the megabucks in court to shoot it down because
: it was so much cheaper to settle.
That was, if I'm not mistaken, are wonderful friends over at AT&T. Or
Bell Labs. Anyways, it was one of the BIG phone companies.
Pretty much unreal, to me.
: >It's also interesting to note that Unisys just layed off 4000 employees
: >and filed for bankruptcy. They're still a very large organization, but
: >they are also the combination of two earlier failing giants: Sperry and
: >Burroughs.
: This explains a lot. Lawyers get a lot more power in these kinds of
: situations and so things like this are more likly to happen. In the
: case of GIF, and LZW in general, this attitude will kill it in the
: freeware and shareware market which will in turn reduce its appeal to
: the commercial market.
Oh indeed! What this actually reminds me of the most, and is probably
*very* similar to in some ways, is the old Software Enhancement Associate's
vs. Phil Katz case. Basically, SEA made the old ARC/XARC utilities that
started the personal computing world onto the road of data compression.
Phil Katz wrote PKARC and PKXARC, his own version of the utils that were
faster, more efficient, and in general better.
While, the people at SEA, being greedy mother fuckers and incapable of
standing the idea that someone was infringing on their god-given right to
suck the world dry of money, sued Phil Katz for infringement of their
format, plus accusing him of having stolen some of their source code (In
the end, what had happened was that he used the same compression method
they did... Which I believe was LZW. I wonder if SEA ever realized that
their using LZW was the *real*, first infringement?). Phil Katz was just
one guy doing this shit out of his own home initially, and SEA was
(comparitively) much larger. So when it came to the court case, Phil
settled out of court. Part of the agreement he made was to never do any
more work on PKARC or PKXARC, or any other programs that used the SEA's
ARC file format.
Phil then went on to write his PKZIP/PKUNZIP utilities, which blew those
stupid assholes at SEA right out of the market. Largely because not only
were his utilties better, but because VAST NUMBERS OF USERS decided they
didn't like the attitude SEA took (Including bullshit like trying to
claim the .ARC file extension as a trademark and telling people they'd
have to pay SEA fees for any utilities that so much as had the *ability*
to read the ARC file format), and showed their dislike by dropping
ARC/XARC and picking up the ZIP standard instead, SEA ended up loosing
the battle in the long run. Now Phil Katz is in the green, he's made a
wonderful set of utilities, and is very generous in his allowing any
developer support his file-format, witout ANY fees.
I'm surprised the idiots at CompuServe and UniSys aren't aware of this.
What this has done has signed the death warrant for the GIF format in
terms of usage. While end-users would never have to pay fees, and
developers who write programs that only view GIF images won't need to
worry about licenses (supposedly), all of the authors of programs that
write to the GIF format, from public domain to shareware to commercial
applications will not have to face massive legal and financial headaches.
Most of the smaller guys will probably say "Fuck it!" to the GIF
standard, which is already 5 years old at its most recent update. And I
suspect at least some of the big commercial companies will go "Um, yeah.
See you in court guys!" at this proposal.
I think Steve Mikes has hit the nail on the head. While we can't be sure
what's going on in the heads of the lawyers and CEO's of CompuServe and
UniSys, I suspect strongly that they're out to make a buck and
simultaneously try and kill something they see as competition: The Net.
FUCK OFF COMPUSERVE!
The 'net was here before you assholes were even born.
: Killing lawyers in wholesale fashion keeps on seeming more and more
: necessary to the health of society.
Indeed. That, or outlawing private practice again.
--
####################==============---- ----==============####################
# afn0...@freenet.ufl.edu - Jeff The Riffer - Drifter... - Homo Postmortemus #
# CLERKS - Just Because We Serve You, Doesn't Mean We Like You. #
# Disclaimer: I am not a number, I am a free man, and my thoughts are my own. #
Jeff Mercer
Subject: Re: PROTEST OF NEW COMPUSERVE-UNISYS GIF USAGE TAX !!
Newsgroups: comp.graphics
In article <kstone-0501...@kstone.crewstone.com> you wrote:
: In article <healy-040...@pudding.med.yale.edu>,
: he...@seviche.med.yale.edu (Matthew D. Healy) wrote:
: > Uhh, WHAT unisys product? Two dying dinosaurs mated to form
: > UNISYS, which is now almost dead precisely because so few people
: > buy their products today.
: The old dying dinosaur myth, how quaint. Not only are they nowhere close
: to dead, they are profitable. The next Unix system you buy may be using
: their multi-processor technology.
Say Keith, I don't want to sound like a jerk here, but why the hell are
you spending so much time defending UniSys?
Are you working for them by any chance, or have a friend who does?
I understand wanting to correct a lot of mis-conceptions floating around,
but you needn't be so obnoxious about touting UniSys's achievements in
every response you make... That's not the issue here, and it's hardly
on-topic (to the thread *or* to the newsgroup)
Jay Farrell
Maybe the right person to ask would be James Unruh: unr...@po2.bb.unisys.com.
He is the CEO of UniSaurus.
---------------------------------------------------------------------
UniSaurus -- The Power of Screw (tm)
---------------------------------------------------------------------
Fell Swoop
>You can shout "COMMERCIAL" as loud as you want, but it will not
>become the truth. Shareware and freeware products are also subject
>to licensing, and since there is no telling how many copies of
>these would be distributed, they are simply forbidden to support
>GIF.
Shareware, yes, freeware no. Check the Unisys press release.
(Don't get me wrong, I think the whole thing sucks and will be sending letters
to Adobe, FD, Corel, Inset, et al to urge them to not pay up and support a
"faux-GIF" instead. You got the facts crooked, though.)
Never coming, really (sob!): The World Wide Web Jack Chick Archive!
Send comments/contributions to v...@teleport.com or
dej...@athmail1.causeway.qub.ac.uk.
<a href="mailto:dej...@athmail1.causeway.qub.ac.uk">..</a>
Although they'll just be wasted because it's never really coming...
Hi, Canter & Siegel !
Keith Stone
afn0...@usenet.freenet.ufl.edu (Jeff Mercer) wrote:
> Say Keith, I don't want to sound like a jerk here, but why the hell are
> you spending so much time defending UniSys?
Go ahead, I do it many times myself. :-)
I'm actually trying to keep the discusion on the core topic, which is that
LZW is patented, and that Unisys owns the patent. Either an alternative to
GIF needs to be developed, or software developers need to licience the
technology from Unisys or Compuserve. End of story.
So I get a bit sarcastic, but reading 50 conspiricy theorys in a row wears
on you.
> Are you working for them by any chance, or have a friend who does?
We've been a vendor in the Unisys market for eight years. Do we have a
vested interest in Unisys? You bet. Are we scum-sucking corporate flaks in
camoflage? Not quite. Actually, some of my friends from UNITE (a Unisys
users group similar to DECUS or SHARE) would find it quite humorus to see
me on the receiving end of arrows aimed at Unisys. I guess after all the
crap I've them over the last 26 conferences, it's only fair. As long as
they don't let it go to their heads. :-)
> I understand wanting to correct a lot of mis-conceptions floating around,
> but you needn't be so obnoxious about touting UniSys's achievements in
> every response you make... That's not the issue here, and it's hardly
> on-topic (to the thread *or* to the newsgroup)
I agree that Unisys' financial health is not germain to the discussion. I
got pissed when someone that obviously hasn't looked at a Unisys financial
statement for a long time claims they're tottering on bankruptcy.
Boycotts, mail-bombing fits, and other tactics aren't productive. Software
(and hardware) vendors licience technology every day. If you don't want to
pay up, you use something else. Simple as that.
--
--------- Keith Stone | Voice: (910) 777-0511
|\\\ ///| Crewstone Consulting ltd. | FAX: (910) 777-1191
|/// \\\| 1001 South Marshall Suite 118 | "Beware of geeks bearing
--------- Winston-Salem, NC 27101 | GIFs"
Paul Schmidt
(Keith Stone) writes:
>
>In article <3eb5oq$a...@ixnews2.ix.netcom.com>, phot...@ix.netcom.com
>(Paul Schmidt) wrote:
>>
[deletia}
>> It's also interesting to note that Unisys just layed off 4000
employees
>> and filed for bankruptcy. They're still a very large organization,
but
>> they are also the combination of two earlier failing giants: Sperry
and
>> Burroughs.
>
>They are laying off employees, but them filing for backruptcy is
patently
>false. That stupid bankruptcy/going out of business rumor has been
going
>around since the merger, and is nothing but hogwash. Anyone realize
that
>Unisys is the only major manufactorer of large scale systems that had
been
>PROFITABLE the last two years? This is during a time DEC and IBM were
>posting LOSSES!
Keith,
You're right, and I received several mail messages about this post,
including one from Unisys, to which I respond publically: Oops! The
source I got that from had heard it from someone else who was supposed
to know....etc. etc. Net result is that it was hearsay, and that's all.
There's a last time for everything, and this is the last time for me
posting any kind of hearsay on the internet.
I publically apologize for any confusion this mis-statement has caused.
Paul Schmidt
Photodex
Keith Stone
Koennecke) wrote:
> Concerning Compuserve GIF and Unisys,
>
> is there actually a real issue? What about the ANARCHY solution
for the problem. There are
> GIF's using up hard disk space on millions of machines,
thousands of copies of GIF related
> software are installed and floating around in netland. The task
of tracking all this down
> and suing everyone for license fees is gigantic and cannot (to
my humble opinion) been
> done.
GEEEEZZZ. Mellow out. The fee only applies to DEVELOPERS OF COMMERCIAL
SOFTWARE. Nothing was mentioned anywhere about a "GIF TAX" for every image
or viewer on each users hard disk. Too many Oliver Stone followers on the
net.
--
--------- Keith Stone | Voice: (910) 777-0511
|\\\ ///| Crewstone Consulting ltd. | FAX: (910) 777-1191
Nicholas C. Weaver
Keith Stone <kst...@crewstone.com> wrote:
>GEEEEZZZ. Mellow out. The fee only applies to DEVELOPERS OF COMMERCIAL
>SOFTWARE. Nothing was mentioned anywhere about a "GIF TAX" for every image
>or viewer on each users hard disk. Too many Oliver Stone followers on the
>net.
Not just commercial. ALL software which reads/writes/displays GIF
images. Read the liscence agreement. It shond't affect images, but if the
developers of image viewers would follow the agreement to the letter, the
viewers could only be used primarily for CompuServer related stuff. I
predict one of two things.
1) This will be ignored
or
2) Gif will die, and everyone will use JPG instead.
--
Nicholas C. Weaver nwe...@orodruin.cs.berkeley.edu
It is a tale, told by an idiot, full of sound and fury, .signifying nothing
Fun with anagrams: computer science -> coerce inept scum
Brad Templeton
>1) This will be ignored
> or
>2) Gif will die, and everyone will use JPG instead.
GIF might die, but JPEGs are not suitable for line-art and other
non-real photographic images. They are also too slow to display for
some applications. TIFF, with jpeg as a subset of TIFF, is more likely
to be the successor, once a nice non-LZW tiff form is defined.
--
Brad Templeton, publisher, ClariNet Communications Corp. | www.clarinet.com
The net's #1 Electronic newspaper (circulation 80,000) | in...@clarinet.com
Keith Stone
Loureiro) wrote:
>
> You can shout "COMMERCIAL" as loud as you want, but it will not
> become the truth. Shareware and freeware products are also subject
> to licensing, and since there is no telling how many copies of
> these would be distributed, they are simply forbidden to support
> GIF.
The statement by Compuserve and what I've heard so far from Unisys says
nothing about a "GIF hunt". People are making a mountain out of a
molehill. If people don't like the Compuserve agreement, they are free to
contact Unisys directly, as the statement from Compuserve says:
> 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.
The statements about this being an attempt to "Kill the WEB" are vastly
exagerated. It's about time everyone takes a cold shower and look at the
terms in a more realistic light. If you're making money using the
technology, it should be licienced. Developers do that every day. If you
don't want to licience technology, come up with an alternative. Both are
valid tacks, and neither requires mail-bombing fits or boycotts.
--
--------- Keith Stone | Voice: (910) 777-0511
|\\\ ///| Crewstone Consulting ltd. | FAX: (910) 777-1191
Tom Lane
> GIF might die, but JPEGs are not suitable for line-art and other
> non-real photographic images. They are also too slow to display for
> some applications.
Agreed. We still need a losslessly compressed, palette-color
format for icons and line drawings and such. GIF did a fine job
in these areas, and no other format now in common use matches it
(except LZW TIFF, which of course is now out of the question as well).
> TIFF, with jpeg as a subset of TIFF, is more likely
> to be the successor, once a nice non-LZW tiff form is defined.
TIFF is not useful as a format for WWW images, because it is
fundamentally dependent on random access to the whole data file
(so that the program can follow all those pointers).
You want something that can be read and written in a strictly
serial order. Unless you're willing to give up that nice
incremental display capability that everyone likes Netscape so
much for...
I suppose it's conceivable that a subset of TIFF could be defined
in which the file elements were required to appear in an order
that was suitable for serial reading. But this subset would be
TIFF in name only. You can bet that few or no existing TIFF
writers would produce such files without modification.
And that's even before you start worrying about the
incompatibilities and variants that TIFF is notorious for.
TIFF is probably the least standard standard that I know of.
I think a simple serially readable format is a better idea.
Thomas Boutell is busy devising a proposal over in comp.graphics;
you folks reading this in other groups may want to check it out.
Another viable plan is to use the GIF file structure without
modification, but stick in a different compression mechanism ---
probably GZIP. (Boutell's also relying on GZIP as the compression
mechanism of his proposal, so the actual compression effectiveness
will be about the same either way.)
The second plan would make more sense if you want to keep some of
the odder features of GIF, such as the animation possibilities
that GIF89 offers. I'm trying to start a discussion of exactly
which features we need in a GIF-replacement format --- come over
to comp.graphics and join in!
regards, tom lane
organizer, Independent JPEG Group
PS: I'm a member of the TIFF Advisory Committee, so you can't
Keith Stone
afn0...@usenet.freenet.ufl.edu (Jeff Mercer) wrote:
> I'm surprised the idiots at CompuServe and UniSys aren't aware of this.
> What this has done has signed the death warrant for the GIF format in
> terms of usage. While end-users would never have to pay fees, and
> developers who write programs that only view GIF images won't need to
> worry about licenses (supposedly), all of the authors of programs that
> write to the GIF format, from public domain to shareware to commercial
> applications will not have to face massive legal and financial headaches.
> Most of the smaller guys will probably say "Fuck it!" to the GIF
> standard, which is already 5 years old at its most recent update. And I
> suspect at least some of the big commercial companies will go "Um, yeah.
> See you in court guys!" at this proposal.
Some of the big commercial companies have already licienced LZW. I'm
amused that people see a 1.5% royalty as a "massive legal and financial
headache". What's the headache? Sign the form, mail a check. Your $20
shareware program author with 1000 customers owes $300 of his $20000 take.
Software developments pay royalties in one shape or forum every day.
Another format as an alternative to GIF may not be a bad idea, but just
because it hadn't changed in five years doesn't make it bad.
> I think Steve Mikes has hit the nail on the head. While we can't be sure
> what's going on in the heads of the lawyers and CEO's of CompuServe and
> UniSys, I suspect strongly that they're out to make a buck and
> simultaneously try and kill something they see as competition: The Net.
OH NO! Another conspiricy! Big timesharing vendor teams with dinosaur
maker to detroy the NET! Details at 11! OJ seen meeting with space aliens
at Unisys headquarters during secret negociations!
Brad Templeton
Tom Lane <t...@netcom.com> wrote:
>br...@clarinet.com (Brad Templeton) writes:
>> GIF might die, but JPEGs are not suitable for line-art and other
>> non-real photographic images. They are also too slow to display for
>> some applications.
>
>Agreed. We still need a losslessly compressed, palette-color
>format for icons and line drawings and such. GIF did a fine job
>in these areas, and no other format now in common use matches it
>(except LZW TIFF, which of course is now out of the question as well).
>
>fundamentally dependent on random access to the whole data file
>(so that the program can follow all those pointers).
>
format is nicely and portably extensible, and while it should have a
standard palatte mode, GIF had limitations (like 256 colours in the forms
I saw) that obviously should not be repeated.
Also, can't we find something better than compressed run length encoding
as a compression method for our line art and icons?
And might we consider one of the command based formats to generate scaleable
images and icons with line, spline and fill. Of course that does require
too much software smarts, perhaps, but there is a lot to be said for its
portability. It would be nuts to go as far as Postscript or PDF, but there
is a middle ground to look at. NAPLPS even, for all its problems, had some
worthwhile ideas.
If you want to get clever you could even support multiple forms of an image
in the same image, with the web browser able to pull only the one it wants.
For example, if you can handle the postscript you take the postscript, but if
not, a rasterized version might be available for you in some compressed bitmap,
etc.
Leonardo H. Loureiro
>Koennecke) wrote:
>
>> Concerning Compuserve GIF and Unisys,
>>
>> is there actually a real issue? What about the ANARCHY solution
>for the problem. There are
>> GIF's using up hard disk space on millions of machines,
>thousands of copies of GIF related
>> software are installed and floating around in netland. The task
>of tracking all this down
>> and suing everyone for license fees is gigantic and cannot (to
>my humble opinion) been
>> done.
>
>GEEEEZZZ. Mellow out. The fee only applies to DEVELOPERS OF COMMERCIAL
>SOFTWARE. Nothing was mentioned anywhere about a "GIF TAX" for every image
>or viewer on each users hard disk. Too many Oliver Stone followers on the
>net.
>
You can shout "COMMERCIAL" as loud as you want, but it will not
become the truth. Shareware and freeware products are also subject
to licensing, and since there is no telling how many copies of
these would be distributed, they are simply forbidden to support
GIF.
Leo
Kevin M. Porter
: 2. GIF was originally developed using the LZW algorithm which was
: found in the open literature, and which was not know to us to be a
: subject of patent filing at that point. We found this out, to our
: displeasure, after the GIF spec was widely disseminated and used.
: 3. CompuServe at that point found it necessary to take a license to
: the patent. Since a number of our developers had used GIF in good
: faith, we also negotiated a pass through license for their benefit.
: Parts of this license, with a poor interpretation, have been widely
: distributed outside of their original context, which was to
: developers of CompuServe related products alone. GIF is included in
: this license because we are unable to pass through a general license
: to practice LZW.
: 4. It is not the intent of CompuServe to attempt to enforce
: proprietary rights in GIF against users or developers, including
: those of Web technology. As sponsors of CommerceNet and new
: entrants to the Internet access business, we intend to assist in the
: development of the Web, not to sabotage it. We cannot and do not
: speak for Unisys' intent in this matter.
it doesn't seem like compuserve is being realistic if they expect GIF
to survive under these constraints. i don't understand why anyone
would use that format knowing the horrible consequences of putting
the implementation in their code.
Pierre Beyssac
Keith Stone <kst...@crewstone.com> wrote:
>terms in a more realistic light. If you're making money using the
>technology, it should be licienced. Developers do that every day. If you
>don't want to licience technology, come up with an alternative.
Why not license ASCII then ? People make money out of it, after
all.
Sorry, you can't retroactively license a techology.
In commercial terms, I think it would be called dumping.
--
Pierre Beyssac p...@jabba.fdn.org
FreeBSD, NetBSD, Linux -- Il y a moins bien, mais c'est plus cher.
You can also get less bang for more bucks. (translation F. Berjon)
Keith Stone
> Why not license ASCII then ? People make money out of it, after
> all.
Had it not been developed by a committee, I'm sure someone would have
patented it.
> Sorry, you can't retroactively license a techology.
> In commercial terms, I think it would be called dumping.
There is no retroactivity. They got the patent in the 80's before GIF was
created. Other vendors have obtained a licence, Compuserve and GIF
developers didn't. They got caught, now they have to pay up.
Allan N. Hessenflow
>in which the file elements were required to appear in an order
>that was suitable for serial reading. But this subset would be
>TIFF in name only. You can bet that few or no existing TIFF
>writers would produce such files without modification.
That has in fact been done; I forget who, but it's called streaming TIFF (or
something like that). But yes, TIFF is a totally inappropriate format to use
for such purposes.
allan
--
Allan N. Hessenflow all...@handmadesw.com
Howard Wilson
<input on how CI$'s hands are tied and they really don't want to do this
deleted>
Hmmm. You claim you do not support this. Simple. Create a new GIF that
does not use LZW. If you truly support GIF, this would already have been
done, since you have known about it for 6 months. You can't sit there and
cry too much, you know. You have options. Explore them, if you are
serious.
: 4. It is not the intent of CompuServe to attempt to enforce
: proprietary rights in GIF against users or developers, including
Then don't do it. Intent and actions are two different things. I may
add that you will be judged by actions, not intent. If your intent is true,
tell Unisys exactly where to go and what to do when they get there, and
rewrite GIF without LZW.
Howard
--
st...@ionet.net fnord | "And my soul from out that shadow that
I speak for no one but myself, | lies floating on the floor, shall be
and no one else speaks for me. | lifted --- nevermore! - The Raven
Commence strategic maneuvers at audible command signal. 5, 4, 3, 2, 1, begin.
J. S. Greenfield
>> Why not license ASCII then ? People make money out of it, after
>> all.
>
>Had it not been developed by a committee, I'm sure someone would have
>patented it.
I doubt it. It seems highly unlikely that one *could* patent a binary
coding scheme for characters.
Let's remember that the patent involved in the case at hand involves
a compression *algorithm*, not a data format.
>> Sorry, you can't retroactively license a techology.
>> In commercial terms, I think it would be called dumping.
>
>There is no retroactivity. They got the patent in the 80's before GIF was
>created. Other vendors have obtained a licence, Compuserve and GIF
>developers didn't. They got caught, now they have to pay up.
I don't think it's anywhere near this simple. We really need to know a
lot more about the facts of the case(s).
In particular, GIF has been around for quite a while (at least 8 years,
right?). Just what has Unisys been doing to enforce it's patent? There's
been mutterings for a long-time about the LZW patent and the Unix compress
utility, but it's not at all clear to me just what actions Unisys has
undertaken to protect its patent rights. If Unisys failed to take appropriate
action promptly, many developers who relied on that inaction may well have
an implied license to use LZW.
Certainly, it is not clear that Unisys would be able to prevail in an
action against those using LZW for GIF compression and decompression. We
need to see the facts before we could determine that.
As a general principle of law, you cannot simply turn a blind eye to an
infringement of your rights, and then, at a much later time, turn around and
sue to enjoin that infringement and recover damages. You do have to be
reasonably prompt in protecting your rights.
--
J. S. Greenfield gre...@thelair.zynet.com
(So what were you expecting?
A Gorilla?!) "What's the difference between an orange?"
Una Smith
of this topic.
--
Una Smith una....@yale.edu
Dept. of Biology, Yale Univ., New Haven, CT 06520-8104
Rainer Heilke
> Let's remember that the patent involved in the case at hand involves
> a compression *algorithm*, not a data format.
Look at the mess around PGP. As RSA proved, you *can* patent an
algorithm.
> I don't think it's anywhere near this simple. We really need to know a
> lot more about the facts of the case(s).
True.
> As a general principle of law, you cannot simply turn a blind eye to an
> infringement of your rights, and then, at a much later time, turn around and
> sue to enjoin that infringement and recover damages. You do have to be
> reasonably prompt in protecting your rights.
RSA took some time as well, and still won (though it still hasn't
actually gone to court - long story), but I don't think that case
was nearly this long a wait. But, who has the money to fight this in
court against Unisys?
--
Rainer
---
USENET: Rainer...@Cytel.CUEHere.Edmonton.AB.CA
MajorNet: andragon@MLM ...the twisted one...
---
'Cause I'm a 21st Century Digital Boy
I don't know how to live, but I got a lot of toys.
My daddy's a lazy, middle-class intellectual,
My mommy's on valium - so ineffectual.
Bad Religion
s...@ccnet.com
>In article <3ee435$t...@unixfe.rl.ac.uk>, m...@isise.rl.ac.uk (Mark
>Koennecke) wrote:
>
>> Concerning Compuserve GIF and Unisys,
>>
>> is there actually a real issue? What about the ANARCHY solution
>for the problem. There are
>> GIF's using up hard disk space on millions of machines,
>thousands of copies of GIF related
>> software are installed and floating around in netland. The task
>of tracking all this down
>> and suing everyone for license fees is gigantic and cannot (to
>my humble opinion) been
>> done.
>
>GEEEEZZZ. Mellow out. The fee only applies to DEVELOPERS OF COMMERCIAL
>SOFTWARE. Nothing was mentioned anywhere about a "GIF TAX" for every image
>or viewer on each users hard disk. Too many Oliver Stone followers on the
>net.
>
>--
That kind of thinking is what allows the public to get screwed so easily.
We are not just talking about viewers here. Every image processor software/
drawing package that supports GIF must pay, and pay a fixed percentage of
the price, no matter how small a part of it's function the GIF read/write
is.
YOU pay for this in higher prices. The situation is similar to the "tape
theif" case. Now, every time you buy a blank cassette tape, you pay the
music publishers a cut because you are automatically guilty of illegal
copying.
What UniGreed/CompuScrew are doing is arranging to syphon cash out of your
back pocket in a way that they hope will be least noticeable to the general
public. Literally a "hidden charge".
------------------------------------------------------------------------------
| JUST SAY NO -- TO THE GIF (Greed Is Fundamental) FORMAT |
| SEND "STEALTH STANDARDS" BACK TO HELL WHERE THEY CAME FROM |
| |
| SAM is s...@ccnet.com |
------------------------------------------------------------------------------
Lewis A. Sellers
> br...@clarinet.com (Brad Templeton) writes:
> > GIF might die, but JPEGs are not suitable for line-art and other
> > non-real photographic images. They are also too slow to display for
> > some applications.
>
> You want something that can be read and written in a strictly
> serial order. Unless you're willing to give up that nice
> incremental display capability that everyone likes Netscape so
> much for...
GIF is dead?
Well, that's ok. Lot's of people have been wanting to bury it for a
while. :)
I was thinking about this yesterday. It seems what we need is a nice new
(free!) format that can handle 1) raw sequential image (better than that
horrible BMP format) 2) Run-length encoded images (similiar to PCX)
3)&4) and both perhaps the Huffman and Gzip compression formats.
It seems to be two distinct issues about the new Compression Technique
and the new format.
I hacked out some C structures for a possible format. Now, it needs lots
of work, but it's a start. And i'm sure it'll get all kinds of
constructive critisizm from the kind polite folk here on the internet :)
but I sent it up anyway.
Hey, I might even actually explain the nuances of it tomorrow if I get some
sleep. <grin> =)
/*
Example values of a 640x480 24-bit image shown in [] brackets.
*/
// iNTERNET Graphics File Format // iGFX "iGGy-x" :-)
////////////////////////////////////////////////////////////////////////
#include "stdio.h"
typedef unsigned char byte;
typedef unsigned int word; //2 bytes
typedef unsigned long dword; //4 bytes
//HEADER////////////////////////////////////////////////////////////////////
typedef struct {
dword tag; //[iGFX]
dword compliancy; // [ 1]
dword screen_width; // [640]
dword screen_height;// [480]
word bit_depth; // [24] ( shr 3 for bytes per [3])
//bit depth valid only with even numbers
byte pixelcomponents; // [3] (palleted/mapped color=1,rgb=3,cymk=4)
byte componentbitdepth; // [8] bits
byte planes; // [1]
dword compression; //[NONE] no-compression
dword filestructure; //[PMAP] sequentially pixel-mapped
/*
PMAP uncompressed sequentional data (or SEQ? :), pixel-mapped
NONE no special file-structure, just sequential
ILY standard 8-line interlaced on the y
ILXY interlaced 8-line/column (for WWW :)
PLANE uncompressed bit-planed data
NONE
ILY
ILXY
RLE (ie PCX...intermediary compression alg. :)
NONE
HUFF Huffman compression variants
NONE
GZIP :-) :-) :-) :-) :-) :-) :-)
NONE
'0000' or NULL, or 'NULL' is the display termination code.
*/
word n_images; //[1]
dword background_red; //[0]
dword background_green; //[0]
dword background_blue; //[0]
dword background_effect; //[NONE]
struct { //palette,which always follows the header if there is one.
//if==0000 then there is no palette, so use default.
dword bytesize,bytesizehigh; //[0000]
dword n_elements,n_elementshigh; //[0000]
} palette;
struct {
word complexity :1; //[SIMPLE]
word background_color :1; //[TRUE]
word reserved :4;
word signifigance :2; //[0]
word reserved2 :8;
word default_palette :1; // 0= grayscale,1=color palette
} reader_flags;
/*
if SIMPLE then n_images=1,screen_width/height ignored, only one per-image
header and that is a PICT.
*/
struct { //GMT...
word millisecond; //[.000]
byte reserved;
byte second; //[00]
byte minute; //[59]
byte hour; //[11]
byte day; //[05]
byte month; //[01]
word year; //[1995]
} GMT;
char filename[32]; //[The Wars Waged On]
} header;
//PER-IMAGE HEADER/////////////////////////////////////////////////////////
typedef struct {
dword image_id; //[1]
dword component_id; //[1]
/*
Each image in a file has a unique number IMAGE_ID, so if it's
color-seperated,etc you can tell what belongs to what. COMPONENT_ID
is it's sub-number, ordering the seperations.
*/
dword relationship; //[0=NULL]
dword related_to; //[0=NULL]
/*
NONE
ICON standard of n-id, fixed size 96x96
5% 5% scale version of n-id image
10%
25%
MIN
HDTV
NTSC ntsc-sized variant of n-id
PAL
ZOOM enhanced close-up of n-id
etc...
The relationals generally indicate that such and such image is some
kind of modification to the main image in a file. Doesn't have
any real effect...just FYI stuff.
*/
dword xorigin,xoriginhigh; //[0,0]
dword yorigin,yoriginhigh; //[0,0]
dword xwidth,xwidthhigh; //[640,0]
dword yheight,yheighthigh; //[480,0]
dword format_tag; //[PICT]
dword format_subtag; //[NONE]
/*
PICT The following is a picture. :)
NONE
INFO
Asciiz NULL terminated human-readable information types.
Some readers might display these on the image...some might
not. :)
FILE Override of 32-byte machine-name entry.
NAME True name of the image ((not) same as machine name)
AUTH Image Author's full name,address,etc
OA Original author (used if a painting,etc)
SITE The site name from whence image originated
DATE full native date-stamp (creation,modification,etc)
TIME full native time-stamp
CMTS Indepth comments on all images following
CMT Comments upon following image (component) only.
SRC Image source identification (ie the HST,etc :)
LEGL Legal status of image...hopefully public domain. :)
MAIL Where to make contact for more information...
Internet address, po box,etc...
LABL Image label...(optional of course)
OEM
DISC
LIST The list of programs used to generate this image.
Officially, when a program writes an IMAGE file
to disk,etc it should add it's name here (after
checking to make sure it's not already on the list of
course.) Programs are seperated by Newlines.
(or should they add theirselves with a date stamp? :)
DATA additional binary-coded information for the machine
CRED creation date of image(s)
CRET
MODD Last modification date
MODT
IMGD date-stamp of what's IN the image. ('40 car,fr. ex.)
IMGT
'0000' or NULL, or 'NULL' is the display termination code.
(optional, perhaps level 2's follow)
TEXT Text that SHOULD be written to the screen after the images are.
Standard ASCIIZ null-terminated string, using xy positioning
from x/yorigin and pixel size from xwidth/yheight. Useful on
JPL-type images,etc.
NONE generic font-style
ITLC italizied generic font.
BOLD
BTLC bold-italics
FRAM
same as TEXT except that it's framed.
*/
union {
struct {
word color;
} mapped;
struct {
word red :1; //[TRUE]
word green :1; //[TRUE]
word blue :1; //[TRUE]
word reserved :13;
} rgb;
struct {
word cyan :1;
word magenta :1;
word yellow :1;
word black :1;
word reserved :12;
} cmyb;
} seperation;
dword imagesize,imagesizehigh,imagesizehigher,imagesizehighest; //[921600]
//original uncompressed size of image.
dword compressedsize,compressedsizehigh,compressedsizehigher,compressedsizehig
//size of image IN THE FILE, after compression, if any.
dword compression_ratio; //[00.00] 16.16 fixed-point value (0=none)
dword n_value; //reserved value space for JPEG,etc variable compression settin
//[0000]
dword alg_table_size; //[0000]
} per_image_header;
main()
{
printf("Structure Valid!\n");
return 0;
}
later,
minimalist Note: Expect occasional delays of up to a
lsel...@brbbs.com week for email due to time constraints.
dreamthecrowblackdream Afterwards: remail to remind =)
David Carr
>
>Let's see. I don't know if LZSS per se is patented. But let's look at
James Storer (one of the S's in LZSS) confirmed it's not patented.
>Whoops. If you're using a single bit flag to mark whether the next item
>in the compressed stream is a string or an uncompressed byte, you may have
>just infringed STAC's patent!
Nope, IBM had that patent, but it has expired. It's also avoided in gzip.
--
Dave Carr | dc...@newbridge.com | It's what you learn,
Software Designer | TEL (613) 591-3600 | after you know it all,
Newbridge Networks | FAX (613) 599-3619 | that counts.
ahti heinla
>the further away from the current location a string is, the less likely it
>is to be found there. So consider the use of smaller bit patterns to
>represent shorter address displacements.
btw, i forgot to mention i did exactly this in a very simple
manner in the custom-coded compressor i was talking about.
>But we're focused on indexed color images. They're two dimensional, so..
>why not describe address displacements by their X-Y distance from the current
>pixel location, and preferentially assign shorter bit strings to describe
>horizontal and near-vertical offsets. This results in a definite win in
>efficiency versus LZSS-compressed image data.
another possibility is to describe the X-Y displacement with a
single value indicating the distance in image along a space-fitting curve,
like hilbert curve. ok, this is more tricky, i admit.
ahti
--
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Launchpad is an experimental internet BBS. The views of its users do not
necessarily represent those of UNC-Chapel Hill, OIT, or the SysOps.
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Fell Swoop
>Bill Davidson (bi...@cray.com) wrote:
>: The problem is, who is willing to go to court over it. Patent court
>: costs literally millions of dollars per case. It's especially
>: expensive when hotly contested over grey areas (software patents are
>: still relatively grey). Remember when some company patented using XOR
>: to move cursors across a screen? That patent had no merit but the
>: slimeballs who held it charged a relatively affordable fee and nobody
>: was willing to spend the megabucks in court to shoot it down because
>: it was so much cheaper to settle.
>That was, if I'm not mistaken, are wonderful friends over at AT&T. Or
>Bell Labs. Anyways, it was one of the BIG phone companies.
>Pretty much unreal, to me.
For that matter, does anybody remember that company that tried to claim that
they invented the GUI, and sue anybody who implemented one? Hey, what
happened to Macs, anyway?
Bill Davidson
>LZW is patented, and that Unisys owns the patent.
Correction. They own a patent; not the patent. LZW is patented twice
and the wording is similar in both patents. LZW is patented by IBM as
well as Unisys. IBM also filed for the patent before Unisys did which
means that if it ever went to court, Unisys' patent could be declared
invalid on the grounds that the algorithm is covered by a previous
patent by another company.
--Bill Davidson
Hannu Niemi
Ks> In article <3ek01v$6...@jabba.fdn.org>, p...@jabba.fdn.org (Pierre
Ks> Beyssac) wrote:
> Why not license ASCII then ? People make money out of it, after
> all.
Ks> Had it not been developed by a committee, I'm sure someone would have
Ks> patented it.
Yeah, and it wouldn't be any standard today. (Not that it even now is strictly
standard, different code pages and so on...). What I think we are facing with
these software patents is something that blocks the 'openness'. We all win
with standardization in the long term - even if writing all kind of translator
programs would actually be 'cheap'money to the developer. And trust me, I know
what I am talking about after living and developing in the fascinating land of
Geographical Information Systems.
Happily the world is going to saner direction (generally spaking). Btw first
time there is a real benefit that is caused by a committee ;-)
___________________________________________________________________________
Hannu Niemi (hannu...@pcb.compart.fi)
Guilty of writing Windows soft... oops software for Microsoft(R) Windows(TM)
...It always pays to set your goal high - if you try to earn billion dollars
you earn million if you only achieve one per mille of your goal
___ Blue Wave/QWK v2.12
Nathan Mehl
: 1) This will be ignored
: or
: 2) Gif will die, and everyone will use JPG instead.
And if #2 comes to pass, remind me to write a BIG THANK-YOU letter
to Compuserve and Unisys for finally killing off a truly bad image
transport format, and freeing up a hell of a lot of bandwidth on
the net in the process. (Anyone want to calculate how much less
space the alt.binaries.pictures.* groups would take if all GIFs
were posted as high-compression JPEGs instead?)
--
-------------{http://ccat.sas.upenn.edu/nmehl/home.html}---------------
|Didn't the book of Revelations say something about a plague of Newts?|
----{Nathan J. Mehl}-------------------{nat...@bwh.harvard.edu}--------
Nathan Mehl
: >> Why not license ASCII then ? People make money out of it, after
: >> all.
: >Had it not been developed by a committee, I'm sure someone would have
: >patented it.
: I doubt it. It seems highly unlikely that one *could* patent a binary
: coding scheme for characters.
: Let's remember that the patent involved in the case at hand involves
: a compression *algorithm*, not a data format.
...and algorithms are allegedly not patentable in the first place, although
the U.S. Patent Office seems to have decided to ignore that little fact
for the last couple of years...
Matt Austern
> I doubt it. It seems highly unlikely that one *could* patent a binary
> coding scheme for characters.
>
> Let's remember that the patent involved in the case at hand involves
> a compression *algorithm*, not a data format.
Data formats have been patented. There was a big stir on
comp.lang.c++ six months or so ago when someone posted the text of a
patent that had been awarded to Microsoft; it was a variation on a way
of laying out some of the internal information used in implementing a
C++ class.
The distinction between a data structure and an algorithm isn't always
terribly clear; I don't think that the Microsoft patent is particularly
more outrageous than any other software patent. If an algorithm can
be patentable, then why shouldn't a data structure be?
--
--matt
J. S. Greenfield
>...and algorithms are allegedly not patentable in the first place, although
>the U.S. Patent Office seems to have decided to ignore that little fact
>for the last couple of years...
Just how did you reach this conclusion?
The case law on patent is pretty clear. You cannot patent the mere
computation of a mathematical formula. However, you *can* patent a computation
used for a particular *application*.
For example, you cannot patent modular exponentiation; however, you can
patent modular exponentiation for use as an encryption tool. (To give a
simplified description of RSA.)
(Incidentally, were you under the impression that RSA was patented in the
last few years? How about LZW? When do you think that was patented?)
J. S. Greenfield
>Data formats have been patented. There was a big stir on
>comp.lang.c++ six months or so ago when someone posted the text of a
>patent that had been awarded to Microsoft; it was a variation on a way
>of laying out some of the internal information used in implementing a
>C++ class.
Do you have the details on this particular a case. I can't comment on the
relation between this and my comments without knowing the specifics of the
particular patent you cite.
(And, in case it wasn't perfectly clear from my other posts, I make no
claims that patent examiners are perfect when it comes to granting patents.
In fact, I claim quite the opposite, particularly in the area of algorithms.)
>The distinction between a data structure and an algorithm isn't always
>terribly clear; I don't think that the Microsoft patent is particularly
>more outrageous than any other software patent. If an algorithm can
>be patentable, then why shouldn't a data structure be?
A better question is if physical processes are patentable, then why shouldn't
algorithms be?
Taking the position that algorithms should *not* be eligible for patent
protection leads to the rather strange conclusion that a hardware
implementation of an algorithm (which is, of course, a physical process, which
has been elgible for patent protection as long as circuits have been around)
is elgible for patent protection, while a software implementation of the
same algorithm is not.
This inconsistency would appear to be irreconciliable.
Richard Robinson
> They acted six months ago. Why has it taken so long to hit the street?
Well, because they let Compuserve catch the flak from telling us.
-------------------------------------------------------------
Richard Robinson, Leeds, UK ric...@beulah.demon.co.uk
"The whole plan hinged upon the natural curiosity of potatoes" - S. Lem
Mike Meyer
> If you believe that Unisys wasn't aware that GIF used LZW for compression
> then you are either very gullible or are being paid to believe it. Your
> volumes of protest in Unisys's defence leads me to believe the latter.
> I have known about LZW in GIF for at least 4 years and I'm not even
> particularly interested in graphics compression formats. It was no secret.
I guess I must be gullible, because I believe them. Then again, I
didn't know GIF uses LZW, and I view & create GIF images on a regular
basis.
On the other had, if you believe Compuserve didn't know LZW was
patented before Unisys told them about it, you are either very
gullible or being paid to believe it. I have know that LZW was
patented for years, and I'm not even particularly interested in
compression. It was no secret.
<mike
Barry Margolin
>On the other had, if you believe Compuserve didn't know LZW was
>patented before Unisys told them about it, you are either very
>gullible or being paid to believe it. I have know that LZW was
>patented for years, and I'm not even particularly interested in
>compression. It was no secret.
However, for some time Unisys has claimed that they were only planning on
demanding licensing from vendors of hardware implementations
(e.g. compressing modems), so Compuserve could easily have expected that
GIF would not be a problem (more paranoid software developers, like the
Free Software Foundation, didn't have such expectations, and developed
their own compression software). Unisys went back on that claim when they
went after Compuserve regarding GIF.
--
Barry Margolin
BBN Internet Services Corp.
bar...@near.net
Kenneth Lerman
...
Some quick comments:
: /*
: Example values of a 640x480 24-bit image shown in [] brackets.
: */
I suggest you limit your format description to ANSI C
: // iNTERNET Graphics File Format // iGFX "iGGy-x" :-)
: ////////////////////////////////////////////////////////////////////////
Lines starting with // are NOT comments in (ANSI) C.
: #include "stdio.h"
: typedef unsigned char byte;
: typedef unsigned int word; //2 bytes
An integer is NOT 2 bytes in ANSI C
: typedef unsigned long dword; //4 bytes
And a long is NOT 4 bytes.
Furthermore, there is NO standard for byte ordering within an integer
or long.
: //HEADER////////////////////////////////////////////////////////////////////
: word n_images; //[1]
The arrangement of bits of bitfields within a word is not specified by
ANSI.
: } reader_flags;
: /*
: if SIMPLE then n_images=1,screen_width/height ignored, only one per-image
: header and that is a PICT.
: */
: struct { //GMT...
: word millisecond; //[.000]
: byte reserved;
: byte second; //[00]
: byte minute; //[59]
: byte hour; //[11]
: byte day; //[05]
: byte month; //[01]
: word year; //[1995]
: } GMT;
: char filename[32]; //[The Wars Waged On]
: } header;
You get the message. I will not comment on the rest.
Ken
--
Kenneth Lerman ler...@seltd.newnet.com
Systems Essentials Limited (203)426-4430
55 Main Street
Newtown, CT 06470
J. S. Greenfield
>> Let's remember that the patent involved in the case at hand involves
>> a compression *algorithm*, not a data format.
>
>Look at the mess around PGP. As RSA proved, you *can* patent an
>algorithm.
Are you under the impression that I claimed otherwise? If so, you are
mistaken.
>> I don't think it's anywhere near this simple. We really need to know a
>> lot more about the facts of the case(s).
>
>True.
>
>> As a general principle of law, you cannot simply turn a blind eye to an
>> infringement of your rights, and then, at a much later time, turn around and
>> sue to enjoin that infringement and recover damages. You do have to be
>> reasonably prompt in protecting your rights.
>
>RSA took some time as well, and still won (though it still hasn't
>actually gone to court - long story), but I don't think that case
>was nearly this long a wait. But, who has the money to fight this in
>court against Unisys?
That is not my understanding of the PGP case. My understanding is that
PKP has always maintained that Phil Zimmerman, and his successors, were
infringing the RSA patent. As far as I know, they were in contact with
the folks involved from the outset. (I believe that Phil initially looked
into licensing the algorithm via RSA Data Security, Inc., but decided
against it.) A licensed version of PGP was released via Viacrypt, and after
years of *pursuing* the matter, PKP and MIT finally came to agreement on
a licensed version of the freeware PGP. (PGP required no license outside
of the US, of course, since RSA is patented only within the US.)
In short, Phil Zimmerman and those later involved in PGP were never left to
believe that PKP was ignoring the infringement, so they never had any
reasonable reliance on such. Taking action to police a patent does not
ncessarily require a lawsuit. Other actions, such as cease and desist
letters and negotiations also constitute enforcement.
The use of LZW in GIF algorithms seesm to be very different from PGP/RSA
situation. From what I can tell to this point, Unisys turned a blind eye
to the use LZW compression in GIF algorithms for years. That's why I think
there's a good chance that they would be estopped from attempting to
enforce the patent against many GI Falgorithm developers now.
Alan Barrett
ler...@seltd.jvnc.net (Kenneth Lerman) writes:
> Furthermore, there is NO standard for byte ordering within an integer
> or long.
There is one that is commonly called "network byte order", and that is
used by most Internet protocols that use binary coded integers. See
Appendix B of RFC 791.
--apb (Alan Barrett)
Mike Schenk
>In article <3ek01v$6...@jabba.fdn.org>, p...@jabba.fdn.org (Pierre Beyssac) wrote:
>
>> Why not license ASCII then ? People make money out of it, after
>> all.
>
>Had it not been developed by a committee, I'm sure someone would have
>patented it.
The fact that something is developed by a committee, does not mean that
it cannot be patented. Lots of things are developed by standardization
committees and are still patented.
>> Sorry, you can't retroactively license a techology.
>> In commercial terms, I think it would be called dumping.
>
>There is no retroactivity. They got the patent in the 80's before GIF was
>created. Other vendors have obtained a licence, Compuserve and GIF
>developers didn't. They got caught, now they have to pay up.
They got caught, but they got caught many years ago. I don't know about
the US, but in lots of jurisdictions, allowing Compuserve and GIF
developers to continue using the patented algorithm means that Unisys
lost the right to a licensing fee.
Mike
Christopher Biggs
>> There is no retroactivity. They got the patent in the 80's before GIF was
>> created. Other vendors have obtained a licence, Compuserve and GIF
>> developers didn't. They got caught, now they have to pay up.
> They got caught, but they got caught many years ago. I don't know about
> the US, but in lots of jurisdictions, allowing Compuserve and GIF
> developers to continue using the patented algorithm means that Unisys
> lost the right to a licensing fee.
I think you'll find that Unisys acted on the compuserve matter a few
months before the deadline to contest the patent. If they'd waited a
little longer, they would have lost the right to enforce it.
cjb
--
Christopher J Biggs |_ch...@stallion.oz.au |_Vice-Pope torture and marketing
Stallion Technologies | Brisbane, Australia | Holy Church of Givashitology
nordfordfnrdfnodfnorfnordnordfordfnrdfnodfnorfnordnordfordfnrdfnodfnorfnordn