This article by Hunter Jensen, CEO of Barefoot Solutions, was originally published in the December 2007 edition of PHP Architect, a print magazine for PHP Professionals. It is the first article in a five part series on some of the different legal issues surrounding the web development industry.

If you’re not a real estate agent, chances are that you have never put something in escrow. But using a trusted third party to store your PHP code could be the best way to protect your investment and your intellectual property rights on either side of a licensing agreement.

I was recently asked to produce a fully-functional social networking module for a client’s web application. The catch: our company had six weeks to get it working. After weighing the options – including hiring a small army of programmers to write the software from scratch – we decided the best solution was to license some existing software and spend the six weeks customizing and integrating with the site. The code base was built for a standard LAMP stack, written in classical OO in PHP5 with one caveat: the PHP was encoded using ionCube PHP Encoder. All of the customization was to be done through the extensive web-based administration panel or the extension of very well documented classes, so our ability to customize was still pretty powerful. We were happy with the decision.

But the software was not cheap. And for the small, upstart company that was licensing it to us, we would be their biggest client to date by far. This raised several important questions. What if the company went out of business? What if something later broke that they decided not to fix? What if the company shifts priorities and they stop developing this product? We wouldn’t have any access to the source code. That could be a serious problem.

We needed a solution included in our license agreement before we were ready to sign anything. More than anything, the issue came down to trust. They couldn’t trust us with the source code in fear that we would sell it, give it away, or not protect it and have it stolen from us. But we were unable to trust that they would give us the source code if they were to go bankrupt, stop maintaining the code, or otherwise be in breach of the license agreement. Our solution to the problem was to use a service that I was largely unaware of, as I imagine most other PHP programmers are too. We decided to place the code in Source Code Escrow.

Escrow 101: Who Can You Trust?

When most people hear the word escrow, they think of placing a house in escrow while all of the inspections, credit checks, and other home buying headaches are taking place. Source code escrow is very similar in concept. At its most basic level, escrow involves a trusted third party which will hold on to some property and follow the terms of an escrow agreement. Generally the three players in a source code escrow agreement are the owner, beneficiary, and escrow agent. The owner can be any licensor, developer, or vendor that is somehow providing software to the beneficiary. The beneficiary is the licensee or customer that is the recipient of the software. And finally the escrow agent is some trusted third party, generally an escrow company, which arranges and enforces the escrow agreement. Source code escrow originally came into play to protect the licensees who were receiving the object code from a compiled language like C++ or Java. As PHP developers, object code is not a problem we face, but there are similar situations where an escrow agreement would be appropriate. First, if the code is encoded, obfuscated, or both, it is inaccessible just like object code. If a need for the source code could ever arise, then an escrow agreement might be appropriate. Another applicable situation is when a licensor hosts the software on their own machines. Even if the source code is not encoded, it is still inaccessible, and as such an escrow agreement might be appropriate. This arrangement is becoming more and more prevalent across the webscape as Software as a Service (SAAS) becomes a viable and thriving business model. This model was popularized early on by Salesforce.com, but since then has popped up in many industries from project management (Basecamp, e.g.) to personal financial services (Wesabe, e.g.).

The process of arranging an escrow agreement begins with the owner and the beneficiary deciding on the “Deposit Materials”. These are the materials that are to be deposited with the escrow agent. They would include, at the very minimum, the source code of the software. Often however, more than just the source code is deposited. The owner may also provide other inaccessible materials such as the API documentation, build instructions, and/or any other proprietary tools that may be used for development of the build process. The deposit materials will be included in the escrow agreement, and will be verified in some form by the escrow agent.

In addition to outlining the deposit materials, a complete source code escrow agreement will include a definition of the “Release Conditions”. These are the conditions which, if realized, will cause the escrow agent to initiate their release procedure, which may ultimately end up with releasing the source code to the beneficiary. Release conditions are to be negotiated between the owner and beneficiary. While every escrow agreement is different, some common release conditions include:

• The licensor goes out of business and/or files for bankruptcy and no entity will assume the licensor responsibilities for the software
• Licensor fails to meet the maintenance and update requirements outlined in the license agreement
• Licensor is acquired by another company that does not intend on continuing development

Another essential piece of any source code escrow agreement involves outlining the “Permitted Use” of the source code. If one of the release conditions is met and the deposit materials are released to the beneficiary, those materials are released with a limited license as described by the permitted use clause of the agreement. The most generous permitted use clause would allow the beneficiary to maintain, modify, enhance, or even sell the software. While most agreements generally do not permit the resale of the software, it is common practice to give beneficiaries the right to make modifications. A piece of software would, over time, become unusable if it were not being updated and modified regularly. Like the deposit materials, the permitted use terms are to be negotiated between the owner and the beneficiary, and their respective legal counsels, to fit the needs of their particular arrangement.

Technical Verification: Breathe a Little Easier

While the deposit materials, release conditions, and permitted use clauses represent the major pieces of a source code escrow agreement, there are some intricacies that are worthy of discussion in all three of these areas. For instance, as a beneficiary, how do I know that the owner has deposited what he claims to have deposited? Any escrow company will do a physical inspection of the deposit materials to make sure that everything which is claimed is present and accounted for. For instance, if 3 CDs and a binder of documentation are claimed to have been submitted, the escrow agent will physically verify that all 3 CDs and the binder are in fact deposited, and that the CDs are readable. But what would stop the owner from submitting 3 blank CDs? Or encrypted code? To account for these issues is a service offered by most IT escrow firms named “Technical Verification”. The level of technical verification, like anything else, differs from agreement to agreement, but there are some common scenarios:

• Physical Verification – as described above, this is offered by any legitimate escrow agent
• File Verification – the escrow agent (or an independent contractor) can examine all media and report filenames and file sizes so that the beneficiary can confirm the presence of all necessary source files. They can go further by verifying that the code is not encrypted and/or obfuscated by randomly viewing files.
• Build Verification – many escrow agreements require the owner to submit build instructions with the source code. These instructions should be sufficient for a technically advanced person to successfully build an executable application. For a web-based PHP application, this would involve any server configuration settings, different application versions (PHP, MySQL, Apache, etc.), and any other information necessary to get a working version of the web application up and running. Then, this application can be run through a test plan agreed upon by both parties.

In addition to the verification of deposit materials, it also important that the source code be updated regularly as the production version of the software gets updated. This can get tricky. If the escrow code is not being updated regularly, eventually it will become outdated and rendered fairly useless. Ideally, the source code in escrow should always be kept up to date with the software that the licensee is using. It can be tough for a beneficiary to know when the production software has been updated however. Particularly in a SaaS environment, where updates may be made as frequently as daily, it is not practical to expect the owner to update the escrow with every update made to the production code. A compromise that can be made in the escrow agreement is a requirement of software updates on a regular interval. For instance, in software that is being updated at least weekly, requiring that the escrow be updated monthly, on a specific day each month, would ensure that the code in escrow does not become outdated for the beneficiary without creating an unreasonable amount of overhead for the owner. The owner could also be required to send notice to the beneficiary each time that the escrow is updated, so that the licensee can properly monitor the situation.

Release Conditions: Time to Share the Wealth.

The particulars of the release conditions, and specifically the procedure followed when a release condition is met, is another issue that needs to be considered when drafting the source code agreement. Most escrow agents will have certain standard release procedures, but they can be fine tuned to meet the needs of the licensee. The most common release procedure is a three step process. First, the beneficiary submits a claim that a release condition has been met. For instance, suppose that the license agreement requires the licensor provide support 24/7. If the licensee were to submit a support email, and two weeks pass without response, then the licensor would be in breach of their license agreement and a release condition will have been met. The beneficiary would then submit this claim with the necessary and sufficient evidence to the escrow agent for review. If the escrow agent does confirm that a release condition has been met, then they will enact the agreed upon release procedure. Generally, the owner has a specified amount of time to respond to the claim or make repairs (like answer the support email). If they do not dispute the claim and do not repair the issue in the given time period, then the escrow agent will release all deposit materials to the beneficiary. However, if the owner does dispute the claim, then the escrow agreement should have a policy outlined for the resolution of this dispute. This can rely on the escrow agent to make the final decision, professional arbitration, or in a worst case scenario the parties can rely on the legal system to make a decision on the dispute. The deposit materials will not be released until the dispute has been resolved.

Now you can see the problem that this could create for the beneficiary. If their claim is disputed, they could be tied up in arbitration or legal struggles for a long period of time. During this time, their software could be rendered useless and they could potentially lose any number of things including money, traffic, or reputation. For this reason many escrow agents also offer an immediate release procedure. With an immediate release clause in the escrow agreement, the beneficiary will receive the deposit materials immediately upon submission of a claim that a release condition has been met. The owner will still have the ability to dispute claims and go to some form of arbitration, but the beneficiary will be in possession of the deposit materials during the dispute resolution. If the dispute is resolved in favor of the owner, then the beneficiary would be required to return all deposit materials to the escrow agent. Further, in that situation it is customary for the beneficiary to pay for any damages and legal fees incurred due to the improper claim.

Picking Up the Check

One final source of contention when drafting an escrow agreement is the age old question – who pays? Of all of the issues that can come up through this process, this issue is the toughest to solve. Because it is generally the licensee that wants the escrow, it is often assumed that they will need to foot the bill. However, it could be in the best interest of the licensor to setup a source code escrow for all licensees, in which case it is only fitting that they pay the fees. This issue should be resolved during the license agreement negotiation, and possibly before an escrow agent is first contacted.

While a source code escrow agreement is usually initiated by the licensee, it has benefits for both parties involved. For licensees, the benefits are fairly obvious. They are able to avoid the risk of relying on another company’s success for their own business to thrive. It also provides a system for monitoring and ensuring regular maintenance and updates. For licensors, a source code escrow agreement can alleviate concerns of potential customers without having to assume the risk of distributing source code and other proprietary materials. It can also provide some validation of ownership of technology assets and intellectual property and create an IP trail, which is outside the scope of this article but an interesting topic in its own right. So while they are not appropriate in all licensor/licensee relationships, they clearly have their place in software development and can be a very useful tool.

Share this article