In a perfect world, all technology vendors would present their clients with balanced legal agreements that perfectly represent the commercial deal between the parties and fully meet the client’s business and legal requirements. Unfortunately, we don’t live in a perfect world, and experience has shown that some vendors are better than others at creating transparent and fair contracts. Based on my own experience, the following list may be helpful to counsel acting on behalf of users in negotiating technology services agreements.
1. RFPs and vendor proposals do matter.
If the client began the contracting process by issuing a Request for Proposal (RFP) and then awarding the deal to the winning vendor based on the vendor’s proposal, then it is critical to incorporate the vendor’s proposal in the contract by reference. This ensures that the extensive promises made by the vendor in its response to the RFP are actually included in the contract. This is not only fair to the client but fair to all the other proponents that were not chosen for the transaction. The winning vendor’s proposal is not supposed to be a marketing bluff: clients do rely upon the representations and promises made in such documents, and the successful proponent should be held accountable.
Unfortunately, some vendors do attempt to disavow their own proposals, even going so far as to say that their responses are not legal contracts that did not pass through the vendor’s own legal approval, and so cannot be incorporated into the final contract. This approach seemingly undercuts the trust process at the beginning of the relationship and strikes me as a red flag that the vendor may be acting unscrupulously and seeking to distance themselves from the various commitments made in their proposal, potentially including pricing and other key assurances. If the client accepts this and decides to proceed with such vendor regardless, it will be important for the client to scrupulously ensure that all of the critical components contained in the vendor’s proposal (and the requirements of the client’s RFP) are actually expressly included in the vendor’s contract, including those related to security/cyber resilience, location of vendor personnel, service levels, certifications, etc.
2. Read the SOW(s).
The Statement of Work (SOW) is the document that describes, in very plain and detailed language, the scope of the actual deliverables and services to be provided by the vendor, applicable project phases/timelines/milestones, pricing, the various responsibilities of the parties, any assumptions/dependencies, staffing, compensation to be paid by the client and any other salient business terms. Unfortunately, SOWs are often the place where some vendors try to reject critical legal and business terms otherwise contained in the main body of the services agreement, through the insertion of net new (and flatly contradictory) terms. This includes the repudiation of legal representations/warranties, the addition of different payment and termination provisions (and sometimes inclusion of robust termination fees), deemed acceptance provisions, attempts to override service levels, etc.
Equally problematic are SOWs that are poorly drafted with many capitalized and undefined terms, vague or no real vendor obligations (or merely commitments to define critical technological or other requirements after the SOWs are signed by the parties—what lawyers like to call “agreements to agree”) and no actual timelines/deadlines. While many lawyers are not comfortable drafting SOWs, it is a vast error not to have client-side tech lawyers do at least one review of the draft SOW before signing with a view to eliminate intentional or otherwise inadvertent language that contradicts the main legal document or otherwise undercuts it.
3. Understand the vendor’s services.
It is important for lawyers counselling clients in the tech space to understand which services/technology are under the control of the vendor in question, versus the portions that are under the control of the vendor’s own affiliates, or any third-party subcontractors of the vendor and other large outsourcing providers. Such an understanding is crucial from the perspective of the flow-down conditions that one should include in the technology services agreement. Vendors should be fully responsible (and liable) for the actions and omissions of their own affiliates and direct subcontractors, particularly in the areas of privacy, cybersecurity, and performance. However, it will be more difficult for vendors to make bespoke promises on behalf of larger vendors, such as Microsoft and Amazon.
Depending on their own regulatory/compliance requirements, some clients may wish to control whether the vendor can assign some of its rights and performance obligations under the relevant agreement to certain approved affiliates or control the use of subcontractors, i.e., only to those located in certain geographic locations/countries or control where their client/user data is being processed. All of this must be understood and documented in the technology contract signed by the vendor.
4. Use the right form of technology agreement.
There are multiple considerations concerning the form of the technology agreement. Firstly, some vendors use a cascade of interrelated and interdependent agreements to form their contract, so it is critical for client counsel to review all of them and understand their order of precedence to ensure that amendments are made to various documents as necessary.
Secondly, certain large vendors employ omnibus “one-size fits all” contracts that incorporate various international terms that are inappropriate for the particular transaction. These include global data protection agreements and services agreements that (inappropriately) reference and hold US and Canadian customers responsible for complying with European data protection laws, anti-corruption law, anti-bribery laws, antislavery laws, export controls and other non-relevant provisions. Thus, clients should insist that their vendors use localized services agreements that contain appropriate terms regarding governing laws, jurisdictions, applicable data protection laws (including mandatory data/security breach notification provisions, including timelines) so that the client can satisfy its own regulatory and legal requirements. If localized versions of the services agreement are not available, then the client and its counsel should factor in the additional time required to negotiate the necessary amendments to make them so.
Lastly, the negotiated amendments must be appropriately incorporated into the overriding/master vendor document, as many standard vendor tech contracts contain a myriad of hyperlinks to ever-changing standard form agreements located on the vendor’s website that would override and contradict these carefully negotiated amendments. Be especially careful to ensure that the relevant Order Form/document specifically references the amended Master Services Agreement and related Exhibits rather than boilerplate standard form terms.
5. Open-source licenses are real agreements, and compliance matters.
While I am a proponent of the use of open-source software (OSS) in technology offerings, I remain dismayed by those vendors that deny their usage of OSS, or otherwise plead ignorance that such OSS is governed by actual OSS licenses, each with their own legal requirements and compliance obligations. While litigation involving OSS is relatively rare, it does occur, as evidenced by the recent 2022 case Software Freedom Conservancy Inc. v. Vizio Inc. In this decision, the US District Court for the Central District of California confirmed that the Software Freedom Conservancy could proceed on a breach of contract claim against product maker Vizio for using OSS (licensed under the GNU General Public License Version 2 and the GNU Lesser General Public License Version 2.1.) in violation of those agreements, confirming the validity of OSS agreements as both copyright licenses and as contractual agreements, each with separate remedies. In other words, OSS licenses are real legal agreements.
Accordingly, if the vendor does use OSS, its technology contracts should contain explicit representations and warranties that confirm the vendor’s usage of such OSS complies with the applicable OSS licenses that governs such code on an ongoing basis to ensure that the client is not in breach of any such OSS licenses through its use. Moreover, client counsel should also seek an indemnity from the vendor if such vendor is in breach of any applicable OSS license, uses any incorrect OSS license or incorrectly combines them in a way that makes the client susceptible to any damages/claims.
6. Future-proof your technology agreement as much as possible.
Technology contracts exist in a rapidly changing environment, and it is important to recognize that the tech transaction does not end at contract execution. As much as possible, tech contracts should be drafted in ways that ensure critical terms remain relevant during the life of the agreement. References to crucial privacy and other legislation should contain language that may be amended or replaced. References to intellectual property representations/warranties and indemnities should not refer to patents that were granted at the date of the agreement’s execution, but instead should be ongoing. The contract should also allow for parties to manage technological change through provisions regarding change management and should contain appropriate governance provisions for ongoing monitoring of performance, and periodic re-evaluation and adjustments, if required, to service levels and other mutually agreed service considerations.
Other recommended provisions include informal and formal dispute resolution, and scheduling periodic meetings with the vendor to get insight as to new product roadmaps, development, etc. While this may make the contract longer, it is worth it if the agreement provides an appropriate vehicle to further manage customer risk, forestall commercial disputes and account for necessary changes during the life cycle of the business arrangement.
7. Anticipate and manage the exit.
Lastly, all good things must come to an end, and tech agreements are notorious for ignoring the exit, as the parties don’t want to deal with the prospective divorce during the “honeymoon” phase of negotiating the original contract. However, preparing for an orderly and a smooth exit is a critical concern for most clients, especially those that may become heavily dependent on their vendor. If the client anticipates it will require a wind-down phase to transition off the vendor’s services and seek a replacement provider, then they must build this requirement into the contract, including the length of the termination assistance period, any changes to the services, the fees for such termination assistance services (if different from the standard fees), whether a transition assistance plan is required, and any limitations that could impact the client’s right to obtain such ongoing services.
The return of customer data, including timing, format, and any related costs, should also be addressed, as well as any ongoing right of the vendor to use client data post-termination/expiration, including client generated data, even in any anonymized/de-identified form. Clients should also ensure through their legal agreements that customer data is never “held hostage” in the event of any fee disputes or otherwise. The tech contract should also robustly address the secure destruction/deletion of all client data and any other critical exit-related terms, including which limited provisions of the agreement (representations/warranties, limitations of liability, indemnities, confidentiality, audit rights, etc.) should survive termination/expiration of the agreement (and for how long). There should be no surprises.
