Contracting for Computer Software in Standardized Computer

Contracting for Computer Software in Standardized Computer Languages Vincent M. Brannigan, J.D. Department of Textiles & Consumer Economics University of Maryland College Park, MD 20742 Ruth E. Dayhoff, M.D. Department of Physiology and Biophysics Georgetown University Medical Center Washington, D.C. 20007 has a broad interest in insuring the freedom of entry into markets which is provided by standardization of products [2]. To say that such an interest is public in no way implies that individuals do not share in this public interest in standardization. For example, individual workers whose skills are dependent on the existence of standards often find substantially enhanced job mobility and employment prospects.

Abstract The interaction between standardized computer languages and contracts for programs which use these languages is important to the buyer or seller of software. The rationale for standardization, the problems in standardizing computer languages, and the difficulties of determining whether the product conforms to the standard are issues which must be understood. The contract law processes of delivery, acceptance testing, acceptance, rejection, and revocation of acceptance are applicable to the contracting process for standard language software. Appropriate contract language is suggested for requiring strict compliance with a standard, and an overview of remedies is given for failure to comply.

The private interest in standards revolves around their use in contracts. The use of standards allows private parties to easily and economically describe the desired product or service. For the uninformed buyer, it provides an indication of what an expert group finds acceptable. The private function of standards between two parties can generally be described as a "shorthand" for a substantially more extensive contract document.

Computer Language Standards.

Standards for computer languages are a relatively recent development, particularly at the national or international level. At this time COBOL, FORTRAN, PL/I, MUMPS, Minimal BASIC, and APT are formal American National Standards. Active standardization efforts are in progress for APL, PASCAL, FORTH, ADA, and several special purpose languages. The standard specifications for these languages when adopted as formal voluntary standards are made available through the American National Standards Institute (ANSI) or other standards organizations.

Introduction The rapid growth and development of computers the need for economic efficiency in programming has led to a concerted effort to standardize the computer languages in which programs are written. This article is designed to (1 ) fill two roles: for those who are contracting for software written in a standard language, to describe how to specify the standard for the language in their contracts, and (2) standards writers, to describe those components of computer software contracts which require clear and explicit information from the standards developer. and

A standard for a computer language consists of explicit definitions of the legal combinations of characters forming the commands or statements of the language as they would be encountered by the computer. The effects of the execution (interpretation or compilation then execution) of commands is specified for every legal command, and error conditions are indicated. Consequently, standards for computer languages tend to be quite lengthy.

Standardization as a concept dates back several thousand years. Standardization began with weights, measures and the like. It was considered significant enough to be incorporated into the constitution of the United States which says that the federal government shall set weights and measures [1].

A programming language implementation for a computer system is actually a program which reads commands as input data and performs their corresponding function as a result. These implementations fall into two types: interpreters and compilers. Interpreters perform the function corresponding to the command immediately, while

There are both public and private interests in standards. The public interest in standardization is founded on the increased efficiency, broader comnerce, and reduction of misrepresentation that In particular, society standardization allows.

0195-4210/82/0000/0483$00.75 @ 1982 IEEE

483

SOCKET

One of the reasons that users want programs written in standard languages is that they can be executed on different processors and different hardware without rewriting. Replacing old or unsatisfactory equipment does not require reprogramming. Also, software can be shared between hospitals or other users, and commercial software can be purchased from a variety of sellers. This ability to transport software among different computer systems is referred to as "portability. "

PLUG

B

STANDARD 11

A

The various national programming language standards were written by different groups of people with different goals in mind. In some cases, portability was a goal. However, the FORTRAN and COBOL standards fail to provide adequately for portability. The FORTRAN standard is "permissive" in that it considers a processor to be standard even if it accepts non-standard commands. Programmers who use these non-standard commands (and they may not know they are non-standard) will produce programs which are not portable. The 1974 COBOL standard is broken into a nucleus and eleven modules, each of which may be Nine of these implemented at various levels. modules, or roughly two thirds of the COBOL standard, are optional, and therefore, it is estimated that there are over 100,000 possible The MUMPS versions of standard COBOL [3]. standard was written with user program portability as a goal. A separate section of the standard specifies limits which must be observed by processors and programmeis t6 pr6duce portable software. Extensions to the language are allowed only as "Z-commands", and these commands must begin with the letter "Z" so they are clearly indicated to the user.

D, D rCz

C

u E

G

1. J

It is important to note that programming language standards affect both (1) processors which execute the programmed commands, and (2) programs which consist of commands which comply with the standard specifications. These must be used in combination by the buyer and therefore failure of either to comply with the language standard destroys portability and causes the combination to fail. This can best be explained by analogy to standard electrical sockets and plugs (see Figure 1). A processor which does not process all commands included in the standard (Figure 1C) will not correctly execute all standard user programs (Figure IB). However, programs which are written for it, using less than the full set of standard commands (Figure 1 D) will run on any standard processor. A processor which processes all standard commands correctly but in addition processes some non-standard commands (Figure IE) will run any standard program. But, such a processor allows the creation of non-standard programs, which contain commands not included in the standard (Figure IF) and cannot be run by standard processors.

Figure 1. Processors and programs can be analogized to electrical sockets and plugs. A and B represent a standard three-prong socket and plug. The prongs can be compared with standard language commands; the sockets are the portion of the processor that handles those standard commands. The processor equivalent of C is not able to process all of the commands which are contained in the standard specifications and therefore not all standard programs will execute. Program D, on the other hand, can be executed by any standard processor because it contains no commands which are not standard. The processor equivalent of E is able to process extra commands which are not part of the standard specifications. It will process any standard program, but will allow the creation of non-standard programs, equivalent of F, which cannot be executed by all standard processors. compilers produce an intermediate program which must be executed to produce the results. Throughout the remainder of this paper, these interpreters and compilers will be called "processors" to distinguish them from computer programs which are written in a standardized language which will be called " programs."

This article will use as an example for most purposes the American National Standard for MUMPS, a language commonly used for medical applications. However, most of what is said also refers to any other standard language. The MUMPS Standard was

484

feel that this definition which includes both the specification and the test method is overinclusive when used with computer language standards. The term "specification" should be limited to the description of the standard commands which make up the standard language, with separate definitions of test methodology and acceptance criteria. This is particularly true since the specifications are usually public, but the test method may be secret or continually changing.

It is currently first adopted in 1977 [4]. completing its five year revision which is expected to be issued in 1 982. Since a major private function for standards and a significant portion of the public function is their use in contracts, we will explore this topic in depth. Contracts refer to computer language standards as a shorthand for a detailed specification of the computer language which the parties intend to use. .

Test Methodology. Any method for determining whether a particular product complies with the standard should be defined under the test methodology section. ASTM uses the term "standard test method" for a concise description of an orderly procedure to determine a property or constituent of material or an assembly of materials. The directions for performing such a test should include all of the essential details, test equipment, test specimens or programs, procedures and calculations needed to achieve satisfactory precision both by the same operator in different tests or by operators in different In the case of a standard laboratories [6]. computer language processor, a lengthy test program might be used. In the case of a standard language program-, the test meth6dology might involve running the program under different conditions using various standard language

However, to attain both the private and public benefits of standardization in contracting, there are a series of functional elements which must be provided by either the standards document itself or by the contract terms which incorporate the standards documents.

Necessary Elements of Contracts for Standardized C~omputerSoftware Products While there is a discipline of standardization and courses are taught, it is still relatively new and it does not yet have compact nomenclature to define elements which each standard should have. These elements will be referred to in this article as scope, specification, test methodology, and acceptance criteria. There are a wide variety of standards documents for different products or tests, and each describes a subset of these When writing a contract for a elements. standardized product, it is often necessary to combine standards together with specific language covering missing elements in order to achieve the The extreme case is where no desired result. standard is used, and all elements must be explicitly included in the contract. It should be emphasized that these elements are defined by the authors, drawing on the use of similar terms in the standards field.

processors.

As noted earlier, the concept of a test method for a program is a difficult one for two reasons. If the seller has an absolute knowledge of the test program, it would be possible to write a processor that corresponded exactly to the test methodology. It is therefore typical to specify that a third party will evaluate the program and give an irrevocable judgment as to whether or not the program or processor meets the standard. The test methodology thus consists of some sort of test method performed by an independent person. In the case of COBOL processors, the U.S. government has set up the U.S. Federal Compiler Testing Center which has a procedure to test COBOL compilers by compiling, executing, and verifying results of test programs written in standard COBOL.

Scope. The scope element explicitly states irhat product or event is subject to the standard. The emphasis is on what is being standardized, not In the case of most current computer how. language standards, commands corresponding to computer actions or responses are what is being Standards often contain internal standardized. limitations on their use, e.g. "This method provides qualitative data only. When quantitative information is required for detailed designs of timeportant structures,this method must be supplemented by laboratory tests or other quantitative data to determine performance characteristics of the soil under expected field conditions" [5]. Contracts which attempt to override these limitations run a serious risk of The defeating the purposes of standardization. scope element should assist the parties in understanding the limitations of the standard.

Acceptance Criteria. The last standards function is the concept of an acceptance criteria. Test methods and acceptance criteria are normally Computer considered crucial in any standard. standards typically do not include these otherwise generally recognized vital parts. This may be due to. the unique problem of writing a standard for a In the case of a computer computer language. language processor, one acceptance criterion might be the successful execution of test programs. For a program, successful execution of the program under specified conditions might suffice. However, several writers [3,7] have said that it is impossible to state that a program complies with a standard, only that failure has not yet Since the failure may be discovered occurred. later, any software contract must allow for this

Specification. ASTM uses the word "standard specification" to describe a concise statement of requirements to be satisfied by a product, material or process including the procedure by which it may be determined whether the requirements given are satisfied [6]. The authors

contingency.

485

Among the most important ideas codified in the UCC is the concept of usage of trade [ucc 1-205(2)]. In the absence of a contract term, the courts look very heavily to the usage of trade within the given industry. In other words, if it is typical in the industry for the seller to deliver the program to the buyer and then spend a substantial amount of time tinkering with and debugging the program, then even if this was not provided for in the contract, the seller is normally given this right by the court. This is under a general policy of the UCC that the usual expectations of business men and professionals shall be upheld. On the other hand, any usage of trade is subject to specific contract language and can be specifically prohibited by the contract. Most courts also permit evidence of the course of performance or course of dealing between the This means that parties can alter or parties. supplement a contract by acquiescing to the other party's actioxs. This supports the UCC p-olicy of allowing the parties to modify contracts with a If a party is unhappy minimum of formalities. with the course of performance by the other party, it is vital that they make this known as soon as possible, or a court could hold that they modified the contract or waived the breach.

The difference between test methodology and relatively normally criteria, acceptance straightforward, becomes complicated with computer software. Test methodology can be thought of as producing a grade, such as a grade of 75. What the grade means is normally determined by the acceptance criteria, e.g. a grade of 60 or more is This may be appropriate with a acceptable. quantifiable element such as run time. However, since test methodology for compliance with a language standard tends to produce a pass/fail answer, then the acceptance criteria is in effect determined by the test methodology, i.e. they are the same. This puts a special burden on the test program; for instance, a test program may be 50 lines of code or 50,000. If it is 50 lines, a processor may pass, while the same processor might fail a more extensive test of 50,000 lines. Sophisticated acceptance criteria can be developed to differentiate between these cases, based on user requirements. Contract Law The law of contracts is an extraordinarily diverse field and contains many complications particularly when the object of the contract is as unusual as computer software.

Since the crucial concept of contract law is to carry out the manifest intentions of the parties, it is clear that there must be coordination between the standard itself and the contract if the aims of the parties are to be For this purpose, the parties must fulfilled. accept the principle that if there is not a section in the standard which gives them what they need then it must be written into the contract. This does not denigrate the standard nor imply that the standards writers should have done It simply expresses the something differently. reality that parties may need more detail than the standard provides or that they need provisions which are not standardized.

The Uniform Commercial Code (UCC) is a system of laws accepted by all states (with certain deviations) dealing with the purchase of goods [8]. It has not yet been clearly established whether or not computer programs are goods under the UCC [UCC 2-105, all UCC references refer to [8]]. If not, they may be governed by older and less explicit laws developed out of the common law on a case by case basis by the courts. Part of the problem is that software contracts for standardized programs tend to fall into two groups. There are contracts for packages which exist prior to the contract and are going to be replicated and provided to the buyer. There are also contracts for programs which will be custom made for the individual buyer. It is possible to think of these as the ends on a continuum with more and more customization of a program as it moves toward a program that is completely custom made. UCC concepts tend to deal with the more standardized packages or at least custom made goods for which exact specifications can be written. The authors believe that whether or not computer programs themselves are goods under the UCC, the aspect of the software contract concerning compliance with a standard is sufficiently like a transaction in goods that the courts should apply UCC thinking to the standardization issues involved in computer contracts. In any case, a contract may state that both parties agree that the UCC is to apply. This article assumes that parties wish to apply the UCC This assumption is made to their contracts. because the volume of litigation on UCC questions has served to clarify the law, and reduce uncertainty. In addition, the concepts of "cure" and "commercial good faith" incorporated in the UCC are of particular value in the computer field.

The crucial question in most contracts is to define precisely what the parties have agreed to and when. The first thing to determine is what benefits of standardization are desired by the contracting parties. It is therefore crucial to look at the question of why a party to a particular contract would want a program written Among the in a standard computer language. reasons a buyer might want to use standard program portability, programmer languages are: portability, ability to assign responsibility for malfunction of the system, cost reduction due to competitive market, assured performance, guarantee of qualities found important by a group of experts, and improved communication [3,9]. It is far beyond the scope of this discussion to determine all the terms which should be in a contract. It can be emphasized that parties who insist on custom made software to direct the function of a computer should not rely on boilerplate legal language to direct the contract. Contract language may be thought of as legal software. Boilerplate contract language has its uses, but parties must be sure it expresses their

486

intentions. It is, therefore, important that the contract include clear, explicit, unambiguous language providing for compliance with the standard. It is also crucial that the contract contain sufficient language that the standards elements mentioned above are actually included. Once it is accepted that the standard and the contract together form the agreement, then deficiencies in the standard can be clearly made up in the contract. If parties are forced to routinely provide contract language which should be included in the standard, the standard can later be improved by inclusion of such terms.

Figure 2.

Standard MUMPS Specifications

It is of the essence of this contract that all programs are written to comply with the American National Standard MUMPS version specified below (hereinafter MUMPS). Failure to comply with thi4 section entitles the purchaser to reject the program, at any time, and vendor shall be liable for incidental and consequential damages, including, but not limited to, the cost of procuring substitute software which complies with the standard. Without prejudice, purchaser may allow vendor a reasonable time to bring the software into compliance.

Specifying a Standard Language in a Contract. When do you have a contract for a program written in a standard language? For example, if a program is advertised as being written in American National Standard MUMPS and purchased on that basis, it is reasonable to assume that what is meant is compliance with the standard itself, not with some manufacturer's version of MUMPS. It is not sufficient that the statement "the program shall be written in MUMPS" is contained in the This could result in a non-standard contract. processor. Much more explicit language is needed such as that shown in Figure 2 D o ].

1. Processors -- A processor will correctly process any commands specified in MUMPS, including vendor specified "Z" commands.

2. Errors -- A processor will report as an error any command not in compliance with MMPS, i.e. specified MUMPS commands or vendor specified "Z" commands.

3. Programs -- Programs contain only commands in compliance with MUMPS, i.e. only specified MUMPS commands or vendor specified "Z" commands.

The contract language noted above makes When standardization crucial to the contract. standardization is important, strict compliance with a standard can be insisted upon, with the penalty being rejection of the entire package. However, this is not automatic simply from noting in the contract that the package will comply with the standard. Specific contract language is required (see Figure 2).

-program/processor 4. Portability The contemplated by this contract WILL/WILL NOT comply with the portability requirements of MUMPS.

5. Extensions -- The program/processor WILL/WILL NOT use any extension.

When a contract references a standard, specific identification of the standard is required. In the case of a computer language such as MUMPS, there is a national standard of a certain date. There are also approved revisions of certain dates and there will be, presumably, a new revised version of the standard. Therefore, a contract which merely provided that the program shall be written in standard MUMPS would generally be held to be flawed. While some element which was not included in any version of standard MUMPS would certainly constitute a breach of contract, an element which was included at some times but not at other times would put the court in the very difficult position of trying to decide exactly what the parties meant. Litigation over a point such as this is enormously expensive, involving expert witnesses and a great deal of time. The additional problem that some computer standards, such as FORTRAN, tend to permit non-standard variation causes an additional difficulty because it may not be possible to develop a test methodology to determine whether programs comply with the standard.

6. Extensions -- If extensions are permitted under Sec. 5, they will comply with MUMPS.

Fulfillment of the Contract. Buyers and sellers should be aware that the UCC includes several stages in the acceptance or rejection of goods. These can include: delivery, acceptance testing, acceptance or rejection, revocation of acceptance, breach of warranty, and cure by the seller.

Copyright 1982 V.M. Brannigan and B. Beier, College Park, MD. Reproduced with permission.

7.

The following extensions are required:

8.

The

following

extensions

are

[list]

permitted:

[list] .

The following extensions are prohibited:

llist] 10. The MUMPS version is: ANSI Standard MUMPS MDC Type A Releases

ANSI Standard MUMPS

(If approved)

(circle as appropriate) 1977 1978 1979 1980 1 981 1982

DIN NORM #

(If approved)

487

third party who tests it for compliance [UCC 2-515(b)] . With a standard, this is particularly useful because of the need to keep test criteria

It must be emphasized that the UCC often gives the buyer several different remedies for breach of contract by the seller. The buyer can reject the goods, demand a lower price as cure, or accept These alternative them and sue for damages. remedies may be crucial because one of the remedies may survive, even if the others are

secret. Also, the buyer pays the cost of inspection, unless the goods fail and are rejected in which case the seller pays [ucc 2-513(2)].

Rejection. Failure to pass test criteria is often a clear cut ground for rejection. However, it is not so simple because programs can fail the test methodology for a number of reasons which may have nothing to do with the actual compliance of the The most important program with the standard. problem that must be addressed with contract language is the problem of an ordinary error in the software. The problem of ordinary errors in software is beyond the scope of this paper but it has a very practical effect in that an error can prevent the software from being adequately tested and therefore accepted by the buyer. On the other hand, certain errors may be present in the software and yet not affect the test routines at all, which are only designed to test for Therefore, the compliance with the standard. acceptability of the program on the whole is not tightly controlled by its acceptability as being standard or not. These two different acceptance concepts must be treated separately. It is, of course, possible to write into the acceptance criteria that only a program which is acceptable in all respects will be accepted.

eliminated. Delivery is normally defined as presenting the goods for examination by the buyer. When dealing with computers and software, this normally takes place at the buyer's location. However, the UCC identifies the place of delivery as the seller's place of business [UCC 2-308]. While the buyer may be required to tender payment on delivery LUCC 2-511], it does not prejudice his rights to reject the goods [UCC 2-512]Jr.

Delivery.

A Acceptance is the stage at which the seller is considered to have delivered complying Goods can be goods to the buyer [UCC 2-606]. accepted by agreement or by using them after they have been inspected. This can occur even if the goods are defective unless the buyer notifies the seller of the defect.

Goods may be accepted or rejected £UCC 2-601], and acceptance may be later revoked LUCC 2-608]. Some consider the issue of acceptance and revocation of acceptance to be the most complicated issue in commercial code. To quote the leading author on the subject, "We can do little more than footnote some of the relevant cases and advise the lawyer dealing with 2-608 to charge a handsome fee." [11 ] Buyers should realize that acceptance of goods is an act with legal consequences and they should have clear procedures for acceptance.

The buyer also may reject only a part of the program and accept the rest [UCC 2-601]. It is not necessary that he accept the entire program or reject the entire program. But any subunits of the program which are accepted or rejected must be commercially reasonable.

Revocatipn of Acceptance. Even after the goods are accepted, if the buyer determines that the goods do not comply with the contract specifications, he is legally permitted under the UCC to revoke acceptance [UCC 2-608]. There are (1 ) there must be a flaw certain conditions: which entitles the buyer to reject the program, and (2) the flaw could not have been discovered or was not discovered in the exercise of reasonable In revoking acceptance, the parties diligence. are put back in the position they would have been in if the buyer had revoked when the goods were first delivered. That is, the program is given back to the seller and the buyer receives his money back.

Acceptance is a term of art under the Uniform Commercial Code and normally bears little resemblance to what computer personnel might consider to be acceptance. It is also complicated by the fact that the UCC deals in tangible items which wear out or otherwise depreciate whereas a computer program normally does not. The seller is not prejudiced by the buyers's use of the program. Many of the cases involving acceptance refer to "using" the item after notice of the defect as having accepted the goods whereas in a computer program you can return it in absolutely the same So the condition in which it was delivered. policy implications of acceptance in the case of computer programs have not clearly been thought out.

It is, of course, important to note in both of these cases that the right to return the goods and receive back the purchase price is often a very inadequate remedy for a hospital or other buyer who has adapted their entire operation to the These additional problems over and software. above the contract price are normally a reason to sue for breach of warranty.

Acceptance Testing. Acceptance under the code is explicitly provided for and acceptance testing is implicitly allowed under the concept of a reasonable opportunity to examine the goods [UCC 2-513]. The buyer need not disclose to the seller at the time of the contract the acceptance testing methodology to be used. On the other hand, if not disclosed, the buyer runs the risk that the seller will challenge the test methodology as unreasonable. The buyer therefore has to choose which course to take. One procedure which has becme common is to refer programs to an expert

Breach of Warranty. Warranties are of two types: express" and "implied." Express warranties are written into the contract; implied warranties operate by action df law. Implied warranties are often disclaimed successfully [12] and are beyond

488

the scope of this paper. Parties who use the terms in Figure 2 have made compliance with the standard an express warranty.

the buyer the unilateral right to rescind the contract or reject the program. The seller is entitled to a reasonable attempt to cure the defect.

A suit for breach of warranty is different from rejection. In this case, the buyer sues for the damages which resulted from the seller's breach . The typical damages that might result would be extra programming time to fix the program, disruption to normal activities, delay in achieving an operational state, etc. The choice between revocation of acceptance and breach of warranty generally depends on whether or not the buyer is better off keeping the flawed program and trying to recover the situation or simply discarding the flawed program. No general rule can be laid down.

The UCC does provide protection for the buyer who is assured by the seller that defects will be corrected [UCC 2-607(2)]. In other words, the buyer does not lose any rights by using software which the seller has promised to cure. One type of cure is an adjustment of price to reflect the difference in value. While not provided for by the UCC, it has respectable

support [13]. However, concerning compliance with the standard, it is often more important to the buyer that the program be brought into actual compliance. This is because the usual damages for

It is possible for the contract to provide for damages for breach of the warranty of compliance with the standard even if there is a disclaimer or other limitation of warranty for the general effectiveness of the software. The argument for this is relatively straightforward. A failure to comply with the computer language standard nomally involves an act by the seller either in writing the software or in refusing to fix the software. It is normally a deliberate choice to either include something which should not have been included or to exclude something which should have been included. Therefore, at any time the defect is discovered the buyer should have an adequate remedy against the seller.

breach of contract are the difference between the fair market value of the software delivered, and the fair market value of the software promised, not the value to the buyer. Assume for example that the market does not value a standards complying program any more than a program which does not comply with the standards. They sell for the same price, but the buyer has a substantial reason for wanting a complying program. If the damages were expressed in terms of market value and the court could force the buyer to accept the program and take the difference in market value, which in this case is nothing, the buyer would be put in a substantially worse position. However, to obtain compliance the buyer should write into the contract that compliance with the standard is a "material element" of the contract, or that compliance is "of the essence. "

Another critical reason for understanding both the revocation doctrine and the warranty doctrine is the common contract term which most sellers attempt to include which either disclaims all warranties [UCC 2-316] or limits the remedies for breach of warranty in a very unacceptable manner. It is important for buyers to realize that even if the seller has successfully disclaimed all warranties they still have the right to an acceptance testing period and the right to revoke for failure to comply with the contract specifications. Acceptance can be revoked even if a reasonable search would not have disclosed the bug. Since programs are unusually difficult to test in many cases, such doctrine can be of great value to the buyer. In addition, if the contract creates an express warranty, a term disclaiming all warranties may have no effect [UCC 2-508].

Summary of Contract Law. The statutory scheme is quite clear. The goods are delivered, the buyer inspects, if the goods are defective he gives notice to the seller, the seller is given the opportunity to make them right, if he is successful then he has complied with the contract, if he is not then he has breached and the buyer can either revoke the contract, give back the goods, and demand return of all monies, or keep the software and sue for breach of warranty. Failure to comply with the standard would be appropriately considered either a breach of contract or a breach of warranty.

Concluding Remarks

Cure by Seller. The seller is normally given a good faith opportunity to correct any errors, generally referred to in the UCC as the right to "cure. " The right to cure implies that the buyer will notify the seller of defects in the program, and the seller will put them right. The right to cure is limited under the UCC to certain specific circumstances. However, some of them seem almost tailor-made for computer program contracts.

This article has only been able to give an outline of the commercial law as it affects purchase of standardized software. Any purchaser of a major software system, particularly one which is to be custom designed or custom modified for the particular buyer, should have substantial legal assistance in drafting the contract and also in determining the acceptability of the course of performance under the contract. While there are no exact statistics, there are persons in computer law who claim that a reasonable legal fee on any software procurement contract is one to three per cent of the value of the contract.

While the concept of cure is fraught with difficulties, in the main it consists of the right, even after a non-complying product has been supplied, to go in and fix it. That is, the fact that the program is defective and does not comply with the contract does not automatically confer on

489

It should be noted that lawyers like to think of a world in which all contracts are clearly identified as such, signed by parties with appropriate authorization after clear discussion of all facts and reduction of all specifications to a written form with which all parties are Reality is satisfied. This is unrealistic. populated by very skillful and very ignorant buyers and sellers, at least as to the legal consequences of their acts. Often, in these authors' opinion, the more technically expert the buyer is about the product, the less likely he is to seek the advice of a lawyer and the less Like attention he will pay to the fine print. programing, contract law and standards are a means to an end. To obtain the benefits of standardization, the computing community must make its needs clear and insist on compliance with contract specifications. Failure to do so can only perpetuate confusion and disappointment in software procurement.

Contracting for 10. Brannigan, VM, Beier, B. Computer Software in MUMPS. MUG Quarterly XII(2):122, 1982. 11. White, JJ, Summers, RS. Handbook of the Law West Under the Uniform Commercial Code. Publishing Co., St. Paul, MN, 1980, p. 303.

Contracting for Computer 12. Zammit, JP. Products, Jurimetrics 22(3): 337-354, 1982.

13. White, JJ, Summers, RS. Handbook of the Law West Under the Uniform Commercial Code. Publishing Co., St. Paul, MN, 198C, p. 322.

References 1.

The Constitution of the United States of America, Article 1, Section 8.

2.

Hemenway, D. Industry Wide Voluntary Product Standards, Ballinger Publishing Co., Cambridge MA, 1975.

3.

Hill, ID, Meek, BL. Programming Language Standardization. Ellis Horwood Publisher (John Wiley & Sons), London, 1980.

4.

American National Standard MUMPS Language Standard (ANSI X1i .1 -1977). MUMPS Development Committee Publisher, 4321 Hartwick Rd. #308, College Park, MD 20740, 1977.

5.

Standard Test Method for Classification of Soils for Engineering *Purposes, ASTM D 2487-69, from Selected ASTM Standard for American Agricultural Engineering Students, Society for Testing and Materials, Publisher, 1916 Race St., Philadelphia, PA 19103, 1981, p. 97.

6.

Selected ASTM Standards for Agricultural E American Society for Testing and Materials, Publisher, 1916 Race St., Philadelphia, PA 19103, 1981.

7.

The MUG Shima, Y, Wakai, I, Ohno, K. Validation Routines, MUG Quarter XI(1):23-25, 1981.

8.

American Law Institute, The Uniform Commercial Code, Official Text. West Publishing Co., St. Paul, MN, 1972.

9.

MUMPS Implementation Tables. Dayhoff, RE. MUG Quarterly XII(1):3-17, 1982.

490