The software escrow (also called source code escrow) is one of the complex concepts existing in the realm of IT agreements. Despite being an advanced notion, this article will attempt to bring it down to earth and explain it in a simple and practical manner. Moreover, after reading this text you may decide for yourself whether a software escrow resembles a prenuptial agreement 🙂
What exactly is a source code escrow?
As we already observed in Tips on Tech Contracts #2, in a software licensing agreement the licensee only receives the object code version of the application but not the source code. This could pose certain risks in case the vendor abruptly ceases the maintenance of the software. Then, in order for the customer to perform the maintenance itself or through a third-party vendor, access to the source code will be needed. This is where source code escrow comes into play as a possible solution.
The source code escrow is an arrangement that is aimed to act as a form of insurance against certain unforeseen circumstances. However, instead of a release of funds it provides a remedy in the form of release of source code. The escrow arrangement reduces the risk of unforeseen developments when it comes to the actions or the situation of the software vendor – such as the vendor ceasing the support and maintenance of the software or going bankrupt. It also brings a layer of predictability into the relations of the parties as they know in advance what exact measures will follow in case the mentioned circumstances materialize.
The source code escrow is a 3-party agreement and the parties to it are: i) the depositor (the software licensor), ii) the beneficiary (the software licensee) and iii) the escrow agent, acting as a neutral third party.
It has to be mentioned that the escrow agreement is reliant on the existence of a main agreement between the parties. This main agreement can be a software licensing agreement or a contract for software development where the vendor retains ownership of the IP rights in the newly developed software.
What are the responsibilities of the parties?
After signing the escrow agreement the software licensor is obliged to deposit a copy of the source code and all related materials and documentation into a depository that is under the control of the source code agent. Additionally, there is an obligation for the licensor to continuously deposit (over a regular period of time such as every 3 or 6 months) any modifications to the source code such as updates and upgrades. The idea is that the source code in the depository should be a mirrored version of the current running code within the licensed application used by the beneficiary.
The main obligation of the beneficiary is to keep the escrow agent notified when a new version of the software application is put to use so that a new deposit with the updated material will have to take place from the vendor.
The main obligations of the escrow agent are to store the deposited source code in a secure physical and electronic environment and to perform its release to the beneficiary if the agreed release events materialize. Additionally, the escrow agent should keep the parties notified about the deposits of code and materials that are placed in its depository. The agent could also perform additional services such as code verification. Verification testing is a procedure where the deposited source code and related materials are reviewed for completeness and accuracy. Additionally, it is verified whether the deposited source code can actually be compiled into a properly functioning application. This provides an additional layer of security to the beneficiary that in case of an actual release event, the source code will be successfully compiled and maintained. If you are on the licensee side, you should definitely insist on adding verification services to the escrow arrangement. It will cost you a bit more but it could save you significant headaches in the long run.
What is a release event?
One of the most important underlying elements in a source code escrow arrangement is the choice of release events. A release event is an occurrence that triggers the release of the source code to the beneficiary. Typical examples of release events are the bankruptcy of the software vendor, a situation where it ceases the maintenance and support of the software or a material breach of the main agreement by the vendor which is related to the application. However, the specifics of the main agreement may warrant that additional release events are added. This will depend entirely on the will of the parties. If you are on the vendor side, you should try to minimize the release events to the established industry standards – going out of business or cessation of software support and maintenance. If you are on the customer side, you may want to also add a material breach of the agreement that is related to the application and maybe even various forms of significant deterioration of the quality of the application-related services provided by the vendor.
Who should cover the costs for the source code escrow?
This is entirely up to the will of the parties to the main agreement – the licensor and the licensee. In my view, as the licensee is the one that can actually benefit from an escrow arrangement it should bear the larger portion of the escrow costs or all of them. As for the vendor, it steps into the escrow arrangement without any fault of its own and embraces the risk of potential release of the source code which is a key asset in its business. Adding the burden of also fully covering the escrow costs on top of this would be disproportionate. Therefore, if you are on the vendor side, in my view you should always try to pass the costs entirely (or at least predominantly) onto the licensee.
How to assess if you actually need an escrow?
When the software licensee is assessing the necessity of an escrow it should answer a list of questions. First, is the application mission critical software for the licensee? What would be the impact on its business if the software is no longer maintained and supported and bugs and more serious issues are not fixed? Would there be a disruption in operations or loss of revenue or even reputational damage? This all should be carefully analyzed by the licensee. If the licensed software is COTS (commercial off-the-shelf software), then an escrow arrangement is probably not a good idea and most large vendors would outright deny the request. However, software escrows are definitely a good fit for customized software that is designed to meet the peculiar needs of the customer. Another important step is the assessment of the software vendor and its reputation, its market position and financial viability and track record. Finally, the licensee should ask itself what if the vendor disappears tomorrow? How long would it need to find a replacement provider? Does the licensee have a competent in-house team of programmers that would be able to maintain and support the software in case of source code release? Based on the answers to all above-mentioned questions, the need for an escrow or the lack of it will easily become clear. Additionally, some of the answers will give further insight on what exact provisions should be added to the escrow arrangement in order to provide stronger protection for the beneficiary.
You must be logged in to post a comment.