This article was originally published in the Massachusetts Lawyers Weekly
The tremendous increase in the number of computer hardware and software vendors and business users over the last few years has made it increasingly common for software related licenses to be negotiated between vendors and users. This is a dramatic departure from the practice in the not so distant past, when a relatively small number of vendors had the market power to impose one-sided, non-negotiable license agreements on most purchasers. Today, subject to the vendor possessing an unusual degree of market dominance in the product line, most aspects of a software licensing transaction are open to negotiation. This article is an introduction to what is often one of the most difficult issues in software license negotiations, the licensee’s access to the vendor’s source code.
What Is Source Code?
The term “source code” refers to a computer program in human-readable form. It is the immediate work product of the efforts of one or more programmers. However, the source code of a computer program is almost never delivered to purchasers or licensees. Instead, the program is first “compiled” by a computer process into a computer-readable form referred to as “object code”. A user in the possession of a program in object code form is unable to make any changes in the program short of undertaking an extremely lengthy and expensive technical process known as “decompilation”. Thus, if a defect or “bug” is found or if a modification, no matter how minor, needs to be made, the purchaser must rely on the vendor to alter the source code to effect the change in the program’s source code, re-compile the program and provide the purchaser with a new copy of the object code.
Maintaining the confidentiality of source code is a matter of the utmost importance to software licensors. Program source code from commercial vendors may represent thousands of hours of labor, and contain valuable design concepts and algorithms.[1] Often, a software company’s source code is its most important asset. Almost invariably, source code is treated as a trade secret by its owner.
Why Is Access To Program Source Code Important To Licensees?
As the complexity and cost of a software program increase, so does the licensee’s need to be guaranteed source code access in the case of the vendor’s inability or failure to maintain the program. Why does a licensee need this access? First, it is widely acknowledged in the computer industry that few if any programs above a moderate degree of complexity are bug-free. Most computer programs require on-going “program maintenance” as long as they are in use.[2] Second, in the case of a customized or semi-customized product, the licensee may be dependent on the vendor to make even the simplest changes to accommodate the licensee’s business. For example, simply changing a field name in a data base application or the format of a report may require access to source code. If the licensor is unable or unwilling to make modifications to the source code, the licensee may find itself stuck with expensive software that can’t be debugged, refined or upgraded.
Reconciling These Differences In Computer Contract Negotiations
One solution to the competing interests of the software developer and the user is the inclusion of a reasonable source code escrow agreement in the program license agreement. Typically, a bank or comparable institution serves as the escrow agent. The escrow agreement is a three-party contract which provides that certain events, such as the vendor’s bankruptcy or failure to maintain the program, will trigger the escrow agent’s release of the source code to the licensee. The escrow agent is treated as a bailee for hire. Although a source code escrow agreement increases the risk of unauthorized disclosure of the source code, by the careful choice of an escrow agent and the use of appropriate confidentiality safeguards the vendor can remain protected, and the user who must have adequate provisions for source code access can be satisfied.
What Events Trigger The Release?
Once a licensor engaged in software license negotiations agrees in principle to a source code escrow agreement, the critical remaining issues left to resolve are the events which will trigger release and the terms of the escrow agent’s obligation to release the source code. At one extreme, the licensor may insist that only its bankruptcy or insolvency should be cause for the release of source code from escrow. At the other extreme, the licensee may take the position that any failure or inability of the licensor to perform maintenance obligations, either during a warranty period or under a software maintenance agreement, should trigger release.[3]
Given the fact that it is the licensor’s failure to maintain the licensed program which the licensee fears, the best compromise of this issue is to provide for release upon maintenance failure, independent of the vendor’s financial condition. In fact, a provision that triggers access to source code only in the event of a bankruptcy may not be enforceable under the Bankruptcy Act. A bankruptcy trustee may be able to void a provision that affects the legal rights of a bankrupt as a result of the bankruptcy petition itself.[4]
However, “maintenance failure” must be defined in such a way as to eliminate the licensor’s justifiable apprehension that the licensee will demand and obtain release of the source code based on a trivial failure of the licensor to discharge maintenance obligations. Typically, the licensee will take the position that release should be triggered by a “substantial” failure to provide maintenance, while the licensor will insist on a “best efforts” standard. The actual standard must be determined on a case-by-case basis based on the relative bargaining strengths of the parties in the context of the negotiations.[5]
An issue closely related to the standard for release is where and how the escrow agent is required to release the source code. Typically, the licensee would prefer that the escrow agent be required to release at the licensee’s request, placing the burden on the licensor to file suit to enjoin the release. The licensor, of course, would prefer that it have the power to block release following the licensee’s demand upon the escrow agent, thereby forcing the licensee to bring suit. This issue is most fairly resolved by requiring the escrow agent not to release the source code upon the licensee’s request if the licensor protests the release. As a practical matter this will require the licensee to seek a court order or cause the licensor to file for declaratory relief to establish that there is no basis for release. Although this approach places the burden on the licensee to change the status quo, it is usually the most reasonable resolution of this problem.
Authentication and Updates
Assume the following scenario: A licensee negotiates what appears to be a favorable escrow agreement to an expensive piece of software and its business becomes heavily reliant on the software. Sometime later a significant bug is discovered, which the vendor, now in financial difficulty or perhaps bankrupt, is unable or unwilling to remedy. The user, intending to hire its own programmers to fix the problem, obtains the source code from the escrow agent only to discover that the code is for a now obsolete version of the program in which many old bugs still exist or, even worse, significant portions of the source code are missing from the program.
How can this scenario be avoided? First, of course, the license agreement should warrant the authenticity of the escrowed source code and represent that the code will be updated at the same time that updated object code is provided to the licensee. An additional measure of safety is provided by independent authentication by a third-party expert who is subject to a confidentiality agreement. Ideally, both the original deposit and source code updates should be authenticated by the expert. Lastly, programmer-level documentation should be included with the source code deposit and be subject to similar update and certification procedures.
ENDNOTES
[1] Estimates are that it takes as much as $8 million to develop and market a microcomputer program. See “Software: The New Driving Force”, BUS. WEEK, Feb. 27, 1984, at 77.
[2] As one influential treatise explains:
The total cost of maintaining a widely used program is typically 40 percent or more of the cost of developing it. …[O]ld bugs found and solved in previous releases tend to reappear in a new release. New functions of the new release turn out to have defects. These things get shaken out, and all goes well for several months. Then the bug rate begins to climb again. …Fixing a defect has a substantial (20-50 percent) chance of introducing another so the whole process is two steps forward and one step back.
Frederic P. Brooks, Jr., THE MYTHICAL MAN MONTH 121-22 (1982). The author of this book was the manager of the development of the IBM/System 360 operating system software.
[3] Licensees will sometimes take the position that source code should be released if the licensor transfers its rights in the product, so that the licensor no longer can provide maintenance. However, such a provision generally is not advisable. First, this creates a threat to the confidentiality of the source code which may inhibit the licensor’s ability to sell the software. Second, there is no reason to assume before the fact that the licensor will not continue to provide adequate maintenance.
[4] The automatic stay imposed by the filing of a bankruptcy petition may also prevent a transfer of the escrowed source code. See, e.g., In re Heckler Land Development Corp ., 16 B.R. 856 (E. D. Pa. 1981).
[5] One issue to be alert to here is whether the source code will be released if a technical bug appears which the licensor, despite its best efforts, is unable to correct. Is the licensee entitled to obtain access to the source code and turn its own programmers loose on the problem, or must it be satisfied with the licensor’s efforts? One answer to this problem is to include objective tests. For example, the license agreement may provide that if a program bug causing execution to abort continues for 45 days after notification to vendor, the escrowed source code shall be released to the licensee. However, in practice a provision of this nature is likely only where the licensee has a great deal of bargaining power.