Software developers may jealously guard their source code, from time-to-time it may need to be disclosed to others. For example, a developer may be required to disclose source code to another developer who is quoting for the provision of development services; alternatively, source code may need to be disclosed as part of a security review.
Source code is a high-level programming language in which software may be written, which uses words as well as symbols and it is known as “human readable”. Source code is generally compiled or translated into object code, which is the machine-readable form appearing as a sequence of numbers, for it to work electronically.
In the case of systems programmed in high-level languages, application developers may supply software in the source code because the system translates the source code as it is run. This does not fundamentally affect the intended terms of licence, but it does remove from the licensor the additional level of security inherent in most users’ inability to convert object code into source code. However, licensing is infrequently of source code since this reveals the secrets of the intellectual property which is the essence of the software’s value, that is, it enables the technically conversant to understand how the problem which the software has been supplied to solve, has actually been solved. It follows that the provision of this information carries with it a much greater risk of misappropriation. Object code can be analysed by someone with an appropriate level of technical skill, in order to work back to the source code but most users will not have this skill.
Source code is also needed in order to carry out any significant modifications to software, and to enable it to be fully maintained. This is why many users who are licensed to use object code are keen to see any escrow arrangement in place when they license software crucial to their businesses to ensure that they can access source in the event of the software supplier’s insolvency. Some software suppliers will not be prepared to licence their source codes under any circumstances. Others will place a premium price on such a licence, to reflect the fact that the software in question is a significant asset to their business.
A source licence is virtually identically to an object licence; it is simply a “beefed-up” version, intended to bring into consideration the additional factors, which apply to the supply of sources. A pre-requisite to a source licence will often be the existence of a current, valid object licence. Sources are often supplied ‘as is’, without any form of warranty of support on the basis that the licensee is being supplied without source code as a tool to be used for the purposes of maintaining, modifying and perhaps further developing the software. It would therefore be possible for changes to be made outside the scope of any warranty. Licensors will generally confine the use of the software to the user’s business and there will be obligations of confidentiality, coupled with restrictions on any form of commercial exploitative use. Sometimes, there will be a requirement for these obligations to be underwritten by insurance.
Use of a Source-Code Deposit Agreement
Users may ask their suppliers to place a copy of the source code on deposit with a neutral third-party custodian for release to the user in prescribed situations. The agreement governing these arrangements is known as a source-code deposit or “escrow” agreement and it is usually a tripartite agreement between the licensor, the licensee and an independent third party “escrow custodian” who holds a copy of the source code.
The arrangement enables the software owner to protect the confidentiality of the software by giving the end user access to object code under normal conditions, yet at the same time giving their user perceived security by allowing a licence to the source code to be released by the escrow custodian for continuing support in certain clearly defined circumstances.
The principal situation for which the escrow arrangements are effected is that if the supplier goes out of business, the user is entitled to obtain the source code from the escrow custodian for the sole purpose of continuing to use the software, supporting and enhancing it as required. This will not solve all the issues with insolvency, but it will at least allow the user an opportunity it would not have otherwise have for continuing to make use of the software.
For the avoidance of doubt a clause in the licence agreement to state that the user could have the source code in the event of the supplier’s insolvency would not be effective in itself. On liquidation, the licensor company would have no further rights itself to supply source code. Under the terms of the Insolvency Act 1986, the ownership of any remaining assets of the licensor, including source code, will automatically pass to the receiver or liquidator who will be under no obligation to hand it over to anyone. Moreover, the user will have no guarantee that the source has been kept up to date and in a format which would be of any use.
What is Escrow?
Escrow is a legal term often used for agreements of this nature. In essence it means that a third party holds something (traditionally by way of deed) until certain circumstances agreed between the two principal parties occur. Then the third-party delvers it to the designated party. The item is held in ‘escrow’ until the specified event occurs.
Historically, a deed was delivered by being physically handed over. This meant that the person who handed it over considered himself bound by it. But in property matters, a deed was regarded as being delivered when it was signed and sealed. Yet the signing and sealing would take place before the transaction was completed, for example when the money for the land was paid. Once a document had been delivered, it could not be taken back, but there was still the risk that completion might not happen. This is how the concept of ‘escrow’ evolved. The document was signed and sealed and therefore irrevocably delivered but subject to the specified conditions, so that it did not take effect until those conditions had been met.
The concept has also been extended to ‘escrow accounts’, referring to the deposit of funds in a bank. The funds are held on the basis that if a third party can produce evidence that the depositor has an obligation which cannot be discharged from any other fund or in any other way; there is authorisation to release the funds to that third party. This is analogous to the use of the word ‘escrow’ to apply to certain circumstances in which the software is held.
Here the conditions which trigger delivery to the designated party, the license, of the software held ‘in escrow’ by the third party, the escrow custodian, will usually be the licensor’s insolvency, although the circumstances, may be extended to other conditions to trigger the release of the source code.