Background
Most businesses, even smaller ones, have at least one software license agreement that is mission-critical. A source code escrow is an arrangement that can provide protection to the business should the software provider go out of business or discontinue support and/or maintenance for the licensed software. Even though the dot com bubble has burst, it is still very common to find smaller and/or newly formed software companies with valuable and useful software for use in niche areas and otherwise.
Source code escrows can reduce or eliminate the risk of doing business with such a small or new company. Source code escrows are generally negotiated as a part of the initial software license agreement. They can also be entered into after the license agreement has been signed, but a licensee has much less leverage at that point to negotiate favorable terms.
Typically, a source code agreement is entered into among the software provider, the business licensee and an unrelated third-party escrow agent. There are many more experienced software escrow agents available now than there were 10 years ago, and many banks will also provide this service.
Under the typical software license, a business only receives access to the object code for the software being licensed. When there is a source code escrow agreement in place, the source code to the software is provided to a third party escrow agent. The escrow agent is authorized to release the source code to the licensee upon the occurrence of certain triggering events.
Agreement Terms
The most heavily negotiated provisions in a source code escrow agreement are those relating to the events that trigger the release of the source code. These triggering events are negotiable but almost always include the bankruptcy of the software provider, the discontinuance of business by the provider and the joint written instructions of the provider and the licensee to a release of the code.
You should also consider the following events as possible triggers to a release:
- The laying off of substantially all of the employees of the provider, or substantially all of the employees that provide support, maintenance and/or development for the licensed software. This is often the first sign that a company is in trouble, and as a licensee, you want notice of this as soon as possible.
- The failure to provide maintenance and/or support in accordance with the provider’s agreements relating to the same.
- A change in control of the provider.
- A discontinuance of the type of software licensed by a business.
- The default of the provider under the software license agreement, after an opportunity to cure.
Other Typical Agreement Provisions
Source code escrow agreements are typically drafted so that there is little or no risk to the escrow agent. Under the agreement, if an event occurs that might trigger a source code release, the escrow agent will generally require written notice of the event from the licensee. Most agreements provide that the escrow agent give written notice to the software provider of the licensee’s allegation that a triggering event has occurred. The software provider then has the opportunity to dispute the allegation of the licensee, and this is generally played out through mandatory arbitration between the provider and licensee. In my experience, if the provider’s ship is truly sinking, the provider typically wants to try to take care of its licensees and will very often co-operate with the licensee and sign a joint agreement to release the code.
When released, unless the escrow agreement provides otherwise, the licensee obtains the right to continue to use the software as provided under the original license; provided, however, that the licensee also has the right to do its own maintenance, support, upgrades, etc., or hire a third party to do the same.
Tips for Negotiating a Successful Source Code Escrow Agreement
- Make sure the escrow agreement can survive the bankruptcy of a software provider, since that is one of the primary reasons a licensee would enter into a source code escrow agreement. In that regard, we recommend that the license granted through the escrow (i.e., allowing the licensee to use the source code to maintain, support and upgrade the software) be a current license, which is just not exercisable until there is a triggering event. The escrow agreement should also have the following language, which will give the licensee certain benefits under the federal bankruptcy laws:
The parties desire this Agreement to be supplementary to the [Software License Agreement] pursuant to 11 United States [Bankruptcy] Code, Section 365(n).
- Think through the triggering events and make sure they fit well with the software provider you have chosen and that they reflect what might really happen. Don’t just rely on the boilerplate triggering events in other agreements.
- If the escrow agreement involves software development, in addition to a software license, a licensee should insist that deposits of the source code be made on a regular basis throughout the development, such as once a month or once every 60 days. Normally it would make sense to wait until the development is complete to require that the source code be deposited, but it is not unusual for a software company to fail halfway into a development.
- Make sure the escrow agent is experienced and reputable.
- Make sure your escrow agreement is crystal clear about the rights of the licensee after the source code has been released. The licensee is still using the source code under a license, and in cases where the provider is defunct, the licensee generally wants to find a third-party replacement for the provider. In my experience, the best place to look for assistance when the worst happens is with the former employees of the provider. They are usually anxious for work and are the most knowledgeable about the software, so it pays to keep in close contact with the employees of your provider.
Alternatives
A business can avoid a source code escrow by obtaining a source code license directly from the provider. This license must give the business the flexibility it needs to move forward should the provider go out of business. In most cases, providers are unwilling to grant source code licenses or they are cost-prohibitive. However, I have been surprised in some cases, and try to remember to ask the question of my business clients when we are working on a software deal.
Another possible approach is to obtain a security interest in the software to secure the obligations of the provider under the license agreement. I have yet to be able to achieve this, since most providers already have bank financing, and the bank has long ago perfected its security interest in the software.
There are situations when the alternatives discussed above may work, but typically a source code agreement is the best means of minimizing risk for businesses in connection with their mission-critical third-party software.