Most businesses – from startups to SMEs to multi-nationals, and from private family-owned businesses to public corporations – will use software as a tool to grow: as a customer purchasing it to use or incorporate into a product offering, or as a developer or provider. Increasingly, businesses are using cloud-based technologies to take advantage of the critical IT infrastructure and e-commerce tools and efficiencies the cloud has enabled. Whether in the cloud (note the authors’ bias: we wrote this article on Google Docs) or not, this software use typically means the business will enter a software licensing agreement. Here are 10 key terms that should be clear in every software licensing agreement.

1. Intellectual property (IP) rights

For many businesses, large and small, their intellectual property is one of their most valuable assets. If the service provider will have access to or will use the customer’s IP in any way, the agreement should confirm that the customer owns the IP, limit how and when the provider can use it, and deal with the service provider’s breaches of those obligations. Similarly, the service provider will, in most cases, own IP rights in their services, and will seek to subject the customer to strict license terms when using those services. 

2. Privacy & data security obligations

Businesses must be prepared to avoid – and respond to – privacy and data security breaches. Canadian and international privacy and data breach laws are stringent and the consequences for breaching them can be harsh. If a service provider will have access to or collect “personal information” from the customer, it’s critical the agreement adequately address the service provider’s privacy and data security obligations and deal with breaches of those obligations. And if the service provider might subcontract any services and the subcontractor will have access to the customer’s data or personal information, the customer should endeavor to negotiate the requirement that such subcontracting is subject to the customer’s consent and agreement, and ideally require the subcontractor to enter into an agreement directly with the customer subjecting it to the same security obligations and breach consequences as those applicable to the service provider.

3. The scope

All contracts benefit from ample and unambiguous definitions (or if that’s not practical then by reference to clear criteria, such as when assessing product or service acceptance) and thus the avoidance of disputes resulting from differing interpretations. But agreeing on clear and unambiguous definitions can be a challenge – particularly in the context of agile development.

Agile developments are an increasingly popular approach. In an agile development, the customer essentially pays for a process instead of a traditional well-specified product or service (that is, waterfall development). The objective is for the project process to be as flexible as possible, and to avoid restricting the parties from identifying and pursuing solutions that arise during – and not necessarily at the beginning of – the development process. While this flexibility has many benefits, it also presents contractual challenges: it’s often difficult or impossible to fully define key terms, such as “services”, “milestones” or “deliverables”, “specifications” and “user acceptance testing”, before any work, generally including a design phase, has begun. And the difficulty of setting out contractual obligations with the degree of clarity the parties typically desire means both parties are exposed to greater risk in terms of the project’s “success”.

From the customer’s perspective, this risk stems from the unknowns associated with the services the service provider is to perform coupled with the general obligation to pay for such services regardless of the results. Therefore, the design phase of a project can be most critical in terms of adding definition to both the project scope – and the contract terms. Customers must carefully manage agile development projects because there’s inherently less certainty, putting more onus on the customer to adequately resource them and ensure that decisions, particularly during the design phase, can be made quickly and on an informed basis – and unambiguously documented. With key terms defined, a customer should negotiate the right to approve each project milestone – in many cases before making corresponding payments. This should include any final deliverables related to testing and/or “go live” phases to ensure there are no critical issues before making the final payment, which generally serves as a “holdback”.

Many service providers have expanded their offerings so customers have the option to purchase the core offering plus whatever additional features suit the customer’s needs and budget. In the cloud context in particular, as many products have evolved to offer additional features, customers are becoming more and more likely to accept off-the-shelf products without customizations.

4. The “services” being purchased / sold

Throughout the service delivery period (or in some cases only at its end), the service provider should deliver to the customer what the customer expected to receive, that is, one or more “deliverables”. It’s in both parties’ interest for that expectation to be clearly established – and clearly defined in the agreement.

However, the required services aren’t always readily apparent (particularly in the case of agile development) to either party. Cloud-based services can be wide-ranging: beyond the software-as-a-service offerings and infrastructure or platform-as-a-service, a customer will often require implementation services and support services, along with other specific services. In turn, legal teams can struggle to establish clear contractual definitions of key terms, such as “deliverables”, “specifications”, and “acceptance criteria”, based on the terms to which the business parties have agreed or set out in a high-level statement of work. Yet clarity around these key definitions is critically important to obtain the necessary level of detail in the agreements so they don’t become the source of future disputes if the parties disagree on what work is or was to be completed and/or paid for.

Therefore, despite the challenges, the customer must know what it needs (or what it needs to find out). From there, the contractual agreement should carefully define the services to be provided as clearly and unambiguously as is reasonably possible.

5. Liability limitations

Service providers will (and should) always limit their liability in an agreement. In addition to making them responsible for less, liability limitations also give service providers more certainty with respect to unforeseen future costs. Liability caps are a common method of limiting liability; for example, a provider might seek to “cap” its liability to the fees paid by the customer in the year prior to the event that caused the loss. Customers, on the other hand, typically seek comfort in knowing the allocation of risk the service provider is willing to bear. As a general rule, customers should seek to negotiate exclusions to liability limitations for breaches or losses that might be particularly sensitive or costly, such as confidentiality or privacy breaches.  Customers should also consider what costs to which they would be subject in the worst-case scenario. In many cases, a one-year cap would not reasonably allocate risk between the parties.

6. Warranty limitations

Agreements typically include warranty terms – and limitations – with the goal of achieving a balance between the objectives of both the service provider and the customer, giving each the reasonable protection they seek.

Service providers generally prefer to limit their warranties, and for good reason. Things can and will go wrong: software can’t be perfectly developed and bugs and the need for patches are inevitable. Furthermore, customers often expect, sometimes unreasonably or erroneously, software to be customizable or to work effectively with internal or other third party software. And sometimes they “tweak” the end product themselves, inadvertently causing problems to its core functionality. At the same time, there’s some onus on service providers to ensure they take reasonable precautions to do the work for which they were hired, free from disruptive or significant glitches. Software providers commonly endeavor to limit their warranty to a performance of the work to the boilerplate “industry standards”.

Customers, however, look to warranties for comfort that the “deliverables” will work as the service provider has described. And many will consider a warranty of work as meeting “industry standards” to be ambiguous – and not that comforting. Customers will therefore attempt to negotiate the warranty in more detail to give them the comfort they seek, with as few limitations as possible.

7. Project governance

Customers should seek to include in the agreement the right to receive notice in the event of a delay – particularly if the service provider claims the customer is the cause of the delay. This helps ensure the service provider can’t allow any such delays to occur without proactively identifying them to the customer; such notice alone might be enough to trigger a quick resolution of the issue.

For customers, disputes pose a threat to the success of a software development project. These projects can disrupt an organization; for example, enterprise resource planning (ERP) cloud services inherently disrupt the status quo. A high level of internal project team support tends to result in a more successful project generally, but particularly so when disputes arise. Disputes offer detractors an opportunity to derail the project; strong leadership typically allows disputes to be more effectively and efficiently resolved. In many cases, it’s therefore beneficial to detail in the agreement which individuals are responsible for dealing with disputes, the mechanisms for formalizing a dispute, how long the parties have to address issues (including delays) and if not resolved, how the parties can escalate disputes.

8. The price

Pricing is another key deal point. In an implementation context, it’s beneficial to the customer to negotiate a breakdown of the service provider’s fees by the specific “deliverables” to be performed. The parties can also negotiate fixed rates. This is particularly attractive to suppliers if there’s a question of the time and material costs that might be involved, as there typically is. This could also be an attractive option for customers, particularly those that seek price certainty.

After the parties sign a contract and work begins, the parties should work together to manage costs. For example, although all parties generally prefer to avoid unnecessary paperwork, a provider could deliver a regular report to show work completed versus work projected. This is intended to give a customer on-going transparency in the project’s progress (including with respect to its budget), so it can hold a service provider more accountable, among other things. This also gives the service provider confidence that the customer regularly see progress, and the value it’s creating for the customer. The parties should identify any such reporting and accountability tools in advance, and bake them into the contract.

9. The term of the agreement

The duration (a.k.a. the “term”) of any agreement is generally among a deal’s most important terms. Cloud products and services have given customers more comfort committing to longer terms because the products and services don’t have the same shelf life they once had: in theory, cloud products and services can be updated indefinitely with minimal, or no, additional cost or disruption to users’ operations. And the longer the term to which the user is willing to commit, the more certainty the service provider has with respect to on-going revenues, giving parties the opportunity to negotiate discounted rates in exchange for longer commitments. But how long is too long? This depends on a number of factors, including the user’s culture, the service provider’s reputation, the level of service the service provider can guarantee, what the competition offers and how easily the customer can transition to another competing service provider. Other relevant factors include the length of the initial term, how renewal periods and price increases will be addressed, and each party’s termination rights.

10. Open source usage

Most software these days includes open source components. Open source is valuable to both software developers, helping drive down development time, and to customers, helping drive down costs. But open source might not be as reliable as newly developed software (for example, it might not be verified for deficiencies), and it’s subject to its own license terms that could be restrictive or abnormal. Service providers using open source  should position themselves to both provide information to customers and demonstrate they’ve complied with the terms of open source usage by creating and maintaining records detailing: the components within their software that are, or that derive from, open source; where they first obtained such coding (for example, the online URL); the applicable license terms apply and the copyright owner; and into what they incorporated the open source. Customers should position themselves to assess the risks associated with the service provider’s use of open source by actively inquiring whether the service provider has used or will use open source. If so, the customer should obtain the details from the service provider and seek a representation that the service provider has and will comply with the terms and conditions of the open source usage. If not, the customer should seek a representation from the service provider that it hasn’t (or won’t) use open source.

---

Please contact your McInnes Cooper lawyer or any member of the Technology Law Team @ McInnes Cooper to discuss this topic or any other legal issue.

---

McInnes Cooper has prepared this document for information only; it is not intended to be legal advice. You should consult McInnes Cooper about your unique circumstances before acting on this information. McInnes Cooper excludes all liability for anything contained in this document and any use you make of it.

© McInnes Cooper, 2018. All rights reserved. McInnes Cooper owns the copyright in this document. You may reproduce and distribute this document in its entirety as long as you do not alter the form or the content and you give McInnes Cooper credit for it. You must obtain McInnes Cooper’s consent for any other form of reproduction or distribution. Email us at [email protected] to request our consent.