Agreements in the technology area are unique. Although many provisions in these agreements are substantially the same as those in other industries, many are quite different. These differences arise primarily because of the nature of computer technology and intellectual property often involved. Many Agreements in the technology area are entered into pursuant to the performance of computer software and equipment, installation, custom programming, software modifications and other software integration services.
Three of the most important provisions that should be included in every Technology Agreement are: (i) price and payment terms; (ii) service performance and delivery schedule; and (iii) product and service specifications. If the parties do not reach a complete understanding and agreement on these terms and clearly specify these terms unambiguously then the Technology Agreement will not successfully protect either party.
Technology contractors who are performing custom services usually request payment based on the amount of time involved in providing the services (time and materials). However, some customers insist on a fixed price agreement. Agreeing upon a fixed price for custom services can be difficult. In many ways computer development and integration services are similar to constructing a building. Just as in the construction of a building, a technology contractor can encounter unanticipated problems beyond the control of the contractor that may delay completion or make it impossible to complete the project. Although technology contractors will not discover granite while excavating a building foundation there are other problems that can be just as severe. If the parties do agree upon an appropriate fixed price for services, then the contractor should try to establish a payment structure that will allow adjustments in the price for unanticipated difficulties and delays especially if the delays or difficulties are caused by the customer.
Payments are rarely due on specific calendar dates. Except for initial payments, the payment times are usually based on completion of performance or portion of the performance that are typically called milestones. Some common payment structures are: (i) payment upon acceptance; (ii) periodic payments based on the level of effort, including the number of hours expended in the programming or integration effort; (iii) payments scheduled upon accomplishing certain milestones; (iv) payments based on the percentage of completion; and (v) limited periodic payments and a final larger payment due upon completion and acceptance.
It is very difficult to predict the exact time required to perform development or integration services. In many cases a flexible work schedule may be necessary. You will see these timelines and schedules in the “Scope of Work” section of a contract.
However, the customer will often ask for a final completion date. While the completion schedule should meet the customer’s requirements and expectations the schedule should also realistically anticipate the time that will be necessary to accomplish the work. When preparing a completion schedule to be included in a Technology Agreement you should keep in mind that software development is always late and that both parties to the Agreement are benefited by establishing a realistic and flexible schedule in order to avoid inaccurate schedules, disputes, irritation and liability . Analyzing past performance and how well projects had been completed in the past can give you a good picture of what to expect in the future. Technology Agreement completion schedules should provide for extension of the completion date if: (i) the customer or a third party delays the work; (ii) the customer requests changes in the specifications or additional services; or (iii) unanticipated problems in accomplishing the specifications in the required time occur.
The specifications and completion criteria should describe the required work in as much detail as possible. For example, the software’s response time, volume of transactions and other performance criteria should be set forth in the specifications.
There have been many legal battles between contractors and their customers that were caused by the failure of the specifications to properly describe the expectations and requirements of both parties. Also, general or non-specific services are bound to cause a problem if there are any types of customer dissatisfaction problems.
In addition to price, schedule and specifications, Technology Agreements should also contain the following provisions, although the exact form of these provisions will vary depending upon the agreement of the parties:
Important Note – The following contract terms and language possibilities ARE NOT MEANT as the ONLY wording or “THE” rule of thumb. They are shown here as examples only. NEVER give a broker or customer “suggestions” or “advice” on contract wording. ALWAYS refer them to their legal committee.
Testing, Acceptance and Duty to Correct Although the completion schedule will set forth the delivery dates, it is important for other portions of the Agreement to set forth the review, testing and acceptance procedures. These procedures usually give the customer an opportunity to test the product and require the contractor to correct any reproducible errors pointed out by the customer or the customer’s testing consultant.
This provision should set forth the remedies available to the customer if the contractor cannot produce a product that complies with the specifications. The contractor should make sure that this provision does not base testing and acceptance upon the subjective satisfaction of the customer (see above – specific and not general language). It is important for the customer and the contractor to be in a position to appeal to an expert or to a judge to determine if the contractor’s work product complies with the requirements of the specifications if there is a disagreement. Mediation and arbitration provisions are a useful method of resolving serious conflicts about Agreement performance since mediation and arbitration avoid some of the delay of litigation and place the decision in the hands of those persons more familiar with the technology industry .
Ownership of Copyrights, Trademarks. Trade Secrets and Patents The Agreement should clearly state who would own the work product copyright, trademarks, trade secrets and patent rights. If the contractor will own the copyrights, trademarks, trade secrets and patent rights then the contractor should grant license rights to the customer pursuant to a license agreement. These licenses are often perpetual and do not require additional license fees. The ability of the customer to obtain source code and make additional modifications is a very important issue that should be specified. If the customer will not receive source code then a source code escrow should be established to protect the customer if the contractor is no longer supporting the product.
Trade Secrets and Non-disclosure Agreements Technology Agreements often contain trade secret and non-disclosure provisions. These provisions can benefit both parties. Many contractors want to prevent their customers from disclosing the special techniques and programming code used by the contractor in performing the services. Many contractors want to prevent their competitors from viewing and using the product because their competitors can obtain competitive advantages. The customer will be concerned about inappropriate disclosure of its data and other business records that may be involved in the computer project. However, these trade secret and non-disclosure provisions must be carefully drafted so that the contractor is not later prevented from performing services for a competitor of a former customer and so that competitors of the contractor can be used for further services in the future, including the modification and support of the product if the contractor is no longer providing adequate support or modification services.
Warranties Some contractors warrant that the software will perform substantially in accordance with the material provisions of the specifications. This is more reasonable when the software exists and is operating properly at the time the Agreement is executed. In a development or integration Agreement this type of warranty is more risky. Some Agreements contain a warranty that the software will be free of defects and will meet the needs of the customer. Contractors should avoid this type of broad warranty and attempt to limit the scope and duration of any warranties. The duration of warranties and other support obligations must be limited specifically in the Agreement. Otherwise, the contractor can find that it has long term obligations that do not provide for further compensation. Many customers ask for a guarantied period of support and limits on support and maintenance fee increases. These can be very dangerous to the contractor since costs may rise in the future.
Disclaimers of Implied Warranties Except for any express warranties contained in the Agreement, the Agreement should disclaim, in capital letters, all warranties, including a disclaimer of all implied warranties of non-infringement, merchantability and fitness for a particular purpose.
Sample of typical language within a contract:
Disclaimer of Warranties:
1. “Except for the express warranty stated above. vendor makes no warranties, express or implied, including any implied warranties of merchantability or fitness for a particular purpose.”
Limitations of Liability .Many Agreements provide that the contractor’s liability for all causes of action and damages are limited to the sums paid to the contractor under the Agreement. However, many customers will not agree to these provisions unless the amount of the limitation is sufficiently large to provide protection. Contractors should also obtain errors and omission insurance. Errors and omission insurance will often cover the contractor and provide a legal defense if a customer claims that the contractor was negligent in performing the services.
Sample of typical language within a contract:
“Without limiting the effect of the preceding paragraph (i.e., limitation of liability), vendor’s maximum liability. if any, for damages shall not exceed the allocable portion of the price paid for the contract.”
Disclaimers of Consequential Damages Disclaimers of liability for consequential and indirect damages provide that the contractor is not liable for indirect or consequential damages. Indirect and consequential damages result, for example, from loss of the customer’s customers because of contractor’s failure to properly implement software in a timely manner according to the Agreement’s specifications.
Sample of typical language within a contract:
“In no event shall Vendor be liable under any legal theory for any indirect. special or consequential damages. even if Vendor has notice of the possibility of such damages.”
Integration Clauses The Agreement should contain a provision that provides that prior written and oral representations, statements and agreements relating to the subject matter of the agreement are terminated and are superseded by the present written Agreement. This provision has saved many contractors from liability for misrepresentations made during the “sales” stage of the negotiations. This has always been referred to as “oversell” (The salesman told me that the program would…).
Sample of typical language within a contract:
“This Agreement supersedes all prior agreements and understandings between the parties, whether written or oral, related to the subject matter and is intended by the parties as the complete and exclusive statement of the terms of their Agreement. No modification, addition to. or waiver of any of the terms hereof shall be effective unless in writing and signed by an authorized officer of Vendor.”
Continuing Obligation to Provide Error Fixes. There is no such thing as bug free software. The contractor should avoid statements, obligations and warranties that provide that the product will be free of defects entirely. However, it may be reasonable for the contractor to agree to exercise reasonable efforts for a limited period of time to correct errors that prevent the software from operating substantially in accordance with the specifications.
Sample of typical language within a contract:
” As the sole and exclusive remedy for breach of the warranty provided above. Vendor shall…(e.g.. repair or replace any component that proves defective within 90 days after delivery).”
Continuing Support and Update Obligations. Some contractors find that continuing support and update obligations are a business opportunity to obtain recurring revenue. However, if it is not contemplated in the pricing structure and if the description of the work can be construed to require the contractor to perform the continuing support or update duties after completion of the product then the Agreement can cause large losses and liability to the contractor. Contractors should not agree to support a product at a set price for a long term. Support Agreements should have short terms and provide that the contractor is only obligated to support current versions of the software. These Agreements should provide that training or support requests that constitute training are to be charged separately. Remind anyone of Year2000 concerns?
Non-Infringement Warranties and Indemnification Concerning Ownership
Many customers will require that the contractor warrant ownership of the software product and that the software does not infringe any copyright, trademark, trade secret or patent of another. Typically these include indemnities and agreements to provide a defense if someone asserts an infringement claim. Although this is a reasonable request it is important for the contractor to limit these warranties to United States law and attempt to exclude warranties concerning patents if possible. Contractors should attempt to avoid ownership warranties and infringement indemnification for software created by third parties. It is dangerous to warrant the ownership of software that has been prepared by another company.
Assignment Customers can reasonably request that the contractor not substitute another party to perform the work, including subcontractors, because the customer has been “sold” by the expertise of the contractor. However, the assignment provision should allow both parties to engage in corporate reorganizations, mergers and sales of the company as long as the parties performing the work and controlling the contractor do not change.
Arbitration and Dispute Resolution. Many disputes and much potential litigation can be resolved if unrelated senior executives of both parties meet, in person, to discuss and attempt to resolve disputes prior to either party filing suit. Some agreements require this type of unofficial consultation. Many agreements require binding arbitration in an effort to reduce the cost of litigation.
Each Agreement must be prepared so that it properly covers all of the issues raised by the specific agreement between the contractor and the customer. Since the specifications and terms of each Agreement are different it is important to ask an attorney to review the issues involved in the negotiation and preparation of each Technology Agreement. You should consult an attorney who practices in the computer area before preparing or signing any Technology Agreement, regardless of whether you are a contractor or a customer.
Underwriting Vendor Contracts – THE BASICS
When evaluating the exposures involved in providing coverage to prospective insureds for E&O, it is important to have a basic understanding of the legal principles affecting potential liability, as well as the steps that insureds can take to contractually limit their liability exposure.
Consequential Damages; Warranty, Representation, Breach of Contract Coverage
It is important to remember that —coverage forms for errors and omissions cover only consequential damages resulting from errors and omissions. Warranties and representations must be well-defined and limited in the contract, for the insured’s protection, since claims for damages that fall under failure to fulfill warranties or representations are not covered.
A well-written contract will disclaim liability for consequential damages. This vastly improves our ability to successfully defend the insured and reduces the exposure under the coverage part.
These factors require that the Underwriter carefully underwrite all contracts used by the insured and that the insured notify the Company if contracts are changed in general or are individually negotiated to change terms in these key areas.
The application requires that copies of contracts be provided. The Underwriter should be sure to get a new application, with current contracts for each renewal.
When Contracts Are Necessary
Almost all insureds should sell their products or services under terms and conditions specified by mutual agreement in the form of a contract. As a practical matter many sole proprietors or very small consultants, consumer products manufacturers, or small manufacturers may not use contracts in all situations.
For all submissions that do not use contracts the Underwriter must evaluate the extent of additional exposure and either increase the rate or decline to provide the coverage.
Current and Prior Contracts
Since E&O is a claims-made policy with, in some cases, full prior acts coverage, the Underwriter must also underwrite all contracts the insured has used in the past as well as current contracts. We must review the contracts used by the insured in the past 3 years.
It is extremely important to underwrite prior contracts on new business or renewals, if the prior contracts issue has not previously been addressed.
Use of the Contracts Checklist
The following is a checklist of important provisions. This checklist is for internal use only. Agents/brokers and insureds may be told of the clauses that are necessary, but the Underwriter should not give them the language to use. The important point to remember is that we cannot be in the position of telling insureds how to specifically write their contracts.
Use the following information to evaluate the contracts used by a risk. Discussion of the Underwriting Importance of each Provision,
- Disclaimer of Warranties: The contract should provide for reasonable warranties (e.g.. the product should do what it was sold to do. and disclaim all other warranties).
- Exclusive Remedy: Very important clause. Debit the rate if this clause is missing. In other words, within this contract is the only remedy if we should have a problem.
- Limitation of Liability:A well-written contract will disclaim liability for consequential damages. This provision vastly improves our ability to successfully defend the insured and reduces the exposure to loss under the coverage parts. Full Disclaimer of Consequential Losses : This is the norm.
Partial Disclaimer : This is where consequential damages are assumed to a limited amount
No Disclaimer : Not acceptable.
- Liquidated Damages: This is where the contract indicated the “maximum liability, if any, usually limited to the cost of the contract.
- Conditions Voiding Warranty: the contract will list circumstances where the warranty is voided. Examples include – accident, alteration, modification, etc.
- Delivery: Important provision. Delay in providing services, software or products most often is caused by errors that can lead to E&O suits. The customer of the insured will most often resist this clause. This is a business risk and usually involves getting a beta-tested product out to market too quickly.
- Risk of Loss : Not of great importance for E&O.
- Site Preparation : It is necessary for the contract to specify who is responsible for site preparation prior to the installation of the product/service. Particularly important for an insured doing business with first time or naive users.
- Force Majeure : “Acts of God”. The contract is not considered void if wars, riots, floods, strikes, etc., delay the completion of the contract.
- Integration: Very important to eliminate misunderstandings due to overselling or excessive expectations a customer may have. In other words, the contract states all of the warranties. No oral “oversell by the salesman” or other types of agreements are valid unless in writing and part of this particular contract.
- Period of Limitation: May already be limited by statute.
A leading computer expert once opinioned in testimony in a major lawsuit that approximately forty percent (40%) of all computer installations fail. That is a staggering number, and it helps to explain why there has been such an explosion in litigation involving computer product performance. Also staggering is the size of the recoveries being obtained in some cases, rising at times in excess of seven figures.
Problems with the performance of a computer system can arise from a variety of sources, including defects in the system’s requirements definition. Hardware (the central processing unit, memory and various peripheral devices), system software (the basic software that allows the computer to perform any useful task), application software (the specific programming written to enable a user to perform a particular job. such as billing or accounts receivable) or a combination of these. Problems can also arise because of poor environmental conditions, operator error or just plain unrealistic expectations on the part of the user.
Unlike early lawsuits involving computers, the bulk of future litigation is not likely to focus on the reliability of the physical components of a computer system. Hardware, by and large. is becoming more reliable. While there will always be the occasional lemon, the primary concern in the future will be related to software, particularly application software.
What users are interested in is a result. Most complaints in the future will center on failure to meet the needs of a particular user rather than on the total inability of a computer system to work. Vendors who undertake to provide solutions in the form of application software or complete turnkey systems will have greater exposure than those who offer only tools, that is, the hardware and system software.
The outcome of any litigation involving computers will be colored by the business context of the particular contract being litigated. Who, for example, are the parties? Is the vendee an unsophisticated computer neophyte purchasing a complete turnkey system on faith? Is it perhaps itself one of the constituent elements of the information technology industry such as OEM or a service bureau? Even if the vendee is an end-user not engaged in some aspect of the computer business, does it have computer expertise –either in-house or through the use of independent consultants? What is the product being purchased. licensed or leased? Is it hardware or software, off-the-shelf or custom-designed, extensively field-tested or experimental? What are the expectations of the vendee? Are those expectations realistic and, if not, what is the source of those unrealistic expectations? The answers to such questions will strongly influence a court’s attitude toward the parties’ legal arguments.
Theories of Legal Liability
Vendors of computer products have potential liability in both contract and tort law.
Although commercial law is the province of state rather than federal law, substantial similarity has been achieved between states as the result of the Uniform Commercial Code (“UCC”). This statute, adopted with minor variations in all states was the culmination of a long effort to codify, simplify and make uniform the law of commercial transactions. Article 2 of the UCC deals with analysis of the law of sales and is the usual point of departure in any potential vendor liability.
There has been substantial debate in the legal community whether software (as distinguished from hardware) is even within the scope of the UCC. One difficulty is that Article 2 specifies that it deals with transactions in “goods.” which are defined as “things’. which can be “moved.” Does software generally viewed as an intangible, constitute .’goods” within the meaning of the statute. The court decisions, which have considered the question to date, have generally been in the context of systems consisting of both hardware and software and have answered the question affirmatively. No published judicial opinion has yet dealt squarely with the issue as applied to software alone, but many courts in deciding cases seem to have tacitly assumed that programs constitute goods. Moreover, many commentators and the computer law committee of at least one prestigious bar association have expressed the view that software should be deemed “goods.”
Another problem in applying Article 2 to software transactions is that software is typically licensed rather than sold. Although Article 2 states that it deals with “transactions” in goods. most of its specific provisions speak in terms of a “sale.’. Is Article 2 flexible enough to encompass software licenses? Again, there is no definitive answer in the published judicial opinions, but courts seem to have assumed that the answer is “yes.’. In fact, the UCC has often been applied to the lease of tangible personal property, including computers. Many observers seem to agree that the UCC is properly applied to program licenses as well.
It is advantageous from a vendor’s viewpoint to have the UCC apply to a transaction, because UCC rules are clearer and easier to deal with than those encompassed within the common lay of contracts. In particular, the UCC lays down rather specific guidelines as to the creation and disclaimer of warranties. (Since they are by their nature service contracts and not the sale of goods, service bureau and consulting arrangements are outside the UCC.)
Breach of a warranty can result in liability of a vendor for monetary damages. The difference between the value of the goods, as delivered, and what they would have been worth “if as warranted” measure such damages. In addition, in the absence of any contractual restriction. a buyer may in a proper case also recover consequential damages (i.e., losses flowing from the breach over and above reduction in value of the goods themselves). The classic example of consequential damages is lost profits resulting from the inability to use the goods in one’s business. Given the critical importance of computers in the conduct of modern business, the consequential damages flowing from a system failure could conceivably run into , hundreds of thousands or even millions of dollars.
The UCC recognizes two basic types of warranties: Implied and Express. As to the former, there are two principal implied warranties. These are the warranties of “merchantability” and “fitness for a particular purpose”, There are clear distinctions between the scope of each of these warranties. The warranty of merchantability, unless disclaimed, arises in every contract for sale where the seller is a “merchant “. It imposes an obligation that the goods be fit for the ordinary purposes for which such goods are used. The warranty of fitness arises only if the vendor “at the time of contracting has reason to know any particular purpose for which the goods are required and that the buyer is relying on the seller’s skill or judgment to select or furnish suitable goods,”
nfortunately, the scope of the two implied warranties in the context of computer or software acquisitions is not always clear. What is a “merchantable” computer system? Unless it fails to operate at all, or generates incorrect results, the vendor can make a strong argument that the implied warranty of merchantability is not violated simply because the system does not perform the user’s particular application in accordance with the user’s expectations. Similarly, in the case of the implied warranty of fitness there may be substantial questions relating to whether the vendor had reasons to know of the vendor’s particular purpose and whether the vendee relied on the vendor’s skill and judgment. In the case of certain types of vendees, such as sophisticated OEMs or users with in-house data processing staffs, the answer to either or both of these queries may be “no.” Obviously, it would be preferable for the vendor if it could exclude these rather uncertain implied warranties from its contract.
An express warranty is “any affirmation of fact or promise made by the seller to the buyer which relates to the goods and becomes part of the basis of the bargain”. In addition to specification incorporated into the contract itself, express warranties can arise by virtue of demonstrations, oral representations by salesmen. or statements contained in advertising and promotional literature. It is not necessary that any particular words, such as “warrant” or “guarantee” be used in order to create an express warranty. Again, it would be to a vendor’s advantage if it could obviate liability for any vague or broadly stated “express” warranties allegedly made by sales personnel or in promotional materials during the pre-contract marketing phase of a transaction and limit its legal obligations to the specific representations set forth within the four corners of a written contract.
Limiting Contractual Liability
In fact, the UCC does permit vendors to exclude the implied warranties and to otherwise circumscribe the scope of its contractual liability, The implied warranties of merchantability and fitness can be effectively disclaimed if the rules set forth in the UCC are followed. These rules essentially require conspicuousness of the disclaimer and specific use of the word “merchantability.” Assuming compliance with the language and conspicuousness requirements, disclaimers of the implied warranties in computer systems procurement contracts have regularly been found to be valid. (The federal Magnuson-Moss act substantially limits the ability of a vendor of “consumer” goods to disclaim the implied warranties. What constitutes a “consumer” good in the context of computers is debatable, although many personal computers probably qualify. Whether software is a “good” for Magnuson-Moss purposes is an unanswered question.
Similarly, a purchaser can usually be successfully precluded from purporting to reply on supposed pre-contractual express warranties by the so-called “parol evidence rule”. This rule provides that, where a written contract is intended by the parties to be the final and complete expression (“integration”) of their agreement. pre-contractual statements are not admissible in evidence to vary or add to the provisions of the contract. The likelihood of establishing an integration is substantially enhanced by the inclusion of a clause (often called a “merger” clause) in the written agreement specifically stating that the contract is the complete and final expression of the parties’ agreement. Thus, by appropriate drafting of the contract (including disclaimers and a merger clause), a vendor can assure that it will be held accountable only for the specific express warranties set forth in the written agreement.
There are other ways in which the UCC allows a vendor to circumscribe its potential liability exposure. One is by contractually limiting the remedies available to an aggrieved buyer. Thus, a vendor may extend a limited, but exclusive, remedy (typically repair or replacement) for breach of warranty, exclude consequential damages (including lost profits) and provide for a “liquidated” (fixed) ceiling on recoverable damages.
Another way of reducing the vendor’s risk is to contractually limit the period in which a lawsuit may be brought. The normal statute of limitations for breach of warranty is four years from tender of delivery. Under the UCC, however, the normal statute of limitations can be reduced in the original agreement between the parties to not less than one year.
Non-Contractual Theories of Liability
Because the UCC permits vendors to substantially’ limit their contractual liability, disappointed users and their lawyers have sought legal theories by which to circumvent contractual restrictions. There are two principal avenues that such disappointed vendees have pursued.
First, the buyer may argue that the restrictions contained in the contract simply are not fair or, in the semantics of the UCC, that they are “unconscionable.” There appear to be only two reported cases in which the unconscionability argument has been successfully advanced in the context of computer procurement. These cases notwithstanding, the applicability of the unconscionability notion in an “arm’s length” commercial transaction is doubtful. The UCC, as has been seen, explicitly authorizes disclaimers of warranty. Similarly, the UCC permits various limitations on remedies. Indeed. the UCC specifically permits exclusions of consequential damages and provides that such clauses are not presumed to be unconscionable where the loss involved is commercial in nature. Accordingly, the vast majority of judicial decisions dealing with such restrictive provisions in computer contracts have upheld them against “attachment” on the purported ground of unconscionability.
The more likely route to circumventing contractual disclaimers and limitations of remedy is the assertion of so called “tort” causes of action. Since tort law’ compensates for violations of duties imposed by operation of law rather than assumed consensually, contractual restrictions are usually not deemed to bar recovery in tort. The broader question, however, is whether the importation of tort theories into the area of commercial transactions is appropriate.
Tort theories generally fall into two categories, namely, errors of omission or commission in the design or manufacture of the product and misrepresentation of the attributes or capabilities of the product. As to the former, while some states have allowed tort recovery for purely economic loss based on faulty design or manufacture, the majority view seems to be that, in the absence of personal injury, negligence and similar tort theories are inappropriate. This has certainly been the holding so far in the few computer-related cases that have considered the issue. The rationale appears to be that there is no duty imposed by law separate and apart from the contract itself and hence no room for non-contractual liability. (In service contracts not covered by the UCC, however, the possibility of tort liability is substantially increased.)
The tort theory most in vogue among disgruntled users in that of fraud. It is easy to see why. In the first place, all those disclaimed extra-contractual “express warranties,” which would otherwise be excluded pursuant to the parol evidence rule, suddenly become provable. Moreover, a successful plaintiff is entitled to recover all their damages, regardless of any contractual limitation of liability, plus (in some instances at least) punitive damages.
Although the UCC specifically recognizes the possibility of recovery for tortious misrepresentation separate and apart from recovery for breach of warranty, a number of courts have displayed reluctance to permit disappointed users to avoid the bargained for terms of their contracts by resort to misrepresentation theories.
Such decisions are generally predicated upon either failure to prove fraudulent intent or failure to plead the alleged misrepresentation with sufficient particularity. To the extent that allegations of misrepresentation are merely contract claims disguised in order to circumvent contractual disclaimers of warranty, the results seem appropriate. Nevertheless, if the necessary elements of a cause of action for misrepresentation can be properly pleaded and proved, no contractual disclaimer of warranty is likely to prevent the imposition of liability. (In addition to common law fraud, some states have adopted deceptive trade practices statutes. Typically, such statutes allow recovery for false promotional statements regardless of either an intent to deceive or even negligence. Often a successful plaintiff can recover multiple damages and attorneys’ fees.)
Considerations in Drafting Computer Contracts
The importance of a well-drafted contract can hardly be overstated. The more precisely the rules of the game are drawn in the contract, the less room there will be at a later date for a court or jury to import into the balance its own peculiar “notions of fairness” (often born of an imprecise understanding of the nature of the relationship). In this regard the vendor frequently has the advantage in that it prepares the contract The price one pays for this privilege, however, is the judicial doctrine that ambiguities in a contract will be resolved against the draftsman. This rule of construction is even more strictly applied in the case of standard form con tracts.
Careless use of language can be devastating. In one case, the court completely read out of the contract the vendor’s warranty disclaimers and limitations of liability because the front of the form referenced the terms on the reverse side of the so-called “security agreement ” In fact, the transaction did not involve a financing and the court found the standard terms (which should have governed regardless of the form of the transaction) to be inapplicable.
It is essential that the vendor’s performance obligations as to both hardware and software be defined clearly and in sufficient technical detail. This can be done by incorporating detailed specifications into the contract and making it clear that such specifications are the criteria by which to measure the vendor’s performance. This will go a long way both to assure the vendee’s satisfaction and to protect the vendor from assertions that the equipment fails to meet either “promised” or “generally accepted” standards of performance or functionality. It is advisable to avoid terms that may come back some day to haunt, such as “turnkey,” “management information system,” etc. All such terminology does is to invite argument over interpretation.
The contract should also be specific in defining the vendor’s obligations regarding site preparation, delivery, installation, interfacing with foreign devices, maintenance, conversion of data, acceptance testing, provision of documentation and so forth. Likewise, the agreement should be clear in spelling out the duties of the vendee, such as to provide a proper environment and clean power, as well as to pay in accordance with a specified payment schedule.
TECHNOLOGY CONTRACT PROVISIONS CHECKLIST
Contractual agreements affecting a business is unique due to the nature of computer technology and intellectual property involved. Most contracts are related to design and installation of equipment, the performance or modification of computer software and other related services performed by a technology firm.
How well the insured is protected depends, in large part, on the specific provisions contained in the contract. The following are some of the more common contract provisions used in the technology area.
- Integration Merger Clause – All prior agreements and oral and written communications are superseded.
Categories: Hartford Articles
- Limitation of Liability – Liability will in no event exceed the total amount paid pursuant to the contract during the last twelve months.
- Warranty and Representation Disclaimer – Gives no warranty or representations, express or implied, except as expressly stated herein.
- Waiver of Consequential Damages.
- Ownership of Proprietary Rights – Does the Insured or the customer own copyrights and patent rights produced pursuant to the agreement.
- Non-Disclosure Agreements.
- Payment Provisions.
- Representations of Authority and Ownership by the other party.
- Assignment Allowed?
- Length of Term.
- Clear description of each party’s performance obligations.
- Obligation to Pay Expenses.
- Payment in U.S. Currency.
- Who Pays Taxes and Withholding Payments?
- Scope of Right to Use Proprietary Information and Software.
- Territory Limitations.
- Arbitration and Dispute Resolution Provisions.
- Non-Solicitation and Non-Compete Agreements.
- Written Default Notices and Termination Provision.
- Choice of Law and Jurisdiction for Arbitration and Law Suits.
- Right to Disable Software for Nonpayment or Default.(Dangerous Provision)
- Right to Use Work in Other Engagements.
- Right to make Derivative Work of Client’s Work.
- Right of Each Party to Audit the Other.