FC: UCITA law: Weird name, great idea, or the Devil itself?

[Declan McCullagh <declan () well com>]

***********

> From: mheller () cio com
> To: declan () well com
> Date: Mon, 6 Mar 2000 09:00:24 -0500
> Subject: FC: UCITA plan may not be a travesty for consumers --responses
>
> HI Declan,
>
> You might send interested readers to http://comment.cio.com/sound.cfm?ID=37,
> where a debate over UCITA, in response to an article I wrote about it, is
> underway.
>
> All best,
>
> Martha Heller
> Web Writer
> CIO.com

***********

> From: Christy Hudgins <chudgins () tbg com>
> To: "'declan () well com'" <declan () well com>
> Subject: RE: UCITA plan may not be a travesty for consumers --responses
> Date: Mon, 6 Mar 2000 06:40:24 -0700
> X-Mailer: Internet Mail Service (5.5.2448.0)
>
> www.nwc.com/1008/1008f1.html
>
> Hi Declan,
> I noticed that a number of people wanted more detailed info about UCITA. I
> wrote a long feature examining these issues back in April. Some things have
> changed since then, but the gist of the legislation remains the same, so
> this might be helpful.
>
> www.nwc.com/1008/1008f1.html
>
> Christy Hudgins
> chudgins () tbg com

***********

> Date: Mon, 06 Mar 2000 05:34:03 -0500
> From: NBII <afn41391 () afn org>
> To: declan () well com
> Subject: Re: FC: UCITA plan may not be a travesty for consumers --responses
>
> Declan McCullagh wrote:
>
> Declan, one thing anyone who wants to oppose this will need is the info
> on their legislators, both state and national. I've regularly pointed
> this one out to people. I am unaware of any better site than this -- and
> even if a person doesn't want to comment on this specific issue, it's
> certainly one they'll want to keep for other cases where they might:
>
> http://www.vote-smart.org/ce/
>
> Feel free to post this to the list.

***********

> From: "Akilesh Rajan" <shivohum () nobletree com>
> To: <declan () well com>
> Subject: Informative UCITA Links
> Date: Mon, 6 Mar 2000 10:16:08 -0500
> X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
> Importance: Normal
>
> http://www.badsoftware.com/ and specifically
> http://www.badsoftware.com/uccindex.htm
> Current draft of UCITA: http://www.law.upenn.edu/bll/ulc/ucita/CITAAM99.htm
> http://linuxtoday.com/stories/15948.html
> http://www.thestandard.com/article/display/0,1151,12615,00.html
> http://www.forbes.com/forbes/00/0320/6507296a.htm
> http://www.computerworld.com/home/print.nsf/CWFlash/000303F33E

***********

> From: James Tierney <jamesti () microsoft com>
> To: "'declan () well com'" <declan () well com>
> Subject: FW: FW: UCITA plan may not be a travesty for consumers --response
>         s
> Date: Mon, 6 Mar 2000 21:07:32 -0800
> X-Mailer: Internet Mail Service (5.5.2651.58)
>
> Hi Declan,
> http://www.badsoftware.com/kaneropd.htm sets the record straight on UCITA.
>
> OP-Ed on UCITA,
> Cem Kaner and David Pels
> We grant permission to the press to print this article without payment to
> us. If you use it, please let us know at ucita () kaner com.
>
> As you read this, a little known but influential legislative drafting
> organization is finishing its work on a 350-page proposal called the Uniform
> Computer Information Transactions Act (UCITA). Backed primarily by computer
> software and hardware companies, UCITA will slash customers' rights.

[snip]


***********

> Date: Sun, 05 Mar 2000 23:14:01 -0800
> From: Barbara Simons <simons () acm org>
> To: Declan McCullagh <declan () well com>
> CC: Barbara Simons <simons () acm org>
> Subject: Melissa's Message
>
> Hello, Declan.  I noticed that some people responded
> to a Dan Gillmor article on UCITA that you posted by
> saying that they couldn't understand from his article why
> UCITA is a bad idea.  Below is an article that I wrote
> a few months ago.  It contains some specific arguments
> for why the technical community should be concerned
> about UCITA.
> Regards,
> Barbara
>
> http://www.cisp.org/imp/september_99/09_99simons-insight.htm
>
> September 1999
>
> Melissa's Message
>
> "Transforming the information infrastructure into a robust system will not 
> be an easy task. We must focus on policies and laws that encourage -- 
> rather than discourage -- the goal of a safe and secure information 
> infrastructure."
>
> Barbara Simons
> <mailto:president () acm org>president () acm org
> Dr. Simons was elected President of ACM in 1998, the same year in which 
> she also won the Electronic Frontier Foundation Pioneer Award. Selected by 
> clnet in 1995 as one of its 26 Internet "Visionaries," and named one of 
> the "Top 100 Women in Computing" by Open Computing in 1994, she holds 
> several patents and has authored numerous technical papers.Dr. Simons is a 
> member of the President's Export Council's Subcommittee on Encryption and 
> is also a Fellow of ACM and the American Association for the Advancement 
> of Science. She previously wrote for iMP in May 1999 on 
> "<../may_99/05_99simons-insight.htm>Outlawing Technology."
> This column has been adapted with permission from an earlier 
> <http://www.acm.org/pubs/citations/journals/cacm/1999-42-6/p25-simons/>version 
> that appeared in Communications of the ACM, Vol. 42, No. 6 (June 1999), 
> Pages 25-26.
> If you have spent the last few months in the Galapagos Islands, you may 
> not have heard of the Melissa virus. As the rest of us know, Melissa gets 
> itself replicated exponentially by exploiting the ability of Microsoft 
> Word to run macro attachments, a known security risk. While Melissa caused 
> some sites to disconnect themselves from the net, significantly slowed 
> down other sites, and created a lot of grief for systems administrators, 
> its effects could have been a lot worse. Melissa hit near the end of the 
> business day on a Friday, March 26, 1999. Although Melissa disabled virus 
> checking and generated large amounts of unwanted e-mail, it appears that 
> no disks were trashed nor files overwritten.
>
> What, if anything, will policy makers learn from Melissa? Will they take 
> steps to make computers, software, and the net more secure and robust? Or 
> will they pass laws that are likely to encourage buggy software and 
> irresponsible business practices?
>
> UCITA and UCC 2B. Because state laws govern commercial transactions in the 
> United States, the Uniform Commercial Code (UCC) was developed as a way to 
> facilitate interstate commerce. Most of the UCC is law in all 50 states; 
> Article 2, which applies to sale of software, is law in 49 states. For the 
> last four years, the American Law Institute (ALI) 
> <<http://www.ali.org/>http://www.ali.org/> and the National Conference of 
> Commissioners on Uniform State Laws (UCCUSL) 
> <<http://www.nccusl.org/>http://www.nccusl.org/> had been working on 
> Article 2B of the UCC. UCC 2B would have applied to mass market licenses 
> and in particular to shrink wrap licenses of software. However, the ALI 
> decided that it would not recommend approval of 2B in its present form. 
> This past April, the NCCUSL decided to go forward with approval of the law 
> anyway, renaming it the Uniform Computer Information Transactions Act 
> (UCITA). UCITA was passed in July, and it will be introduced in the state 
> legislatures. If passed by one or more states, some corporations may 
> threaten to move their headquarters to UCITA states unless the state in 
> which their headquarters are located also passes UCITA.
>
> UCITA applies to contracts involving digitized and other kinds of 
> intellectual property. It formalizes in law many current shrink wrap 
> license provisions, some of which are likely to encourage the marketing of 
> non-robust, buggy software.
>
> Anyone who has written a large program realizes that it's impossible to 
> produce bug-free code and very difficult even to produce software that is 
> robust and secure. Consequently, we do not hold software producers liable 
> for every bug that might occur in their software. But that does not mean 
> that they should be absolved of all responsibility for any problems that 
> might occur because of their software. UCITA makes it trivially easy for 
> software producers to limit their liability only to the purchase price of 
> the software, even if the producer knew that the software contained 
> serious bugs at the time of sale. It's a bit like telling food processing 
> companies that if they knowingly sell contaminated food, they are required 
> only to refund the purchase price of the food to people who are made ill 
> by eating it. If this aspect of UCITA becomes law, it could place 
> companies that strive to produce relatively bug-free and secure code at a 
> disadvantage when competing with other companies that have a less 
> professional approach. This is hardly a good strategy for developing a 
> secure and robust net.
>
> Benchmarking practices are another problem confronting software developers 
> and users. Companies have been known to tailor their products to optimize 
> the performance of standard benchmarks. Yet, when benchmarks are 
> customized for a set of tests, there is the risk that the benchmarks 
> might, intentionally or inadvertently, favor some of the software being 
> tested over other software. In spite of the known problems of benchmarks, 
> they are used as a rough method for comparing software and hardware. 
> UCITA, if enacted, will exacerbate the problem of evaluating and comparing 
> software by legitimizing nondisclosure agreements in licenses. In other 
> words, if you want to attempt to compare, say, several different database 
> programs, you may need the permission of each of the database companies in 
> order to publish your results. Presumably, companies whose software did 
> not perform especially well would be unlikely to allow you to publish 
> information about their software. This rule applies not only to 
> benchmarks, but also to any kind of analysis of the software, assuming 
> that the analysis is based on having run the software.
>
> Consequently, software producers, unlike almost any other kind of 
> producer, would be given considerable control over what is said about 
> their software. At a time when we should be publicizing information about 
> insecure products, we may find ourselves forbidden by law from so doing.
>
> A number of other portions of UCITA place the consumer at a disadvantage. 
> For example, a consumer probably could not hold a producer liable for 
> statements included in the manual unless the consumer saw the manual prior 
> to the sale. By contrast, the software producer would not be required to 
> make a copy of the license or any warranty disclaimer available for the 
> customer to read prior to purchase. The consumer's only recourse would be 
> to return the software if he or she objects to the terms, terms that 
> frequently are made known to the consumer only during installation of the 
> software.
>
> What should we do? Cem Kaner is a lawyer with a strong background in 
> computing and the co-author of the book, Testing Computer Software. Kaner 
> has spent the past several years working pro bono in an attempt to 
> negotiate more reasonable terms for UCC2B and then UCITA. He and a 
> colleague, Todd Paglia, have proposed an alternative approach to UCITA. (A 
> detailed description of the problems associated with UCITA can be found on 
> Kaner's web site 
> <<http://www.badsoftware.com/>http://www.badsoftware.com/>.) They 
> recommend that software producers should be free from liability for 
> damages caused by any defect that:
>    * Was not known to the producer at the time the publisher sold the 
> product, provided that the lack of knowledge was not due to grossly 
> negligent development or testing practices; or that
>
>    * Was described in material accompanying the product, written in a way 
> that a typical member of the product's market could understand.
> Otherwise, either the defect was known but not documented, or the quality 
> control was drastically inadequate. There are differing views about 
> whether or not there should be a cap on economic damages that can be 
> recovered because of defects in mass-market software. This and related 
> liability questions have underlying technical aspects that the legal 
> community is not equipped to evaluate unaided. Computing professionals 
> should be involved in any such debate, and we should insist that any laws 
> that are adopted encourage the development of sound, robust, and secure 
> software.
>
> We have constructed a large and complex system in which potential security 
> problems frequently are ignored. Transforming the information 
> infrastructure into a robust system will not be an easy task. We must 
> focus on policies and laws that encourage -- rather than discourage -- the 
> goal of a safe and secure information infrastructure.
>
>
>
> Released: September 22, 1999
> iMP Magazine, 
> <http://www.cisp.org/imp/september_99/09_99simons-insight.htm>http://www.cisp.org/imp/september_99/09_99simons-insight.htm
>
> © Copyright 1999, <http://www.acm.org/>ACM, Inc. Reprinted by permission. 
> All Rights Reserved. Permission to make digital or hard copies of all or 
> part of this work for personal or classroom use is granted without fee 
> provided that copies are not made or distributed for profit or commercial 
> advantage and that copies bear this notice and the full citation on the 
> first page. To copy otherwise, to republish, or post on servers or to 
> redistribute to lists, requires prior specific permission and/or a fee.
> <09_99itaa-insight.htm>Previous Insight <09_99hauben-insight.htm>Next 
> Insight<09_99hauben-insight.htm> <09_99contents.htm>
> <http://www.saic.com/>SAIC home | <http://www.cisp.org/>CISP home | 
> <copyright.htm>Copyright Policy | <masthead.htm>Masthead



> The organization is the National Conference of Commissioners on Uniform
> State Laws (NCCUSL). NCCUSL was formed by the States shortly after the Civil
> War, to write laws that all (or most) of the States could agree to. If
> NCCUSL approves UCITA at the end of this month, UCITA will probably become
> law in a few states by the end of 1999.
>
> Here are examples of the rules under UCITA:
>
> Suppose you buy a computer game.When you've finished playing it, suppose
> that you want to take it off of your computer and give it to your sister.
> Under the law today, this is just like buying a book or a record--you can't
> make a copy to keep for yourself, but you can give away the one that you
> bought or you can lend it to a friend or sell it used. Under UCITA, the
> publisher can say you can't sell the software used, lend it or give it away.
> Book publishers tried to restrict post-sale reselling of books a century
> ago. A feisty little retailer called Macy's took them on, and the United
> States Supreme Court invalidated these restrictions. UCITA's grant of new
> intellectual property rights to mass-market sellers is one of many reasons
> that the main American library associations oppose UCITA.
> Suppose your new computer game doesn't work. You call for help. The software
> company charges $3 per minute to talk to you. After half an hour ($90), you
> realize the company won't help you. You ask for a refund and return the
> product. Under UCITA, the company can send you the $40 you paid for the game
> but keep the $90 you spent on the phone call. You'd have been better off
> throwing the game away. This is one of many ways in which UCITA lets
> software companies avoid responsibility for their defects, even for defects
> they know about when they sell the product. Even for defects that they know
> about and choose not to tell the customer about. Many software developers
> believe that this rule threatens the professionalism of their work. It is
> one of the reasons that the main developers' professional societies
> (including the Association for Computing Machinery and the Institute for
> Electrical and Electronic Engineers) oppose UCITA or have expressed serious
> concerns about it. Similar opposition comes from quality control
> professionals.
> Suppose that a software company demonstrates a product at a trade show. You
> order the product at the show. The product you receive has different
> screens, is harder to use and less capable. Today, when a software company
> demonstrates a product, it creates a warranty that the product you get will
> be the same, work the same, and have the same capabilities as the one
> demonstrated. UCITA eliminates this warranty for the display layout and
> commands) and cuts it back for functionality.
> Backers of UCITA insist that it leaves consumers and small businesses with
> our existing rights, and gives us new ones. But it doesn't. That's why every
> consumer advocate we know (including Consumers Union and Ralph Nader's
> Consumer Project on Technology) has called for termination of the UCITA
> project. A July 9, 1999 analysis by the Federal Trade Commission points out
> that UCITA allows software companies to place "restrictions on a consumer's
> right to sue for a product defect, to use the product, or even to publicly
> discuss or criticize the product." The analysis concludes, "we question
> whether it is appropriate to depart from these consumer protection and
> competition policy principles in a state commercial law statute."
> NCCUSL is a well-respected legislative drafting organization. Having worked
> in the software industry (usually as managers) for most of our adult lives,
> we appreciate NCCUSL's enthusiasm for protecting America's fastest growing
> industry. But NCCUSL's drafting committee has let itself be too heavily
> influenced by software companies' lawyers, who dominate the committee's
> open-to-the-public meetings.
>
> Until recently UCITA was a proposed amendment to the Uniform Commercial Code
> (UCC) called Article 2B. The American Law Institute co-authors all
> amendments to the UCC with NCCUSL. The ALI called for "fundamental
> revisions" in Article 2B because of its treatment of customer rights.
> Recently, the ALI withdrew from the Article 2B process, killing it as a UCC
> amendment. NCCUSL renamed 2B UCITA and is now carrying UCITA on its own.
>
> >
> >-----Original Message-----


--------------------------------------------------------------------------
POLITECH -- the moderated mailing list of politics and technology
To subscribe, visit http://www.politechbot.com/info/subscribe.html
This message is archived at http://www.politechbot.com/
--------------------------------------------------------------------------