Don't Settle For Just a Warranty

Once the acceptance period ends, some functionality issues will inevitably be discovered. This is why warranty and related provisions, such as remedies and limits of liability, are so important. These provisions often do not receive sufficient attention from the attorneys, corporate managers and contract analysts who typically draft and review them.

The licensor will normally include in the license agreement a boilerplate warranty that lists length and extent of coverage. The licensor is usually the software manufacturer but can be any entity granting the software license, such as an authorized reseller of the manufacturer. An example of a standard boilerplate warranty provision that licensees should beware follows.

Software warranty ' For 30 days following software delivery (the warranty period), the licensor warrants software will function without material defect. Licensor does not warrant software is free from all bugs, errors or omissions. Licensor will make reasonable efforts to correct any software that fails to comply with the foregoing warranty, provided customer gives licensor prompt written notice of such failure during the warranty period. If, after such reasonable efforts, licensor is unable to correct the software, licensor will refund a reasonable portion of the license fees customer has paid with respect to such software in full satisfaction of all of customer's claims relating to such noncompliance. The warranty does not extend to any failure of the software caused by use in an operating environment other than as specified by the licensor. A standard example of boilerplate remedies provision that is unacceptable to licensee follows.

Exclusive warranties and remedies. 'The warranties and remedies set forth in this section are exclusive and are in substitution for all other warranties. Customer hereby waives all other rights and remedies with respect to any noncompliance in any software, including ' but not limited to ' any implied warranty of merchantability or fitness for a particular purpose.

A poorly written limits of liability provision specifies what amount, as well as types, of compensation will be available to the licensee should a warranty breach occur. Here's an example of what licensees should avoid:

Limitations of liability ' Licensor's entire liability for any claim arising from or related to this agreement will in no event exceed the license fees paid to licensor by customer for the applicable item that is the basis for the claim. In no event will licensor be liable to customer or to any of customer's customers or any other person or entity for lost data, lost profits or for any punitive, indirect, incidental, special or consequential damages arising out of licensor's performance or nonperformance or the use of, inability to use or results of use, of any software.

Keep in mind that warranty provisions can be crucial in supplying remedy for a product that doesn't work. If clearly written, they can be indispensable; on the other hand, poorly written ones can be a nightmare.

Warranties

Warranties provide licensees remedy for defective software once the acceptance period is over. Most practitioners are surprised to discover there are many kinds of warranties. Some types of warranties one can request follow.

Performance warranty ' It's easy to omit an objective performance standard everyone can measure. To ensure a functional product, the agreement should clearly state the software will work at least as specified in its user manual and documentation. Be sure the warranty length will be appropriate for the intended use, especially if the software will be used at certain times of the year, such as annual events or quarterly transactions. These events should occur at least once during the warranty period to ensure the product will work as expected. Most licensors disclaim all warranties, citing 'industry standard practices.' Don't let this deter, because individual negotiators create industry standards. A licensor uncomfortable standing behind its software raises a red flag.

Compatibility warranty ' The software should be warranted to operate with any hardware or third-party software the licensor recommends. This is especially important if the software will be used as a basis on which the licensee plans to build a particular function. Also, the warranty should specify that all upgrades and enhancements provided will operate with the licensed software without errors or malfunctions. The right to acquire future upgrades and enhancements at no additional cost is meaningless if they do not work with the software initially purchased. Having to customize each upgrade or enhancement can be very expensive.

Compliance with laws and regulatory requirements ' If the software will aid the licensee in the operation of a highly regulated industry such as insurance or finance, then ask the licensor to guarantee the software complies with all laws and regulatory requirements. In addition, the warranty should require the licensor to supply upgrades or regulatory fixes to the software within a specified time of a regulatory change.

Adequacy of documentation ' The accompanying documentation should be the basis for any performance-standard warranty. In light of its importance, a warranty requiring the documentation to be complete and accurate should be included. If the documentation is vague, then the performance standard will be ambiguous.

Warranty of noninfringement ' Every software license agreement should contain a warranty requiring the licensor to indemnify the licensee if the licensee's right to use the software is challenged. When a licensee purchases a software license, the only thing the licensee pays for is the right to use the software. Warranty coverage should be extended overseas and not be restricted solely to the United States.

Data destruction warranty ' If the software is to be used to compile or manipulate data, then this warranty should be included. In industries such as finance or health care, the corruption of customer data can be disastrous. The software should be required to accurately interact with the data without damaging it. The licensor should be responsible for any damages and should be required to reconstruct any customer data, should that be necessary.

Virus warranty ' All software licenses should contain a warranty ensuring the software will not contain viruses. It's important the licensor warrant not only its own source code, but also any third-party source code used in development. The licensor should also be required to notify the licensee within a specified time if the possibility of a virus being present comes to light after product sale. The licensor should also be required to supply a fix for any virus found.

Remember that including a warranty isn't enough. If licensee doesn't build in a remedy for a requested warranty, then he or she has an 'empty warranty.' Some remedies that should be included in software license agreements are listed below.

Warranty remedies

Termination ' Always include the right to terminate the license agreement and any corresponding maintenance agreement. If the right to terminate the maintenance agreement is omitted, then the licensee may find himself with a continuing obligation to pay support for software not in use.

Liquidated damages ' For service-level performance warranties, it's a good idea to include liquidated damages (a specific amount of money agreed to in the contract as compensation for any breach), particularly when performance levels state software must be running for a certain percentage of time.

Specific performance ' Requested response times to any breach of warranty can be listed in accordance with the severity of the problem. The licensee should require that a cure to any breach be done within a specified time. A product glitch causing a customer problems might need immediate response, while a less-severe problem might allow a response over several days.

Intellectual property indemnification ' Indemnification should cover all court costs including any judgment awarded. This type of indemnification should also require the licensor to do one or more of the following:

• secure the licensee the right to use the challenged software;
• supply noninfringing software of an equivalent or greater functionality; or
• return all fees paid in connection with the agreement.

A time regarding when a remedy must be supplied should also be specified. The warranty should apply for the entire term of the license. If the license is perpetual, then the licensee should seek to extend the warranty for five to seven years, or until the technology will most likely become outdated. Be sure to omit clauses that will depreciate the warranty coverage over a period of time.

If software fails to perform and litigation appears inevitable, then the licensee will want to know two things: how much can he or she get in damages and what damages are available. The licensor's enthusiasm for curing any breach of warranty will be strongly influenced by the sum of money at stake. Some liability-limitation considerations follow.

Limits of liability

Disclaimer to avoid ' Every boilerplate software-license agreement disclaims all damages above actual damages. There's also usually a cap directly related to fees paid for the software. These disclaimers can be disastrous for the licensee, especially for a high-dollar deal gone bad. The licensee should seek to include damages such as special, indirect or consequential.

Damage limits to pursue ' Both parties will understandably seek to limit liability in the transaction. A compromise might be reached by capping the dollar limits of liability while allowing both parties to file a claim for any type of damages, consequential or otherwise, for which they can make a case. A licensee should generally require at least three times the amount of the fees paid for the transaction. This means that the cost for any consulting or implementation should be included in these dollar amounts. These fees can be costly and can often be considerably more than the license fee itself. Where both parties want to quantify their exposure, a general cap will allow definition of possible exposure while retaining an equitable remedy.

Other considerations

UCITA ' The Uniform Computer Information Transactions Act (UCITA) was drafted as a proposed revision to article 2B of the Uniform Commercial Code (UCC). The UCC is a uniform body of law governing sale of goods. But the UCC's drafters didn't envision transactions involving intangible goods when the code was developed prior to 1960.

UCITA was drafted to fix the insufficiency relating to technology transactions that exists within the UCC. It aimed to provide a uniform body of law to govern technology transactions. The revisions caused a stir, because many felt consumers of such products weren't adequately represented, thus perhaps creating a revision drafted heavily in favor of software developers.

UCITA is making its way from state to state to create a uniform body of law governing intellectual property transactions. Location of transaction parties, and the choice of law or forum, will affect whether the agreement will be subject to UCITA. Practitioners, then, must know the act and which states have adopted it. As of late January, only Maryland and Virginia had adopted UCITA. But legislation has been introduced in several states. Practitioners who fail to become familiar with the act and the states that have adopted it may undermine their own carefully crafted provisions, particularly those related to warranties. For more information on states with pending UCITA legislation, visit www.ala.org/washoff/ucita/news.html.

Marie Flores, J.D., is assistant vice president and contracts department manager at Southwest Bank of Texas, N.A., in Houston.

Software license agreements can appear deceptively easy to draft, particularly in an age when form contracts are readily available.

The danger, however, lies in overlooking subtleties that truly define parties' contractual intentions and obligations. If the licensee will be paying for custom software or modifications to pre-existing software, then warranties will play a particularly important role.

Well-drafted software development contracts include preacceptance standards to ensure the product will work as expected.

Once the acceptance period ends, some functionality issues will inevitably be discovered. This is why warranty and related provisions, such as remedies and limits of liability, are so important. These provisions often do not receive sufficient attention from the attorneys, corporate managers and contract analysts who typically draft and review them.

The licensor will normally include in the license agreement a boilerplate warranty that lists length and extent of coverage. The licensor is usually the software manufacturer but can be any entity granting the software license, such as an authorized reseller of the manufacturer. An example of a standard boilerplate warranty provision that licensees should beware follows.

Software warranty ' For 30 days following software delivery (the warranty period), the licensor warrants software will function without material defect. Licensor does not warrant software is free from all bugs, errors or omissions. Licensor will make reasonable efforts to correct any software that fails to comply with the foregoing warranty, provided customer gives licensor prompt written notice of such failure during the warranty period. If, after such reasonable efforts, licensor is unable to correct the software, licensor will refund a reasonable portion of the license fees customer has paid with respect to such software in full satisfaction of all of customer's claims relating to such noncompliance. The warranty does not extend to any failure of the software caused by use in an operating environment other than as specified by the licensor. A standard example of boilerplate remedies provision that is unacceptable to licensee follows.

Exclusive warranties and remedies. 'The warranties and remedies set forth in this section are exclusive and are in substitution for all other warranties. Customer hereby waives all other rights and remedies with respect to any noncompliance in any software, including ' but not limited to ' any implied warranty of merchantability or fitness for a particular purpose.

A poorly written limits of liability provision specifies what amount, as well as types, of compensation will be available to the licensee should a warranty breach occur. Here's an example of what licensees should avoid:

Limitations of liability ' Licensor's entire liability for any claim arising from or related to this agreement will in no event exceed the license fees paid to licensor by customer for the applicable item that is the basis for the claim. In no event will licensor be liable to customer or to any of customer's customers or any other person or entity for lost data, lost profits or for any punitive, indirect, incidental, special or consequential damages arising out of licensor's performance or nonperformance or the use of, inability to use or results of use, of any software.

Keep in mind that warranty provisions can be crucial in supplying remedy for a product that doesn't work. If clearly written, they can be indispensable; on the other hand, poorly written ones can be a nightmare.

Warranties

Warranties provide licensees remedy for defective software once the acceptance period is over. Most practitioners are surprised to discover there are many kinds of warranties. Some types of warranties one can request follow.

Performance warranty ' It's easy to omit an objective performance standard everyone can measure. To ensure a functional product, the agreement should clearly state the software will work at least as specified in its user manual and documentation. Be sure the warranty length will be appropriate for the intended use, especially if the software will be used at certain times of the year, such as annual events or quarterly transactions. These events should occur at least once during the warranty period to ensure the product will work as expected. Most licensors disclaim all warranties, citing 'industry standard practices.' Don't let this deter, because individual negotiators create industry standards. A licensor uncomfortable standing behind its software raises a red flag.

Compatibility warranty ' The software should be warranted to operate with any hardware or third-party software the licensor recommends. This is especially important if the software will be used as a basis on which the licensee plans to build a particular function. Also, the warranty should specify that all upgrades and enhancements provided will operate with the licensed software without errors or malfunctions. The right to acquire future upgrades and enhancements at no additional cost is meaningless if they do not work with the software initially purchased. Having to customize each upgrade or enhancement can be very expensive.

Compliance with laws and regulatory requirements ' If the software will aid the licensee in the operation of a highly regulated industry such as insurance or finance, then ask the licensor to guarantee the software complies with all laws and regulatory requirements. In addition, the warranty should require the licensor to supply upgrades or regulatory fixes to the software within a specified time of a regulatory change.

Adequacy of documentation ' The accompanying documentation should be the basis for any performance-standard warranty. In light of its importance, a warranty requiring the documentation to be complete and accurate should be included. If the documentation is vague, then the performance standard will be ambiguous.

Warranty of noninfringement ' Every software license agreement should contain a warranty requiring the licensor to indemnify the licensee if the licensee's right to use the software is challenged. When a licensee purchases a software license, the only thing the licensee pays for is the right to use the software. Warranty coverage should be extended overseas and not be restricted solely to the United States.

Data destruction warranty ' If the software is to be used to compile or manipulate data, then this warranty should be included. In industries such as finance or health care, the corruption of customer data can be disastrous. The software should be required to accurately interact with the data without damaging it. The licensor should be responsible for any damages and should be required to reconstruct any customer data, should that be necessary.

Virus warranty ' All software licenses should contain a warranty ensuring the software will not contain viruses. It's important the licensor warrant not only its own source code, but also any third-party source code used in development. The licensor should also be required to notify the licensee within a specified time if the possibility of a virus being present comes to light after product sale. The licensor should also be required to supply a fix for any virus found.

Remember that including a warranty isn't enough. If licensee doesn't build in a remedy for a requested warranty, then he or she has an 'empty warranty.' Some remedies that should be included in software license agreements are listed below.

Warranty remedies

Termination ' Always include the right to terminate the license agreement and any corresponding maintenance agreement. If the right to terminate the maintenance agreement is omitted, then the licensee may find himself with a continuing obligation to pay support for software not in use.

Liquidated damages ' For service-level performance warranties, it's a good idea to include liquidated damages (a specific amount of money agreed to in the contract as compensation for any breach), particularly when performance levels state software must be running for a certain percentage of time.

Specific performance ' Requested response times to any breach of warranty can be listed in accordance with the severity of the problem. The licensee should require that a cure to any breach be done within a specified time. A product glitch causing a customer problems might need immediate response, while a less-severe problem might allow a response over several days.

Intellectual property indemnification ' Indemnification should cover all court costs including any judgment awarded. This type of indemnification should also require the licensor to do one or more of the following:

• secure the licensee the right to use the challenged software;
• supply noninfringing software of an equivalent or greater functionality; or
• return all fees paid in connection with the agreement.

A time regarding when a remedy must be supplied should also be specified. The warranty should apply for the entire term of the license. If the license is perpetual, then the licensee should seek to extend the warranty for five to seven years, or until the technology will most likely become outdated. Be sure to omit clauses that will depreciate the warranty coverage over a period of time.

If software fails to perform and litigation appears inevitable, then the licensee will want to know two things: how much can he or she get in damages and what damages are available. The licensor's enthusiasm for curing any breach of warranty will be strongly influenced by the sum of money at stake. Some liability-limitation considerations follow.

Limits of liability

Disclaimer to avoid ' Every boilerplate software-license agreement disclaims all damages above actual damages. There's also usually a cap directly related to fees paid for the software. These disclaimers can be disastrous for the licensee, especially for a high-dollar deal gone bad. The licensee should seek to include damages such as special, indirect or consequential.

Damage limits to pursue ' Both parties will understandably seek to limit liability in the transaction. A compromise might be reached by capping the dollar limits of liability while allowing both parties to file a claim for any type of damages, consequential or otherwise, for which they can make a case. A licensee should generally require at least three times the amount of the fees paid for the transaction. This means that the cost for any consulting or implementation should be included in these dollar amounts. These fees can be costly and can often be considerably more than the license fee itself. Where both parties want to quantify their exposure, a general cap will allow definition of possible exposure while retaining an equitable remedy.

Other considerations

UCITA ' The Uniform Computer Information Transactions Act (UCITA) was drafted as a proposed revision to article 2B of the Uniform Commercial Code (UCC). The UCC is a uniform body of law governing sale of goods. But the UCC's drafters didn't envision transactions involving intangible goods when the code was developed prior to 1960.

UCITA was drafted to fix the insufficiency relating to technology transactions that exists within the UCC. It aimed to provide a uniform body of law to govern technology transactions. The revisions caused a stir, because many felt consumers of such products weren't adequately represented, thus perhaps creating a revision drafted heavily in favor of software developers.

UCITA is making its way from state to state to create a uniform body of law governing intellectual property transactions. Location of transaction parties, and the choice of law or forum, will affect whether the agreement will be subject to UCITA. Practitioners, then, must know the act and which states have adopted it. As of late January, only Maryland and Virginia had adopted UCITA. But legislation has been introduced in several states. Practitioners who fail to become familiar with the act and the states that have adopted it may undermine their own carefully crafted provisions, particularly those related to warranties. For more information on states with pending UCITA legislation, visit www.ala.org/washoff/ucita/news.html.

Marie Flores, J.D., is assistant vice president and contracts department manager at Southwest Bank of Texas, N.A., in Houston.