Assume you’re the MIS Director for your company and you’ve discovered a program that brilliantly solves your most nagging systems dilemma. You’ve seen the demos and examined the product; there’s nothing like it; it has no competition. The problem is that the vendor is a one-product start-up shop with five employees and a president who’s still in grad school. They’re bright, but whether their company will be around in a year to support their product is anyone’s guess. Like most vendors, they’re happy to license as many copies of their object code as you have workstations. You say you want the source code so your staff can maintain the program. They say no, but you can’t make the investment you’d like to without it.
Or suppose you’re a software publisher with a niche product, good sales and an established user base. To stay current, you need to add some new functions that your competitors have already included in their latest versions. You’ve done the make v. buy analysis and decided you need to go outside. Unfortunately, your vendor of choice has just appealed a multi-million dollar adverse court judgment and may not be able to survive if they lose the appeal. They, of course, assure you they will win and be around to support their product for as long as the sun shines. You think you’d better have access to the source code just in case.
(If you’ve read this far you probably know the difference between source code and object code. If you don’t: source code is the computer program as originally written by the programmer, usually a human, in a particular programming language. It can be printed out as text and people who understand the programming language can read and make sense of it. For a computer to be able to understand and execute its instructions, it must be converted into object code, or electrical impulses consisting of combinations of ‘0’s and ‘1’s readable directly by the computer. The object code is the final instruction to the computer.)
Back to our examples. Clearly, the user and the vendor have competing interests. Without the source code, the user can’t make any modifications to the licensed software. As a result, the user is completely dependent on the vendor for maintenance, such as bug fixes, updates, revisions and enhancements. This dependence makes the issue of the vendor’s long term viability extremely critical. If the vendor ceases to provide maintenance, either by choice or because it goes out of business, the source code may never become available and the user could be stuck with a software albatross that quickly loses its value and usefulness. If the software is considered a mission critical component of a company’s systems but can’t be maintained, the results could be disastrous for the user.
The vendor, on the other hand, regards its source code as its corporate crown jewel. The vendor’s concern is that if it makes the source code available to any user, it could easily be copied (copyright law and contractual restrictions notwithstanding) or made available to anyone over the Internet. Software companies can be driven to ruin by such things. A major source of a vendor’s revenue can be the maintenance that it alone can provide to its user base if it is the lone keeper of its source code.
Source Code Escrow Agreements
A common and generally accepted means of resolving the conflicting interests of the user and software vendor described above is for the parties to place the source code in escrow with an independent third party escrow agent and enter into a written escrow agreement between each other and the escrow agent.
Escrow agreements generally obligate the vendor to deposit with the escrow agent updated versions of the source code as the software is revised in order to ensure that the source code held in escrow is kept current. This sounds reasonable enough, but sometime presents practical problems. Since software maintenance is often an ongoing process, the vendor may not be diligent in depositing the latest versions of the source code, especially if it is having financial problems. To protect the user, some escrow agreements allow the user (or the escrow agent if it has sufficient technical skills), to periodically test the deposited source code to ensure that it corresponds to the latest version of the program’s object code.
Escrow agreements typically provide that the escrow agent will hold the source code in confidence as a trade secret of the vendor and will release a copy to the user only upon the occurrence of specifically described events, usually involving (i) the vendor going out of business; (ii) the vendor’s discontinuance or inadequate performance of maintenance; or (iii) the vendor’s bankruptcy.
If the vendor goes out of business, the escrow agent can easily verify this fact and should not object to the delivery of the source code to the user.
However, where the user contends that it is entitled to the source code because the vendor has failed to meet its maintenance obligations, the escrow agent will usually refuse to release the source code until after the user has sued the vendor and obtained a court determination that the vendor has failed to maintain the product. Since litigation can take years, the vendor and user can agree in the escrow agreement to arbitrate the issue of inadequate maintenance out of court. Or they can agree that the user may have conditional, restricted use of the source code after posting a bond to cover any damages the user or escrow agent may suffer.
The vendor’s bankruptcy has historically meant bad news for the user because of the broad powers a trustee in bankruptcy has to protect the assets of the bankrupt vendor, which might consist solely of its software. Under the bankruptcy laws, “executory” contracts such as license agreements containing continuing warranty and maintenance obligations, can be rejected by the trustee in bankruptcy. However, in 1989, Congress passed the Intellectual Property Bankruptcy Protection Act, which affords some level of protection to users facing a vendor’s bankruptcy. The statute prohibits the bankruptcy trustee from blocking enforcement of a user’s contract rights with a third party, such as an escrow agent, with respect to those items (i.e., the source code) the user needs to exercise its rights to use the software under the original license agreement with the bankrupt vendor.
Access to source code will almost always be a complicated and sensitive issue for negotiation between the vendor and user in any important software transaction. Source code escrow agreements are a widely used tool to balance the divergent interests of the parties and allow them to do business together.
Attorney Eric Freibrun specializes in Computer law and Intellectual Property protection, providing legal services to information technology vendors and users. Tel.: 847-562-0099; Fax: 847-562-0033; E-mail: firstname.lastname@example.org.