Subject: RISKS DIGEST 16.69 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Tuesday 3 January 1995 Volume 16 : Issue 69 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** HAPPY NEW YEAR! Note the collection of DATE stories! ***** ***** See last item for further information, disclaimers, etc. ***** Contents: Gov't Recommends Electronic Copyright Restrictions (Edupage) One for the GIFfer (CompuServe-Unisys GIF Tax Protest) (Pat Clawson) Mail repeatedly returned to sender (Curtis Keller) Dates in a 4GL (name removed) Dates and Times Not Matching in COBOL (Fred Ballard) Testing and the Sources of Dates and Times (Fred Ballard) Dates in "Ancient" Systems (Fred Ballard) COBOL's Two-Character Year Field (Fred Ballard) Last call for papers for COMPASS 95 (John Rushby) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Tue, 3 Jan 95 14:12:52 PST From: "Peter G. Neumann" Subject: Gov't Recommends Electronic Copyright Restrictions (Edupage) From Edupage, 27 Dec 1994: GOV'T RECOMMENDS ELECTRONIC COPYRIGHT RESTRICTIONS 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: listproc@educom.edu 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: listproc@educom.edu and in the BODY of the message type: unsubscribe edupage.] ------------------------------ Date: Tue, 3 Jan 95 13:27:49 PST From: "Peter G. Neumann" Subject: One for the GIFfer (CompuServe-Unisys GIF Tax Protest, 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 [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 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 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 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 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 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 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. 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.support@telegrafix.com ------------------------------ Date: Mon, 2 Jan 1995 22:05:11 -0600 From: Curtis Keller Subject: Mail repeatedly returned to sender "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 curtis@neosoft.com curtis@kinesix.com ------------------------------ Date: Tue, 3 Jan 95 12:12:12 XST From: [Name removed at submitter's request] Subject: Dates in a 4GL 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. NOTES: 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_. ------------------------------ Date: 01 Jan 95 21:31:03 EST From: Fred Ballard <72400.1525@compuserve.com> Subject: Dates and Times Not Matching in COBOL 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 COBOL.) ------------------------------ Date: 01 Jan 95 21:31:02 EST From: Fred Ballard <72400.1525@compuserve.com> Subject: Testing and the Sources of Dates and Times 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.) ------------------------------ Date: 01 Jan 95 21:30:55 EST From: Fred Ballard <72400.1525@compuserve.com> Subject: Dates in "Ancient" Systems 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 time. ------------------------------ Date: 01 Jan 95 21:30:57 EST From: Fred Ballard <72400.1525@compuserve.com> Subject: COBOL's Two-Character Year Field 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] ------------------------------ Date: Fri 30 Dec 94 12:08:49-PST From: John Rushby Subject: Last call for papers for COMPASS 95 Typeset copies of the CFP are available via anonymous ftp from ftp.csl.sri.com in /pub/compass95-cfp.{txt|tex|dvi|ps} and /pub/compass95-cfp-a4.{dvi|ps} or via WWW from http://www.csl.sri.com/compass95.html . 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. INSTRUCTIONS TO AUTHORS: 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. PROGRAM COMMITEE 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 FOR FURTHER INFORMATION CONCERNING THE SYMPOSIUM, CONTACT: 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 BONNIE.DANNER@trw.sprint.com Rushby@csl.sri.com Paul Anderson, Publicity Chair Space & Naval Warfare Systems Command SPAWAR 224-1B Washington DC 20363 Tel: (703) 602-3179 FAX: (703) 602 4485 andersop@smtp-gw.spawar.navy.mil Additional and typeset copies of this call for papers are available via anonymous ftp from ftp.csl.sri.com in /pub/compass95-cfp.{txt|tex|dvi|ps} or via WWW from http://www.csl.sri.com/compass95.html . ------------------------------ Date: 22 December 1994 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S. users on .mil or .gov domains should contact (Dennis Rears ). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, THEN please send requests to (which is not yet automated). SUBJECT: SUBSCRIBE or UNSUBSCRIBE; text line (UN)SUBscribe RISKS [address to which RISKS is sent] CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. All other reuses of RISKS material should respect stated copyright notices, and should cite the sources explicitly; as a courtesy, publications using RISKS material should obtain permission from the contributors. CURRENT ARCHIVES: "ftp unix.sri.comlogin anonymousYourName cd risks or cwd risks, depending on your particular FTP. Issue J of volume 16 is in that directory: "get risks-16.J". For issues of earlier volumes, "get I/risks-I.J" (where I=1 to 15, J always TWO digits) for Vol I Issue j. Vol I summaries in J=00, in both main directory and I subdirectory; "bye" I and J are dummy variables here. REMEMBER, Unix is case sensitive; file names are lower-case only. =CarriageReturn; UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username, password; bitftp@pucc.Princeton.EDU and WAIS are alternative repositories. Risks can also be read on the web at URL http://catless.ncl.ac.uk/Risks Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html (Please report any format errors to Lindsay.Marshall@newcastle.ac.uk) FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 16.69 ************************