Whether you are an in-house transactional generalist, a litigator focusing on business disputes or the junior associate who has been tasked with overseeing the firm’s transition to a new record management system, the odds are good that you will need to draft, negotiate or review a software contract during your career. Software contracts can seem overwhelmingly full of technical jargon and the allocation of duties inscrutable.These challenges are often compounded by pressure for you as the lawyer to rapidly review and understand the contract’s terms. A client’s eagerness to leverage the software to gain new business efficiencies, the approach of a filing deadline in a dispute or the simple need to lock in a good rate are just a few of the many considerations pushing toward a quick turnaround on the legal review. Close collaboration between the lawyer and an IT expert can help—along with several key steps in the legal analysis.

Understanding the Purpose

Before delving into the review, drafting or negotiation process, it is critically important to develop a general, broad understanding of the client’s purpose in entering into the contract. A license agreement for use of a commercial off-the-shelf software package, an agreement for light configuration of an existing tool or a contract for the development and ownership of completely new custom software all differ from one another and address separate legal issues. Thus, whether you are negotiating, drafting or reviewing a software contract, it is necessary to determine the parties’ reasons for entering into the contract at all.

Traditionally structured contracts use recitals to discuss purpose, and as in other contracts, they can provide helpful indication of the motivations underlying a software agreement.¹ The modern trend is drafting lean contracts, and recitals of this nature might be skeletal or even omitted completely. Regardless of whether they are included or not, approaching a software contract as though you must write recitals for it yourself is a workable way to build an understanding of the business reasons behind the contract. Must the software interface with an existing system? What is the advantage that it offers? How will it facilitate the work that the customer does? Talking with your IT expert at the beginning of the process about the common purposes of existing software (license context) or the intended purpose for custom software (development context) will drastically reduce the time needed for you to identify core issues and locate or draft the relevant provisions. Moreover, once you are clear on which business functions the software supports, it will be much easier to identify key risks, allocate them between the parties and build in controls to mitigate them.

In addition to understanding the agreement’s purpose, it is necessary to understand the timeline of that purpose. Does your client intend to use the software long-term? If so, who will support its maintenance and perform updates? In a licensing agreement, duration of the intended use or purpose will inform the duration of the license. In a contract for custom software development, the deadline for implementation of the system or deadline for moving the software from user acceptance testing to production status is a central issue. And a project with an agile approach to software development normally involves an iterative process (requirements gathering, modeling, design sessions, testing, etc.) over successive periods of work on specific groups of components or functionality (i.e., “sprints”).² The prioritization of tasks in each sprint drives the entire project’s tempo and success. Gathering this context from your client or your IT expert in a quick conversation expedites your legal review.

Performance Standards and Approach

One feature that distinguishes software contracts from more conventional agreements is the difficulty in articulating performance standards that adequately describe the roles of the parties and the services. This is attributable, in part, to the methods commonly used to accomplish development work. For example, while agile software development works well for technical purposes, it is at odds with the traditional contract drafting focus on describing the specifications of the deliverables; it is almost impossible for the parties to comprehensively state the specifications of the software at the time of contracting, and the development process will invariably encounter practical considerations that render changes necessary. These considerations push the parties toward looser standards.

Significantly, however, there is no special rule of contract law reducing the degree of specificity that is necessary to support specific enforcement of software contracts. Rather, software development contracts are, like any other, governed by the bedrock principle that a contract must be of sufficient explicitness so that a court can perceive what are the respective obligations of the parties.³ Simply listing the categories of services or the types of functionality that the developer must deliver normally does not establish adequate specificity for contract formation.⁴ At the other end of the spectrum, a contract with excessively detailed specifications the software must meet can be detrimental to your client.⁵

One strategy to resolve the competing interests of fluidity in software development, practical deal structure and contract specificity is to use the most of the contract’s performance standards to describe the development process (details of development approach, length of each sprint, major deadlines, etc.) rather than the software itself. This sort of drafting, coupled with a payment milestone fee structure and broad discretion in inspection and acceptance of the software services, can give the parties a solid basis for a successful development project and standards specific enough to be legally enforceable. The Court of Appeals has favorably cited experts for precisely this proposition.6 For similar reasons, when analyzing a software development contract and relevant facts in a breach of contract analysis, it is often more fruitful to focus on the parties’ adherence to the development process described in the contract rather than the specifications of the software that ultimately goes into production status.

Forum and Choice of Law, Remedies and Source Code

Fully remote work, hybrid work schedules and flexibility in working hours are more widespread than ever across the spectrum of industries. In software contracts, this reality makes it important to understand not just what the developer will do, but where the developer will do the work. In many cases, a consultant will enter into a software development contract, write source code, perform testing and deliver all other necessary services remotely. This begs the question of where the parties will litigate if a dispute arises.

Longstanding choice of law principles such as lex loci contractus are often of little help in resolving disputes arising from contracts for information technology services, particularly where the contracting process and entire course of performance occurred remotely. Moreover, the question of which state’s substantive law will govern is of heightened importance in software contracts, since the copyright preemption analysis is driven by the specific state law claim at issue.⁷ For these reasons, choice of law and venue in a software contract is not just a means of avoiding the expense of litigating on the road, but actually determines the rights available for claims sounding in contract and in tort. For example, if the contract is ultimately deemed unenforceable, then whether an action for quantum meruit is available or preempted by the Copyright Act will turn on the elements of the state law claim at issue, whether the claim is based on a theory of a contract implied in fact, etc.⁸ All of these considerations point to the value of a solid provision stating the governing law for the contract and indicating the venue for disputes.

Likewise, ownership of and access to the source code is a central matter in software contracts, and an area where clarity pays dividends. The use of a third-party escrow agent is an effective, if somewhat dated approach to balancing the parties’ interests in the software. The complexity and expense of an escrow agent can be obviated, however, by use of a more transparent and collaborative approach, such as the developer keeping the source code and data artifacts in a data repository hosted on the client’s server. Regardless of the mechanics of access to the source code, it is advisable to state in the contract with maximum clarity which party owns the software, which party owns updates and configurations to it, and the exact contours of the non-owner’s license to use them. This sort of clarity is in both parties’ best interest and, consequently, is normally possible to achieve in the contract.

Conclusion

Legal work on software contracts involves a variety of challenges, and the dense technical language pervading these agreements often make them seem overwhelming to attorneys. But working closely with IT experts helps a lawyer quickly understand the core purposes underlying the contract and the intended timeline. Through this collaborative approach, lawyers can help structure definite, enforceable contractual standards, identify breaches, determine the availability of remedies and offer sound counsel. |||

STROUD VAUGHN serves as counsel, legal & business affairs, for SESAC Rights Management, Inc., and his practice focuses on contract law and intellectual property.  He has assisted several organizational clients, including the Tennessee Department of Human Services, with contracting for development and implementation of software, access to hosted solutions, and configuration of commercial off-the-shelf solutions.  Vaughn earned his law degree from Belmont University College of Law in 2014.

NOTES

1. See, e.g., Circle C Construction LLC v. Nilsen, 484 S.W.3d 914, 918 (Tenn. 2016).
2. “Practices for Scaling Lean & Agile Development” by Craig Larman and Bas Vodde, pp. 289-296. Pearson Education, Inc. Boston. 2010.
3. ICG Link v. Steen, 363 S.W.3d 533, 544 (Tenn. Ct. App. 2011).
4. ICG Link at 540, 546-7.
5. See “Both Feet on the Ground, Ahead in the Cloud: Practical Considerationsin Contracting for Hosted Services,” Tennessee Bar Journal Select, Dec. 8, 2020, by Stroud Vaughn, www.tba.org/?pg=TBJSelect&pubAction=viewIssue&pubIssueID=7959.
6. ICG Link at 545.
7. See Wrench LLC v. Taco Bell Corp., 256 F.3d 446 (6th Cir. 2001).
8. See, e.g., Brainard v. Vassar, 561 F.Supp.2d 922 (M.D. Tenn. 2008)