What is a Software Maintenance Agreement?
A software maintenance agreement, sometimes called a maintenance agreement, is a legal contract between the owner or licensor of a piece of software and the end user or licensee of that software. These agreements are often vital to the success of a software licensing deal, specifying critical elements of the licensing relationship. When done correctly, a software maintenance agreement can be fantastically important. When done incorrectly, however, a software maintenance agreement can be disastrous and bring a software ecosystem to a grinding halt.
The vast majority of software contracts are governed by the Uniform Commercial Code ("UCC"), which provides, among other things, general rules regarding contract formation under Article 2 of the UCC. The UCC typically applies to software sales. Therefore, parties who decide to enter into a software maintenance agreement generally do so because a maintenance agreement provides unique benefits not otherwise addressed by the UCC.
Software maintenance agreements are managed by the Special Committee on Software Contracting Practices of the IEEE Computer Society, which is responsible for developing standard practices that govern the content of a software maintenance agreement. A Software Maintenance Agreement usually includes four distinct elements: (i) a "scope" agreement; (ii) an "operations" agreement; (iii) a "change" agreement; and (iv) a "termination" agreement. The "scope" agreement describes the nature of the relationship between the parties and what rights and privileges each party is entitled to with respect to the other. A "operations" agreement describes the operational procedures governing how work is done in a software maintenance relationship. A "change" agreement describes how alterations can be made to the software and/or the relationship. Finally, a "termination" agreement describes the procedure for ending the relationship and how work on the software is to be properly terminated.
A wide variety of business entities are involved in software maintenance agreements. Most commonly, a software vendor who has a single piece of software offering will enter into a maintenance agreement with a single company that will install and maintain a licensed software system . The maintenance agreement will most likely include details on specifics, such as – everything from how upgrades to the software are to be delivered, to what sort of training will be provided by the vendor to the customer. Alternatively, larger software vendors may use a software maintenance agreement template or framework agreement that covers all of its software maintenance offerings and is then customized for each software licensee or customer.
Software maintenance agreements are generally distinct from software licensing agreements, although a particular software contract may contain elements of both. More specifically, a software maintenance agreement generally focuses on the terms, conditions, and procedures for maintaining, modifying, and developing the software that is already in use. On the other hand, a licensing agreement generally covers issues related to protecting the intellectual property rights of the software vendor.
For example, software licensing agreements generally contain provisions for compensating the software vendor for the use of its intellectual property, including royalties for the use of the vendor’s copyrighted software. Software maintenance agreements, on the other hand, generally focus on the definition of the duties of the parties toward the continued usability of the software being maintained.
In short, a software maintenance agreement is a contract between a software vendor and a software user to determine the nature of the relationship between them with respect to the use, maintenance, and operation of the software that has been delivered. Typically, software is delivered as an extraordinarily complex and interdependent system of code, with many modules or features dependent upon one another in order to perform the software’s intended functionality. Therefore, the general purpose of a software maintenance agreement is to set forth the agreed upon scope of effort for the maintenance of that software, as well as to establish procedures for making changes to the software and to the relationship between the parties.
Essential Elements of Software Maintenance Agreements
A software maintenance agreement outlines the relationship between a software vendor and its customer post-implementation—including how software updates, bug fixes, and new functionality will be delivered, what support channels are available if a problem arises, and how the customer can seek assistance in getting those upgrades or bug fixes.
The key elements of a software maintenance agreement include:
Terms of Service. Terms of service establish and address the legal parameters within which a vendor can provide maintenance and support services. Major concerns include ownership of derivative works, limitations on liability, and dispute resolution. The terms of service should also address maintenance and support deliverables (such as patches, updates, and upgrades) and any associated costs. If the terms of service do not specifically carve out one of those items, the law may treat it as covered by the agreement. While discussing the terms of service, be sure to review the vendor’s service level policies (or SLAs), or equivalent service levels, for responsiveness to critical issues. A skilled provider will have published SLAs that address urgent issues—such as the response and resolution times for system outages, business critical errors, and other high-priority problems—providing the customer with a target service level.
Version Policy. Version policy, as the name suggests, outlines which versions of the software will be supported under the maintenance program. Version policies can be strict—supporting only the current version of the software—or more flexible—a common approach is to support the current and prior versions, and, at times, even earlier versions. It’s important to discuss these issues up front so that the vendor provides maintenance and support for all applicable programs.
Business Hours. Different vendors will have different hours of availability and a good maintenance agreement will address the hours the vendor will be available to provide support. There may be different requirements for support, meaning that some issues may not be addressed until after a certain hour. For example, a vendor’s support structure may include a help desk with limited availability. In addition, an SLA may require that support affects certain problems such as critical failures or complete downtime immediately or within a certain number of hours.
Support. This portion of the agreement describes how support will be structured and who will have access to the various support services offered by the vendor. It may also discuss a number of other issues, including the various tiers of support being offered, where support can be obtained (e.g., via phone, email, or online, and if onsite support will be available), how a customer accesses the various support options, how changes to support procedures are handled, the amount of error correction assistance provided, and whether direct access to developers will be available.
Common Legal Concerns with Software Maintenance
The legal issues surrounding software maintenance agreements are varied and can be the source of disputes, especially when either end of the agreement has high expectations. In addition to clear and concise definitions of the obligations of both vendor and customer, the following issues should be considered when drafting the agreement:
Limitation of Liability
Often, software maintenance agreements will contain a "limitation of liability" clause which seeks to cap the liability of the vendor in the event of a claim, and indemnification provisions dealing with how legal claims brought against one party by a third party are handled if they arise out of the conduct of the other party. In the former case, vendors need to balance against the high costs of software litigation with exposing themselves to substantial liability which may be outside their control, such as bugs in the software that can’t be fixed. Customers, on the other hand, need to ensure that their rights are adequately protected should their customer base suffer loss or damages arising out of a bug that the vendor hasn’t yet remedied. In the latter case, oftentimes a vendor will seek to have the commercial general liability insurance policy of the customer kick in for any claims arising out of the "scope of work", whilst the customer will seek to include the vendor in its insurance coverage if the actions of the vendor (if egregious) lead to a successful claim against the customer.
Intellectual Property
Intellectual property (IP) clauses are important provisions in a software maintenance agreement because they set out the respective obligations of the parties to protect their own IP, as well as set out the restrictions on use of, and claim to, any IP created during the course of the software maintenance. In particular, special care must be taken where one party is licensed to use the software, but holds no claim to the copyright of the software. Allowing a licensee to make changes to the code may result in their becoming the owner of the code (subject to the agreement of the parties). Allowing a licensee to make changes "generally" to the code may create the same result, unless the vendor can clearly demonstrate that the licensee only added on to the pre-existing code – requiring a definitive definition of what amendments can and cannot be made. Similarly, if the vendor is using the customer’s equipment and/or existing IT infrastructure to maintain the software, the vendor will likely become the owner of any useful items created in the course of the maintenance work (i.e. any hardware upgrades), unless expressly excluded.
Termination
Termination provisions tend to be particularly contentious in a software maintenance agreement, since they tend to be unilateral in nature – a customer can often terminate the agreement for cause, but tends to have no right to terminate for convenience. Similarly, a vendor tends to have the right to terminate for convenience without cause, but does not generally have a right to terminate except in the event of default by the customer. As a result, customers seeking the use of enterprise software products for the long haul may be in a difficult position with respect to their ability to terminate the agreement and migrate to a new solution.
Best Practices for Drafting Software Maintenance Agreements
When it comes to drafting clear and enforceable software maintenance agreements, several best practices can help software developers protect their proprietary rights and ensure that the agreement is easily understood by both parties.
First and foremost, it is important to use precise, concise language that accurately reflects the terms and conditions of the agreement. Avoid using ambiguous or vague terms that could be interpreted in different ways, leading to confusion or misunderstandings down the line. For example, instead of stating that the developer will provide "support" for the software, specify what types of support will be offered (e.g., telephone support, email support, on-site support) and what hours support will be available.
Another key practice is to define all important terms used in the agreement. For instance, the agreement should define the term "software" to include not only the initial version of the software but also any upgrades or updates that are released during the term of the agreement. It should also define the scope of the maintenance services to be provided, including any restrictions on what types of modifications or enhancements may be made to the software .
It is also crucial to include provisions that allow for flexibility in the event that technology or business needs change over time. For example, the agreement could include a clause that allows either party to terminate the agreement with a certain amount of notice if the other party fails to meet its obligations. Or, the agreement could include a provision for renegotiating the terms of the agreement every year, or every other year, to account for changes in technology, labor costs, or other factors.
Other best practices for drafting effective software maintenance agreements include:
Including provisions for confidentiality and nondisclosure
Specifying the governing law for the agreement
Including a dispute resolution clause
Clearly outlining the dispute resolution process
Establishing the confidentiality
Specifying how disputes will be resolved if they cannot be settled amicably
Defining the scope of the confidentiality obligations and the duration of those obligations
Including procedures for returning or destroying confidential information when the agreement ends
By following these and other best practices, software developers can create software maintenance agreements that are clear, concise, and enforceable.
The Importance of SLAs in Software Maintenance
Service Level Agreements (SLAs) are another form of follow-on agreement that come into play in the software maintenance context. The vendor’s responsibilities are set forth through SLAs that dictate, in robot terms, the robot’s obligations. To prevent the customer from terminating the agreement immediately after the software is working perfectly, agreements often specify a period of time (e.g., six months) after deployment when the customer may not terminate for reasons related to performance (within some minimum threshold). As a result, the SLAs stand as a general proof of the supplier’s capabilities to keep their obligations in the event of a quality or performance dispute.
SLAs should clearly state what SLAs are included in the software maintenance agreement, including things such as percentage uptime of the application(s) and available support hours. If the supplier offers multiple SLAs for tiered levels of application performance, customer will have a choice regarding the level of SLA they will accept. Generally, a greater degree of performance from the supplier will require a greater price from the purchaser. When multiple SLAs are available, customers must carefully compare the pricing structure and the percentage of uptime, since the difference in cost may not be worth it for the customer.
SLAs often specify the methods of complaint resolution as well as the method of measurement. Sometimes SLAs also provide for liability caps, meaning that if the supplier does not perform at the SLA level, the liability of the supplier will be capped at some level that is below 100%. For example, an SLA might provide that any failure to meet a specified SLA will result in a credit against future SLAs, or offset against other fees owed to the supplier.
Most commonly, suppliers will agree to respond to help desk tickets within a certain time of day, or within a specified time of receiving a ticket. These response times should be specified early in the software maintenance agreement and discussed thoroughly. For example, if urgent tickets must be processes within 24 hours, the purchaser must be aware of both the SLA level they are accepting, and the supplier’s response time capabilities. It may be acceptable for an SLA to state that the supplier will use its best efforts to respond within that timeframe, but it would be unreasonable for the SLA to state that the supplier guarantees a response will be provided within that timeframe. Likely, a customer would be required to tolerate some variances in response time to the extent the supplier gives notice of a delay and a reason for the delay. If the supplier does not provide notice to the customer of the delay, and the delay results in a significant negative impact on the customer’s business, the supplier could argue that the customer was aware of the SLA requirements and assumed the consequences of non-compliance. Of course, a thoughtful court might find an SLA that effectively requires timely notice to be illusory and a bad public policy.
Negotiating Terms of a Software Maintenance Agreement
For any enterprise seeking to purchase a software maintenance agreement, costs are an obvious consideration. As a starting point, enterprise should look for a cost schedule based on two factors: the number of software licenses covered and, if applicable, the number of concurrent users on the system. The benefits of a cost schedule are twofold: first, it will provide a useful basis for comparison with other vendors; and second, it will facilitate clear allocation of costs among disparate budgetary line items one and two years hence. Of course, the overarching goal is to minimize software maintenance costs so that they are in line with the expected and justified utility of the software. There is an important caveat, however: don’t sign a software maintenance agreement simply in order to obtain a lower up-front cost for software development. There is a risk that someone will then need to hire programmers to fix it.
The cost of a software maintenance agreement will inevitably vary not just by license type (and thus number), but also by vendor. As a result, enterprises should consider at least one of the following strategies to balance vendor and client interests. First, an enterprise might decide to pay the costs of one software maintenance agreement on a monthly basis and the other on an annual basis, thereby improving cash flow. Second, an enterprise might choose a multi-year agreement for one license and an annual agreement for the other, thereby improving both cash flow and its bargaining position in the future. Finally, an enterprise might consider a "co-use" agreement whereby a minimum amount of payment is required, but in which the entity purchasing the agreement pays only for actual usage, at a significant discount to the list price of the software. The benefit of co-use agreements is that they effectively allow clients to pay selectively for the maintenance of one or two key software components, while conserving cash.
In addition to costs, one question that enterprises frequently ask is "What is an acceptable support time?" Like cost , support times are vendor-dependent and vary widely from a few hours per month to virtually 24/7. There are also two important factors that may further drive support times. First, the nature of the software will impact needed support. For example, the greater the software’s impact on client operations, the more critical its availability and thus the greater the need for 24/7 support. Second, the number of licenses will also impact needed support times. For example, the more licenses, the greater the likelihood that maximum utilization will occur during the same hours, making 24/7 support more important. Of course, the benefit of longer support times comes at a cost.
Finally, one question that enterprises frequently ask is "How long should a vendor ideally take to respond to a problem?" "Response rates" (e.g., eight hours), have become more common in the past decade and are favored by many purchasers. "Response rates" can be objectively enforced and are often easier to measure than "resolution" times (e.g., three days). However, the notion that an individual user or business unit should get its own set of response obligations is not only entirely impractical given the size of many systems, it also ignores the fact that response times must be reasonable and commensurate with the reliability of the underlying system. There is no benefit, for example, to having a 24/7 critical response if the software is down for two days every month. Instead, any need for 24/7 support should be driven by an appropriate assessment of the software and overall system architecture.
For all of the reasons noted above and others, an enterprise should consider minimum levels of maintenance services, such as monthly hardware checks or quarterly security patches. The goal is to balance both parties’ interests in a workable way. A pint of blood will seem like a pretty good deal if the alternatives are HIV and hepatitis. Similarly, though a deal may seem strikingly favorable to one party, there may be some unknown (or, worse yet, undisclosed) risk. With an effective software maintenance agreement, at least some of that risk can be managed and prudently allocated.