Escrow Holds the Key to Encryption

By Robert K. Peddycord

It has been advocated that encryption is an inexpensive, workable alternative to the use of software escrows. Its proponents depict encryption as a cheaper method of protecting the vendor's proprietary code, while at the same time permitting the licensee reasonable access to the code. Certainly, this is an appealing scenario. However, a more thorough analysis of encryption reveals it as only a partial solution. Encryption is more wisely used in appropriate circumstances in conjunction with a well-managed software escrow. Generally, encryption is a process whereby text is encoded with the use of an encryption key. Once encryption occurs, the text becomes understandable only if it is decrypted by the reversal of the encryption function. In other words, the key is used to subtract out the encryption to return the document into understandable text.

If it is assumed the company holding the encrypted code does not have and will not obtain the technical sophistication and cryptography tools to reverse out the encryption without the key, the confidentiality of the code is maintained by the secrecy of the encryption key.

As an example, an encryption arrangement that does not use an escrow would work as follows: "Sensational Software" develops a scheduling program for the corrugated box industry which is licensed to "Big Tree." Sensational installs an executable copy of the program on Big Tree's computer system and delivers to Big Tree a magnetic tape that contains an encrypted copy of the source code. Additionally, Sensational delivers to an officer of Big Tree the encryption key written on a piece of paper. As required by their agreement, the officer deposits the paper containing the encryption key in a safe deposit box with restricted access. The paper is to be removed, and the key used to decrypt the code, only if Sensational goes out of business, stops supporting the software or otherwise breaches its agreement. Many problems can be identified in this scenario that can be solved by careful drafting of the agreement. However, certain problems found in an agreement which depends solely on encryption cannot be cured through contract; whereas these same problems can be solved in a well-designed source code escrow contract. Identified below are examples of some of these problems.

Trust
Unlike an escrow arrangement where a neutral third party holds the source code, the non-escrow encryption arrangement allows the licensee to hold not only the source code, but also the key to decryption.

Such possession is permitted on the assumption that the owner of the source code trusts an officer of the licensee to keep the key safe and separate from the source code. This may be viable when there is some pre-existing relationship between the licensee and the owner; but what if no such relationship exists? 

What if the trusted individual leaves the licensee company or there is a change in control of the company that subjects the trusted individual to unknown or less scrupulous authority? In any of these circumstances, without the requisite trust, the non-escrow encryption procedure leaves the owner of the source code at significant risk. Additionally, if the trust for this arrangement is being placed with the individual officer who receives the encryption key, that individual should assume personal responsibility for the safeguarding and proper use of the key. However, in practice, it may be extremely difficult to cause the trusted individual to accept personal liability for this process.

Release of the key
The biggest argument in support of the non-escrow encryption procedure is that it allows the licensee immediate, unfettered access to the source code if a default condition occurs. However, for most owners of software, this is also the most significant argument against this process. The reason is simple.

If there is a dispute as to whether or not the release condition has occurred, this process allows the owner no opportunity to contest the matter. The key has been withdrawn from its depository, the source code decrypted, and the confidential code revealed and used by the licensee and its employees and consultants before the owner of the software company has any opportunity to protect its interests. All the advantages thus move to the side of the licensee. If this advantage is knowingly desired and acceptable to each party, then the same result can be reached by the use of a source code escrow. The escrow company is instructed that, if it receives a demand from the licensee to release the code, then it should do so immediately. This reaches the same objective as the non-escrow encryption alternative but without the risk that the key and source code can be misused pending the demand for the release.

Administration
Many licensees do not want the administrative burdens involved in encryption processes that do not use escrow. Tracking the dates for the deposits of the updated source code and notifying the depositor to make the updates are tasks that can easily slip through the proverbial cracks. For this reason, they prefer that a third party (the escrow agent) be responsible to calendar, notice and otherwise track the times for the deposits of updated source code.

Many owners of software also prefer to avoid the administrative burdens involved in encryption processes that do not use escrows. For example, if there are multiple licensees registered to one deposit of the source code, an escrow arrangement is much simpler to administer. Instead of having to issue copies of the code and encryption key to each licensee, the owner of the software makes one deposit of the code with the escrow agent, and then merely signs additional documents to add new licensees. This significantly cuts down on administrative time.

Conclusion
The use of encryption can be beneficial in protecting source code. However, in most cases, it is better in conjunction with an escrow, rather than in place of an escrow. The escrow agent can maintain the encryption key, the encrypted code, or both. In this way, the owner of the software and the licensee are equally protected and their agreement can be drafted to anticipate and effectively deal with all applicable issues.

Robert K. Peddycord is a partner with Knight & Peddycord, a San Diego law firm specializing in business and computer law.