INSIGHT: Red Flag Language in Technology Contracts During Due Diligence

Is your company about to sign a service agreement with a third-party service provider under which the provider will access and use technology of your company? Have your company’s applicable third-party contracts been checked to see if any consents of the contract counterparties are required?

The contracts under which your company uses technology every day, from the mundane to the critical, may contain hidden restrictions on the third party’s access and use for your benefit under the services contract.

There is an endless number of arrangements a customer could have with its third-party service providers, but in this article, we will discuss the case where the customer authorizes a service provider to access and use licensed software either while remaining at the customer site, or by moving it to the service provider’s site.

More specifically, we explore some of the issues and language in the customer’s license agreements with those third-party software providers that should be flagged and reviewed during pre-signing due diligence.

Definitions

The first place to check in the license agreement is the definitions. Generally, how the agreement defines “Authorized User,” “Use,” or “Affiliate” is a good indicator as to where the analysis might come out.

In best-case scenarios, “Users” will include employees, consultants, clients, external users, contractors, and agents. However, be aware that the company may also be subject to increased fees in order to increase the number of users or allow the use by the service provider.

Additionally, the “User” definition may limit permitted users (including contractors) to use the software on a particular piece of hardware, at a certain location, or in connection with a certain function. Other relevant definitions need to be read to see if they present any issues based on the structure of your deal.

License Grant

This is one of the key provisions to review. If the required access and use rights are not included in the license grant, or are specifically excluded, you may need a consent from the licensor. If the license grant states that the licensee’s rights are “non-transferable” or “non-sublicensable,” you will need to consider whether the structure of your deal poses an issue or risk.

In the case where the service provider comes on site to use the software and the definition of “Authorized User” includes contractors or third-party users, for instance, then your risk assessment and analysis may be that the license right has not been “transferred.”

However, you may well conclude that there may be a transfer under the same circumstances where the definition of “Authorized User” is limited to company “Personnel” or “Customers.”

If the license grant restricts the required access and use by the service provider, then consent will most likely be required. If the license grant, alternatively, is ambiguous or unclear on its permitted uses and restrictions, your analysis could similarly conclude that consent is required if the risk of being wrong is too great and your risk assessment influences the analysis into obtaining consent.

Outsourcing Language

Where the agreement allows your company’s service providers, vendors, and contractors to access and use the software for the purposes of providing services to your company, or where there is explicit permission for your company to enter into technology outsourcing arrangements, then there should be no need to obtain any consent from the licensor.

It is important to note that your company will be responsible for any breach of the license agreement by the service provider, so the service provider’s obligations under the services agreement with your company (including those relating to confidentiality and data security) should be structured to mirror or cover your company’s corresponding obligations under the license agreement.

Confidentiality

Another restriction that the due diligence team might come across is in the confidentiality provision of the license agreement, where your company may be restricted in its use and disclosure of the licensor’s confidential information (which may well be defined to include the licensed software and related documentation).

For example, the license agreement may contain a covenant that your company will not disclose or publish any of the licensor’s confidential information to third parties or that it must restrict access to the licensor’s confidential information to those of the company’s officers, directors or employees who have a need to know the confidential information in connection with the company’s license rights and obligations under the license agreement.

These types of restrictive covenants may trigger the need for a consent by the licensor.

Infringement Indemnity

A less prominent trigger of the need for consent may be found in the licensor’s infringement indemnity clause. If the licensor is relieved of its infringement defense and indemnity obligations if the licensed software is used in some combination of hardware or software not originally approved by the vendor (or a similar concept), then use by the third-party service provider on its systems may potentially result in the loss of the infringement defense and indemnity.

Depending on your company’s level of comfort with potentially losing this kind of protection, your company may conclude that consent is recommended.

Other provisions may also raise consent issues. In short, a proper due diligence analysis must take a look at all of the controlling documents between licensor and licensee in order to accurately determine whether consent, notice, or something in between is required.

The key point is to get out in front of the analysis by focusing on what is occurring in your technology solution, what software and other technology is involved, and what third-party agreements are in play. Your due diligence team should not only be looking for anticipated issues, but should also be on alert for unexpected issues as well.

This column does not necessarily reflect the opinion of The Bureau of National Affairs, Inc. or its owners.

Author Information

Michael L. Pillion is a partner with Morgan, Lewis & Bockius LLP. He is also the founding partner and assistant leader of the firm’s technology, outsourcing, and commercial transactions practice. Pillion brings more than 30 years of experience navigating high-stakes transactions to his technology, outsourcing, and commercial transactions practice.

Zachary Feldman is an attorney with Morgan, Lewis & Bockius LLP and focuses on technology and outsourcing matters. He advises clients on domestic and international outsourcing service agreements for a variety of business processes.