The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 16 Issue 69

Tuesday 3 January 1995


o Gov't Recommends Electronic Copyright Restrictions
o One for the GIFfer (CompuServe-Unisys GIF Tax Protest)
Pat Clawson
o Mail repeatedly returned to sender
Curtis Keller
o Dates in a 4GL
name removed
o Dates and Times Not Matching in COBOL
Fred Ballard
o Testing and the Sources of Dates and Times
Fred Ballard
o Dates in "Ancient" Systems
Fred Ballard
o COBOL's Two-Character Year Field
Fred Ballard
o Last call for papers for COMPASS 95
John Rushby
o Info on RISKS (comp.risks)

Gov't Recommends Electronic Copyright Restrictions (Edupage)

"Peter G. Neumann" <>
Tue, 3 Jan 95 14:12:52 PST
From Edupage, 27 Dec 1994:

The draft report on copyright law issued last July is drawing fire from
some academics and librarians, who say it gives copyright holders too much
power and "ought to maintain the balance that is maintained in the print
world," according to a law professor who moderates an Internet forum on
copyright law. One particular sticking point is U.S. Patent & Trademark
Office Commissioner Lehman's opposition to allowing libraries to ship books
electronically to patrons, because an extra copy would show up in each
recipient's computer. "To me, the burden on those who would say that ought
to be a fair use is extraordinarily high. You would see massive dislocation
of the market for that work," says Lehman. The draft report was used to
represent the U.S. position in recent meetings of the World Intellectual
Property Organization, and Lehman says a basically unaltered final report
will be ready in the spring. (Wall Street Journal 12/27/94 B5)

  [To subscribe to Edupage: send a message to: and in
  the BODY of the message type: subscribe edupage YourName (assuming that
  your name is YourName; if it isn't, substitute your own name) ... To
  cancel subscription to Edupage: send a message to: and
  in the BODY of the message type: unsubscribe edupage.]

One for the GIFfer (CompuServe-Unisys GIF Tax Protest, Pat Clawson)

"Peter G. Neumann" <>
Tue, 3 Jan 95 13:27:49 PST
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 [1995] 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

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
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 unenforceable, 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

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 Communications 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

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
convenience 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.


Pat Clawson
President & Chief Executive Officer
TeleGrafix Communications Inc.
Huntington Beach, CA

Voice: (714) 379-2140
Fax: (714) 379-2132
BBS: (714) 379-2133

Mail repeatedly returned to sender

Curtis Keller <curtis@Starbase.NeoSoft.COM>
Mon, 2 Jan 1995 22:05:11 -0600
 "You are invited to discover Wired magazine - free"

 I received a pretty snazzy advertisement for Wired magazine 2 weeks
 ago and I decided to order the "free sample copy".  I have placed the
 postage paid reply card in the mail 3 times,  and 3 times a day or so
 later the same reply card has returned.  It turns out that the reply
 card has my name and address on the flip side in the same position
 as the address of Wired magazine on the "correct side."   Additionally
 the postal service 5+4 bar coding is on both sides of the card - once
 for Wired magazine and once for "me".  I'll toss it in the mail once again.

Curtis Keller 713-953-8309

Dates in a 4GL

<[Name removed at submitter's request]>
Tue, 3 Jan 95 12:12:12 XST
I am currently using a fourth-generation language called NOMAD2.  NOMAD2
stores dates internally as the number of milliseconds since a date in the
1580s when the Gregorian calendar was first put into use.  At least the
version of NOMAD2 that I use does (1).

For the most part, this seems to work out very well.  Much of the fears
about what happens with computer-stored dates on January 1, 2000 are
groundless for NOMAD2.  But perhaps not all of them.  Using an appropriate
date data type may have led to a false sense of security.

Most years are entered in the application system I'm working with as two
digits.  NOMAD2 allows this and effectively adds 1900 to years entered as
two-digit years.  When the system date changes to 2000, I'm not sure whether
NOMAD2 will start adding 2000 to the years entered.  (There may even be a
system variable for setting this.)  Regardless, on 1-Jan-200, it will still
not be appropriate to add 2000 to years from the now previous century or
1900 to years from the now current century.  Any arbitrary scheme to treat,
say, the entered years 30 through 99 as 1930 through 1999 and 00 through 29
as 2000 through 2029 would lead to problems (2) since the system I'm working
with could involve birthdates of 1929 and before.

Since the department I am working in has chosen to stay with the current
version of NOMAD2 (1), any new schemes for handling this problem may be lost
to my application.  The whole topic of staying with a stable release of a
system and not getting improvements or fixes to existing errors versus going
to new releases that have improvements, may fix existing faults, but may
introduce new ones is a rich risk management topic.


1.  A new application system in another operating environment is replacing
the one I am maintaining.  As a consequence, no further upgrades are being
planned for NOMAD2 in our operating environment.  The vendor of NOMAD2
continues to make upgrades.  The vendor's most release dealt with a date
problem from one its clients.  The client was storing uninitialized dates on
its DB2 database as something like January 1 of the year 0 which DB2's date
data type allows.  NOMAD2 can map DB2 databases, but its date data type did
not allow dates before the introduction of the Gregorian calendar.  (I
assume they haven't had any clients who wanted to store archaeological
data.)  The client was stubborn and the new release of NOMAD2 contains a fix
for the problem.  I'm not aware of the implementation details.

2.  As Brian Hayes noted in "Waiting for 01-01-00" on p. 14 of
January-February 1995's _American Scientist_.

Dates and Times Not Matching in COBOL

Fred Ballard <>
01 Jan 95 21:31:03 EST
There is no way to obtain the system date and time in one statement in
COBOL.  A program could get the date just before midnight and then get the
time relative to the day after the date it got.  A timestamp of 31-Dec-1994
00:00:01 indicates just after midnight between 30-Dec-1994 and 31-Dec-1994,
but it could have been obtained from a COBOL program running around midnight
between 31-Dec-1994 and 1-Jan-1995.

The only way in a COBOL program to assure that the time obtained is for the
date obtained is to loop getting the date, then the time, and then the date
again until both dates match (as would usually be the case).

No one knows how often such a check is performed in existing COBOL code, but
I would guess it is very rare.  No one knows how likely such an error would
occur or what consequences it might have.  But it certainly is not
desirable.  (It's a little like the Pentium FDIV bug.)

I haven't heard of any problems actually caused by this, but the potential
risk is there as it is in any language that makes accessing the date and
time simultaneously impossible.  (I believe BASIC shares this problem with

Testing and the Sources of Dates and Times

Fred Ballard <>
01 Jan 95 21:31:02 EST
Application software typically draws the current date and time directly from
the system.  Not using data hiding, that is, drawing the current time from
another application module, may cause problems with testing and could lead
to faults due to the difficulty of testing if it is not possible to change
the system date and time during a test.

A realtime financial application may want to close the books for the now
previous day when the time goes past midnight.  I've heard of such an
application and the developers did not use data hiding.  As a result they
had to run their tests when the system (and actual) time changed to
midnight.  Therefore, only one test could be run each night and in this case
they had to rearrange their normal 8-5 working hours to center around
midnight.  Introduction of changes and fixes were more easily introduced
when the programs were modified to access the "current" date and time
through a common module that could shift the time during a test.

However, as with most things, the tradeoff of using data hiding instead of
directly accessing the system date and time opens up the potential risk of
accidentally using test times in a production environment.  (This risk might
still be present if a test was allowed to alter the system date and time
thereby moving data hiding to another level.)

Dates in "Ancient" Systems

Fred Ballard <>
01 Jan 95 21:30:55 EST
In a few IBM 1401-based programs at the insurance company I was working at
in the late 1960s, the year was stored as a one-character field!
Fortunately the problem of going from 1969 to 1970 in these programs was
recognized in time, the programs were few in number and modest in size (our
1401s had a maximum main memory of 8K), and the programs were corrected in

COBOL's Two-Character Year Field

Fred Ballard <>
01 Jan 95 21:30:57 EST
Stating the fact that COBOL has a default date format used in its
special-registers bypasses the fact that COBOL has no date data type for the
storing of fates (Freudian-slip, make that dates).

This has left the coders of the billions of lines of existing COBOL code
free to invent as many date formats as human creativity will allow.  In my
reading, use, and maintaining of COBOL code in over twenty-six years of
information system programming, this is a surprisingly large number.

This is one of the reasons "dusty deck" COBOL systems are such a problem as
the year 2000 draws near.  No assumptions can be made as to how dates are
stored in COBOL-based systems and files.  Also, the manipulation of a given
format varies from one COBOL program to the next.  There is no guarantee
that any installation-wide modules are used for date manipulation.
(Installation-wide is pretty much the best you can hope for; COBOL itself
has no date manipulating modules.)

Actually, there is no guarantee that date routines will even be concentrated
and re-used within a given COBOL program.  Date processing is often
scattered throughout the program, with each date variable having not only
its own unique processing but different code for the same operations on a
given date at different points in a program.

Obviously, some of this date code may contain errors.  In many cases the
errors are compensated for, consciously or unconsciously, by the program's
developers or maintainers.  So correcting a date computation at one point
may lead to an error because the next use of the date has an existing
correction for the previous error.

   [Thanks to Fred, who also pointed out an error on Page 88 of my RISKS
   book, which should have read "COBOL uses a two-character YEAR field"
   (instead of DATE).  Sorry!  PGN]

Last call for papers for COMPASS 95

John Rushby <>
Fri 30 Dec 94 12:08:49-PST
Typeset copies of the CFP are available via anonymous ftp from
in /pub/compass95-cfp.{txt|tex|dvi|ps} and /pub/compass95-cfp-a4.{dvi|ps}
or via WWW from .

               CALL FOR PAPERS
                             COMPASS '95

10th Annual IEEE Conference                     June 26--30, 1995
on COMPuter ASSurance (COMPASS)                 Gaithersburg, MD USA

Sponsored by IEEE Aerospace and Electronic Systems Society
         and IEEE National Capital Area Council
In cooperation with The British Computer Society

The purpose of this conference is to bring together researchers,
developers, integrators, and evaluators who work on problems related
to specifying, building, and certifying high-assurance,
high-consequence computer systems.  What distinguishes COMPASS from
similar conferences is its emphasis on bridging the gap between
research and practice.  For researchers this provides an opportunity
to present new results, theories, and techniques both to other
researchers, and to practitioners who can put them to use.  They can
also learn from practitioners of issues and problems encountered in
building real systems.  Practitioners have an opportunity to share
lessons learned, to hear of new research, and to influence future
research directions.

The conference will be held at the National Institute of Standards
and Technology in Gaithersburg, Maryland, which is a suburb of
Washington DC (4 miles from the Shady Grove Metro Station).
The proceedings will be published by the IEEE.

Papers should present advances in the theory, design, implementation,
evaluation, or application of high-assurance systems, or report on
experiments, evaluations, and open problems in the use of new
technologies for computer assurance.  Special consideration will be
given to presentations (either single papers or paper pairs) by
practitioners and researchers who have worked on the same problem.
There will also be a tools fair and the conference will be preceded by
one or two days of tutorials.  Papers, panel session proposals,
tutorial proposals, and tools fair proposals are solicited in
relevant areas including the following:

   Software Reliability     Software Safety       Computer Security
   Formal Methods           Tools                 Human-Computer Interfaces
   Real-Time Systems        Networks              Embedded Systems
   V&V Practices            Certification         Standards
   Measurement and Metrics  Organization Theory   Lifecycle Processes

Representative application areas of interest include but are not
limited to: communications, military systems, avionics, road and rail
transport, space systems, nuclear and conventional power generation,
plant and process control, and medical systems.


Send five copies of your paper, panel session proposal, tutorial
proposal, or tools fair proposal to John Rushby, Program Chair, at
the address given below.  Abstracts, electronic submissions, late
submissions, overlength papers and papers that cannot be published in
the proceedings will not be considered.  Papers submitted from
outside North America should be sent via overnight courier service or
express mail.  Exceptionally, authors in countries where copying or
printing facilities are limited may submit a single copy in any form
available to them (including electronic mail).

Papers must be received by January 17, 1995 and must not exceed 7,500
words.  Authors are responsible for obtaining prior to acceptance any
and all necessary permissions and clearances for publication and are
expected to present their paper in person if it is accepted.
Authors will be notified of acceptance by March 14, 1995.
Camera-ready copies are due not later than April 17, 1995.

Papers that describe use of technology presented at a previous
COMPASS conference are eligible for a special award.  Papers of
exceptional quality and appropriate subject matter are eligible for
inclusion in a special issue of the Journal of High Integrity Systems
or the Journal of Computer Security.

Limited financial assistance will be available for student authors.


Robin Bloomfield Adelard, UK
Connie Heitmeyer Naval Research Laboratory, USA
John Gannon     University of Maryland, USA
Rich Gerber     University of Maryland, USA
Jon Jacky       Radiation Oncology, University of Washington, USA
Jeremy Jacob    York University, UK
John Knight     University of Virginia, USA
Carl Landwehr   Naval Research Laboratory, USA
Keith Marzullo  University of California, San Diego, USA
John McLean     Naval Research Laboratory, USA
Jon Millen      MITRE Corporation, USA
Steve Miller    Collins Commercial Avionics, USA
Peter Neumann   SRI International, USA
Hans Rischel    Technical University Denmark
Jeannette Wing  Carnegie-Mellon University, USA


Bonnie Danner, General Chair             John Rushby, Program Chair
                                         Computer Science Laboratory
TRW Systems Division                     SRI International
One Federal Systems Park Drive           333 Ravenswood Avenue
Fairfax, VA 22033, USA                   Menlo Park, CA 94025

Tel: (703) 876-4383                      Tel: (415) 859-5456
Fax: (703) 876-4304                      Fax: (415) 859-2844   

                        Paul Anderson, Publicity Chair
                        Space & Naval Warfare Systems Command
                        SPAWAR 224-1B
                        Washington DC 20363
                        Tel: (703) 602-3179
                        FAX: (703) 602 4485

Additional and typeset copies of this call for papers are available via
anonymous ftp from in /pub/compass95-cfp.{txt|tex|dvi|ps}
or via WWW from .

Please report problems with the web pages to the maintainer