This article is a report I prepared for one of the parties in litigation outside the United States. I served as what American courts would call an expert witness. This article is published with my client’s permission. The parties’ names have been replaced, and identifying information has been removed.

This article explores an issue common to IT contract negotiations. If a technology development project is late or fails altogether, does the buyer have to pay for maintenance services? Does it have to pay for the underlying software or (not addressed by the report) for cloud computing services? Are buyer obligations conditional upon “go-live”: launch of the technology? Should they be?

Readers may want to skip the “Qualifications” section and go right to “Background Facts and Summary of Opinion.”

—————————

I have been retained by [deleted] (“Vendor Company”) to assist the court by providing my opinion on certain questions regarding the customs and practices of the information technology (“IT”) industry, particularly the operation of IT contracts. I am the author of a book that addresses those customs and practices, including some of the questions at issue in this litigation. In this report, I present my book’s relevant explanations and elaborate on them.

In the United States, where I practice law, my role would be described as “expert witness.” This report generally uses a format typical of U.S. expert witness reports.

Qualifications

I am the author of The Tech Contracts Handbook: Cloud Computing Agreements, Software Licenses, and Other IT Contracts for Lawyers and Businesspeople,[1] (“The Tech Contracts Handbook” or the “Handbook”). The American Bar Association published the second edition of The Handbook in August of 2015. The first edition, published in 2010, was the number-one bestseller for the American Bar Association’s Intellectual Property Law Section, starting shortly after publication and continuing throughout its time on sale.

I am an attorney practicing with Sycamore Legal, P.C. in San Francisco, California. I represent both buyers and sellers of information technology, and my primary services involve negotiating and drafting software license agreements and other IT contracts. I have represented clients ranging from small technology startups in the Silicon Valley to Fortune 100 global corporations. I began providing these services in 1997. Before that, I spent roughly three years providing litigation services, primarily on cases involving technology and intellectual property.

In addition to practicing law, I provide training on negotiating and drafting information technology contracts. Through these training engagements, I teach both attorneys and businesspeople about the clauses typically found in IT agreements. I also speak frequently on topics related to IT contracts, before bar associations and trade groups and at universities. And I have written several short articles on IT contracts.

I graduated cum laude from Harvard Law School in 1993, receiving a Juris Doctor, and I received an LL.M. from Cambridge University in England in 1994. I received my Bachelor of Arts from U.C. Berkeley in 1990, with highest distinction in general scholarship. I have served as General Counsel of a publicly traded software company, as Vice President of Business Development with a technology startup, and as an associate with a global law firm.

The biography page at my firm’s website provides additional information about my background, writing, training, and speaking engagements: http://sycamorelegal.com/team/david-w-tollen/. The website for my book also provides information about training and about my practice, and it hosts many of my articles: http://techcontracts.com/.

Background Facts and Summary of Opinion

I have reviewed the [license agreement] between [deleted] (“Integrator Company”) and Vendor Company, including the attached [statement of work] (collectively, the “Contract”). In that contract, Vendor Company agrees to provide certain technology products and services to Integrator Company’s customer, [deleted] (“Customer Company”), for use in a software development project. The products and services required are two different software systems, which for simplicity’s sake I refer to as the “base software” and the “client portal software,” as well as technology support and maintenance services. Integrator Company agrees to pay for all these products and services. It agrees to pay a fixed license fee (in installments) for the base software and to pay annual fees for the client portal software and services, with a minimum three-year term for the client portal software and a minimum five-year term for the services.[2]

I have been informed that Vendor Company delivered the base software and client portal software to Customer Company in [month & year] and that at that point, Integrator Company and Customer Company were free to use them. Use of the software didn’t require further action from Vendor Company. I have also been informed that Integrator Company then paid the applicable fees for the base software. But then in [month], Customer Company cancelled the software development project [deleted]. Whatever Customer Company’s reasons, I am informed that they did not relate to Vendor Company. Integrator Company claims that, as a result of the project’s cancellation, it should not be required to pay the contract fees for the remaining Vendor Company products and services: the client portal software and the maintenance services. Vendor Company has responded that the contract’s payment obligations are unequivocal, with no exception for any change of plan by Customer Company. [deleted].[3] So Vendor Company sued Integrator Company for payment.

I am informed that the court would like to learn whether IT contracts regularly include unequivocal payment obligations: requirements that the buyer pay, even if circumstances change and the buyer no longer needs the technology or services. I am also informed that the court would like to know whether enforcing such payment obligations would be consistent with IT industry custom and practice. This report endeavors to answer those questions.

In my experience, unequivocal payment obligations, like those of the Contract, are common in the IT industry. My book, The Tech Contracts Handbook, discusses unequivocal obligations to pay for maintenance services, and it tells buyers that such contract provisions may require that they pay for services they never receive. The book does not specifically address conditions on obligations to pay software license fees because, in my experience, contracting parties generally expect such obligations to be unequivocal.

The Handbook describes some of the reasons vendors ask for unequivocal payment obligations. They rely on those obligations in a variety of ways, and three are particularly relevant here. First, vendors often dedicate staff and other resources to technology projects in advance, incurring opportunity costs and other costs. Second, vendors often price their products and services on the assumption that they’ll receive reliable revenue streams. Third, vendors invest resources in drafting and negotiating IT contracts, and those contracts impose various risks on vendors, including risks that burden the vendor even if the project is cancelled. If the buyer doesn’t pay the expected fees, due to conditional payment obligations, the vendors’ investments in staff and other resources is wasted, it’s accepted contract risks in exchange for little or nothing, and its prices may not be adequate.

Also, at the heart of IT contracting customs and practices lies a desire for predictable relationships. Clear, explicit contract provisions lead to predictable relationships, while any risk of implied or imposed conditions, like unwritten conditions upon payment obligations, reduces predictability.

I am not arguing that IT buyers should or do at all times agree to unequivocal payment provisions. The Handbook advises buyers to ask for a conditional maintenance fee clause in some cases, and it points out that almost anything is negotiable. My opinion, rather, is that such exceptions generally should and do appear in the contract’s explicit written provisions.

The Prevalence of Unequivocal Payment Obligations

The Tech Contracts Handbook says the following about software maintenance obligations:

—–“—– The parties sometimes argue over when maintenance starts. Does it start the day the vendor delivers the software, or on the contract’s effective date? If the vendor will be customizing the software or needs time for delivery or installation, an early date like either of those could mean the customer pays for maintenance it won’t ever use.[4] —–“—–

The Handbook is inviting the reader to imagine a common transaction in the IT industry: a software development project that involves customization or implementation of software, as well as maintenance services. If the contract’s maintenance term and the buyer’s obligation to pay maintenance fees start at some fixed date, what then happens if customization isn’t done by that date, or if the project hasn’t even begun? There might be no software to maintain. What if the software is never ready for maintenance because something goes wrong in development or because the project itself never launches? The Handbook’s warning is clear: in cases like that, the contract may require that “the customer pays for maintenance it won’t ever use.”[5]

The Handbook doesn’t even assume the vendor is blameless. It does not posit that the vendor had nothing to do with whatever delayed the project or ended it, rendering maintenance services temporarily or permanently unnecessary. It simply warns the buyer that it might still have to pay. (Obviously, the vendor’s actions might relieve the buyer of its payment obligations in some cases, but not all. And in this case, of course, cancellation of the project did not relate to the vendor—to Vendor Company.)

Unequivocal payment provisions, like those discussed in the Handbook, are common in the IT industry. IT contracts regularly include obligations to pay for maintenance during some minimum maintenance term—usually a period of years—without exceptions for late or cancelled projects. (I suspect Integrator Company uses these provisions regularly in contracts with its customers.) In fact, in my experience, relatively few buyers even think to ask for conditional maintenance fee obligations.

The Tech Contracts Handbook does encourage buyers to think about the issue. It suggests that, if a buyer does not want to pay for maintenance it might not ever need, it should negotiate for an explicit written clause starting the maintenance term, and maintenance fees, when the software is ready for use, rather than on a fixed date.[6] The buyer, in other words, should ask for a conditional payment obligation: one that won’t go into effect if the software project never launches. The Handbook does not recommend that the buyer sign a contract with unequivocal payment obligations and then hope that clause won’t be enforceable, if unforeseen circumstances terminate the software development project. Again, the book warns buyers that such unequivocal payment provisions may require that they pay for maintenance they never use.

The Handbook also warns buyers that, even if they do request conditional maintenance fee obligations, they might not get them. Vendors often resist.[7] This report’s next section explains why.

Software license payment obligations work on similar principles. License agreements often provide for a license term starting on some fixed date—again, a minimum term usually lasting for some period of years—with fees required throughout that term. Under provisions like those, if the underlying software development project is cancelled through no breach of the vendor, the buyer pays for software it won’t ever use.

As with maintenance provisions, relatively few buyers try to avoid that outcome by requesting conditional license fee provisions. The Handbook doesn’t even address the issue related to license fees because it arises so infrequently. (Among other reasons, the buyer needs a license even to start a customization project—long before use in production.)

Information technology contracts, however, do not completely ignore risks related to unforeseen circumstances. In fact, most IT contracts I’ve reviewed address those risks through “force majeure” clauses. But they do so with explicit written provisions, not implied unwritten conditions, and the circumstances in question are disasters, rather than more predictable shifts in business plans (like cancellation of the Integrator Company – Customer Company software project). And even then the contracts generally don’t excuse payment obligations. The Tech Contracts Handbook offers a typical force majeure clause: “No delay, failure, or default, other than a failure to pay fees when due, will constitute a breach of this Agreement to the extent caused by acts of war, terrorism, hurricanes, earthquakes, other acts of God or of nature, strikes or other labor disputes, riots or other acts of civil disorder, embargoes, or other causes beyond the performing party’s reasonable control.”[8] The Contract has a force majeure clause too, and like the Handbook’s clause, it excludes payment obligations: “[deleted].”[9] The prevalence of these clauses demonstrates that IT buyers and sellers assume that their obligations will be enforced—even in the face of changed circumstances. That’s why they draft the force majeure clauses. The clauses also demonstrate the centrality of payment obligations in IT contracts. Even an earthquake or terrorist attack won’t excuse them.

The Rationale for Unequivocal Payment Obligations

In my experience, unequivocal obligations to pay fees play a central role in many IT vendors’ business models.

Some IT buyers simply never think to request conditional obligations to pay. They’re not experienced enough with technology to recognize that an early start date for the maintenance term, or an unequivocal obligation to pay license and service fees throughout the term, could require that they pay for software and services they never receive. (Integrator Company [deleted] doesn’t fit that description.) But even if the buyer does raise the issue, it often won’t get a late or conditional payment obligation. In my experience, most technology vendors resist. The Handbook explains why, with regard to maintenance fees:

—–“—– [T]he vendor may have good arguments for starting early [for starting the maintenance term and fees before customization is finished (or before it’s even started)] … It might make certain staff and other resources available through the maintenance process, and customization and installation might be difficult without those resources. Plus, many maintenance clauses include updates and upgrades … If maintenance doesn’t start until after implementation …, how does the customer pay for updates added during implementation? Also, for some vendors, maintenance fees “upon delivery” are built into the price of the technology. Maybe the customer really doesn’t need maintenance until after customization and installation, but license fees or cloud subscription fees would be higher if maintenance fees started later.[10] —–“—–

In other words, vendors argue that an early and unequivocal maintenance fee obligation is built into their business model. The vendor often has to allocate staff and other resources to the project in advance and arrange to have them available throughout the maintenance term. That commitment of resources involves costs, including opportunity costs: the other deals the vendor has to turn down or delay and the risk of upsetting other buyers. It may also involve the cost of hiring additional staff and buying additional resources. That investment makes sense if the vendor can rely on fees for some reasonably long maintenance term—usually some period of years. But if the buyer doesn’t pay for maintenance services, due to conditional payment obligations, the vendor has incurred those costs for nothing.

The same logic applies to software license fees, at least where the vendor’s commitments go beyond simply licensing and delivering the software. If the vendor’s obligations include supporting the buyer—providing tech support, maintenance, customizations, etc.—it again may invest staff and resources in the relationship, in advance. Fees for maintenance and other professional services might compensate the vendor for that investment, assuming those fees come with unequivocal payment obligations, but not necessarily. The vendor might price professional services relatively low, assuming it will make its money, and justify its investment, through software license fees. If so, the vendor has wasted its investment if it doesn’t receive fees for some reasonable license period—if the buyer avoids payment through a conditional payment clause.

Vendors also invest substantial resources and take potentially expensive risks simply by negotiating and signing IT contracts. The investments include staff and attorney time and fees dedicated to negotiating and drafting. The risks comes from contract clauses that might cost the vendor money, even if the underlying software project stalls of never launches. For instance, most IT contracts include intellectual property warranties and indemnities from the vendor. As soon as the buyer runs, modifies, or even tests the software, the vendor has incurred possible liability under these clauses. That’s because third parties might sue the buyer or vendor for intellectual property infringement, forcing the vendor to defend. Those risks and the vendor’s contracting expenses might not be worthwhile if the buyer doesn’t pay for the licensed software and maintenance services during some reasonable minimum term, due to conditional payment obligations.

I am informed that Vendor Company incurs exactly the sorts of costs described above. It allocates staff and other resources to anticipated development projects and buyer relationships, and it plans to keep those resources available during the applicable minimum terms: five years for maintenance in the Contract, with six months’ notice required to terminate even after that five-year period.[11] In that way, it incurs costs, including opportunity costs related to other business lost or delayed. In fact, I am informed that the Integrator Company – Customer Company project required an unusually large resource commitment for Vendor Company. And the Contract does impose various risks on Vendor Company, as discussed above, including intellectual property indemnities and warranties.[12]

The Handbook passage above on page [X] also suggests that vendors rely on unequivocal maintenance fee obligations in setting their prices. The same goes for software license fees, as suggested above. If an IT vendor couldn’t rely on fees paid over a reasonable contract term, due to conditional payment obligations, it would likely have to charge more for its suite of products and services. Vendors avoid conditional payment obligations because they’ve set their fees assuming those obligations will be unequivocal.

Assumptions Supporting IT Contracts

I believe two central assumptions lie behind all these IT industry customs and practices surrounding unequivocal contract provisions.

First, when IT buyers and vendors negotiate contracts, they generally assume that courts will enforce those contracts’ clear and explicit provisions, without imposing new clauses, like unwritten conditions on payment obligations. In U.S. jurisdictions at least, the law generally requires that courts do just that: interpret contracts based solely on their clear and explicit provisions.[13] The assumption that courts will not impose new provisions lies behind the advice in The Tech Contracts Handbook, and, I believe, the IT industry’s customs and practices.

Second, the IT industry—like most industries—benefits from predictable relationships. Clear, explicit written contract language provides that predictability. If courts impose clauses not written into the contract, like conditions on payment obligations, IT relationships become less predictable.

This emphasis on clear, explicit contract provisions runs through The Tech Contracts Handbook. As the book’s introduction explains:

—–“—– We sign contracts because good fences make good neighbors. … The best way to avoid arguments in a business relationship is to write down the parties’ expectations ahead of time. That list becomes a boundary marker—like a fence between neighboring yards—explaining who’s responsible for what. If the parties disagree, they can look at the list for guidance.[14] —–“—–

I believe that if one party can ignore those boundary markers, and if courts support that practice, IT buyers and vendors will find it difficult to cooperate as good neighbors, and the industry will suffer.

Conclusion

In contract negotiations, nearly anything is possible. So with both license fee and maintenance fee provisions, a buyer could negotiate a conditional payment obligation, applicable only if some software project launches or goes into production. Perhaps the vendor in a given contract doesn’t need to commit substantial resources to the buyer in advance, so it’s less reliant upon unequivocal payment obligations and can afford the concession. Or perhaps the buyer can offer incentives valuable enough to trade for conditional payment obligations. Those incentives might include better provisions related to other issues, like indemnity or limit of liability, or higher prices.

If the vendor accepts such a trade, the conditional payment provisions would generally appear in the contract, in an explicit written clause. The vendor, then, would not assume the buyer will pay—unless and until the software project launches or the software goes into production. It will have warning that it shouldn’t rely on the revenues and that it should think twice before passing up or delaying other opportunities or investing in extra staff or other resources.

If that negotiation happens, it is before the parties sign the contract, when the vendor still has a chance to adjust its commitment or to ask for something in return. If the buyer refuses to pay after the fact—after accepting a typical payment clause—the vendor has no chance to adjust its plans or to negotiate. It loses predictability in its relationships, it may have wasted resources and accepted unnecessary risks, and it gets nothing in return.

———————————

endnotes:

[1] Tollen, The Tech Contracts Handbook: Cloud Computing Agreements, Software Licenses, and Other IT Contracts for Lawyers and Businesspeople, Second Edition, (ABA Publishing; IP Section of the ABA 2015).

[2] Contract [section reference]. [deleted]

[3] Contract [section reference].

[4] Handbook 77 (emphasis added).

[5] Id.

[6] Id., 76-78.

[7] Id., 77-78.

[8] Id., 221.

[9] Contract [section reference].

[10] Handbook 77-78.

[11] Contract [section reference].

[12] Id., [section references].

[13] “[I]f an agreement is complete, clear and unambiguous on its face, it must be enforced according to the plain meaning of its terms.” Wiser v. Enervest Operating, L.L.C., 803 F.Supp.2d 109 N.D.N.Y. (2011). “The language of a contract is to govern its interpretation, if the language is clear and explicit, and does not involve an absurdity.” Cal. Civil Code § 1638. “[I]f the agreement on its face is reasonably susceptible of only one meaning, a court is not free to alter the contract to reflect its personal notions of fairness and equity.” In re New York Skyline, Inc., 471 B.R. 69, 2012 WL 1658355 Bkrtcy. S.D.N.Y. (2012). “[W]hen the language is clear and unequivocal, the parties are bound by its plain meaning.” Morris James LLP v. Continental Cas. Company, 928 F.Supp.2d 816, 2013 WL 943459 D. Del. (2013). Of course, litigation is rarely predictable, and U.S. courts sometimes go beyond the contract’s explicit provisions. But the cases above express the widespread general rule.

[14] Handbook xviii.

—————

—————

© 2015 by David W. Tollen. All rights reserved.