In this digital and technological corporate world, having a plan B in case your software or computer program license goes wrong is a must. Can a customer successfully leverage its position, by entering into an escrow agreement with the licensor? How does the source code escrow work, anyway? When can the source escrow be released to the licensee?
1. What is software escrow and source code escrow?
1.1. What is source code?
Source code is the version of software as it is originally written (i.e. typed into a computer) by a human in plain text (i.e. human readable alphanumeric characters), according to the Linux Information Project.
The notion of source code may also be taken more broadly, to include machine code and notations in graphical languages, neither of which are textual in nature.
For example, during a presentation to peers or potential clients, the software creator may ascertain from the outset that, ‟for the purpose of clarity, ‟source code” is taken to mean any fully executable description of a software system. It is therefore construed to include machine code, very high level languages and executable graphical representations of systems”.
Often, there are several steps of program translation or minification (i.e. the process of removing all unnecessary characters from the source code of interpreted programming languages or markup languages, without changing its functionality) between the original source code typed by a human and an executable program.
Source code is primarily used as input to the process that produces an executable computer programme (i.e. it is compiled or interpreted). Hence, computer programmers often find it useful to review existing source code to learn about programming techniques. So much so, that sharing of source code between developers is frequently cited as a contributing factor to the maturation of their programming skills.
Moreover, porting software to other computer platforms is usually prohibitively difficult – if not impossible – without source code.
1.2. Legal status of software, computer programs and source code
In the United Kingdom, section 3 (Literary, dramatic and musical works) of the Copyright, Designs and Patents Act 1988 (‟CDPA 1988”) provides that among works which are protected by copyright, are ‟computer programs”, ‟preparatory design material for a computer program” and ‟databases” (i.e. collections of independent works, data or other materials which are arranged in a systematic or methodical way and are individually accessible by electronic or other means).
Section 3A of the CDPA 1988 provides that the standard for copyright protection is higher, for databases, than for other ‟literary works”, since they must be original (i.e. by reason of the selection or arrangement of the contents of the database, the database constitutes the author’s own intellectual creation). Since the CDPA 1988 has no equivalent provision for computer programs, it is common knowledge that the provisions of section 3A of the CDPA 1988, relating to originality, apply to both databases and computer programs.
Moreover, the European Directive on the legal protection of databases (Directive 96/9/EC) and the Computer Directive (Directive 91/250/EEC) confirm these higher standards of originality for computer programs and databases, in the sense that they are the author’s own intellectual creation. This is a higher standard of originality than ‟skill, labour and judgment”.
Article L112-2 of the French intellectual property code (‟IPC”) provides that softwares, including preliminary conception work, are deemed to be ‘works from the mind’ protected by copyright. That copyright protection includes source code.
Both in France and the UK, the duration of copyright for software and computer programs is 70 years after the death of the author or, if the author is a legal entity, from the date on which the software was made public.
Copyright is acquired automatically in France and the UK, upon creation of the software or computer program, without any need for registration of such intellectual property right.
Both under English and French law, computer programs are regarded as not protectable via other registered intellectual property rights, such as patents. Indeed, section 1(2) (c) of the Patents Act 1977 (‟PA 1977”) lists computer programs among the things that are not regarded as being inventions “as such”. Article L611-10 of the IPC does the same in France.
1.3. Software escrow / source code escrow
Since authors of software and computer programs – which include source code – own the copyright to their work, they can licence these works. Indeed, the author has the right to grant customers and users of his software some of his exclusive rights in form of software licensing.
While some softwares are ‟open source”, i.e. free to use, distribute, modify and study, most softwares are ‟proprietary”, i.e. privately owned, restricted and, sometimes, kept secret.
For proprietary software, the only way for a user to have lawful access to it is by obtaining a license to use from its author.
When some very large sums of money are exchanged, between the licensor (i.e. the author of the software and source code) and its licensees (i.e. the users of such software and source code), a precautionary measure may be required by the latter: software escrow.
It is the deposit of software source code with a third-party escrow agent, such as Iron Mountain or SES. The source code is securely administered by a trusted, neutral third party to protect the developer’s intellectual property, while at the same time keeping a copy safe for the licensees in case anything happens, such as the licensor no longer being able to support the software or going into bankruptcy. If that situation materialises, the licensees request a release of the source code from the escrow account and are able to keep their businesses up and running. This escrow solution effectively gives the licensee control of the source code and options to move forward.
2. How do you put source code escrow in place?
Many organisations have a standing policy to require software developers to escrow source code of products the organisations are licensing.
Therefore, alongside the licensing agreement to use the computer program, in-house or external lawyers of the licensees also negotiate the terms of an escrow agreement pursuant to which the source code of that computer program will be put in escrow with a trusted third party.
3. Is it worth requesting source code escrow alongside a software license?
Only a small percentage of escrows are ever released: Iron Mountain, the dominant escrow agent in the USA, has thousands of escrow accounts and more than 45,000 customers worldwide that have stored their software and source code with them. Over the 10-year period from 1990 to 1999, Iron Mountain released 96 escrow accounts, less than 10 per year.
Just as well, because escrow agreements are entered into as a kind of insurance policy, only to be used in case something goes very wrong at the licensor’s company, which triggers one of the release events (insolvency, case of force majeure, death of the computer developer, etc.).
However, one valid cons is that most escrowed source code is defective: often, upon release, source code fails to provide adequate protection because it is outdated, defective or fails to meet the licensee’s needs. According to Iron Mountain again, 97.4 percent of all analysed escrow material deposits have been found incomplete and 74 percent have required additional input from developers to be compiled. This is a valid point and licensees of the software, who insist on getting an escrow agreement as well, must insert some clauses in the escrow agreement whereby the escrowed source code is tested on a very regular basis by both the licensee and the licensor, in order to ensure that such escrowed source code will be usable as soon as one ‟release event”, set out in the escrow agreement, materialises. The licensor should have an obligation of result to maintain the escrowed source code up-to-date and fully operational, throughout the duration of the escrow agreement.
Another point of caution is that licensees may lack the expertise to use the released source code. Even if the licensor has been diligent and the released source code is properly updated, well-documented and fully operational, most licensees lack the technical resources or capability to utilise the source code upon release. The licensees may work around this problem by either hiring an engineer who has the technical knowledge to make the most of that released source code (bearing in mind that most software licensing agreements bar licensees from poaching licensor’s employees during the term of the license) or instructing a third-party software company. The best and most economical approach is to be as autonomous as possible, as a licensee, by developing in-house expertise on the workings of the software, and its source code, even before one of the release events materialises.
Another identified problem is that software licensors may prevent the timely release of the escrowed source code by imposing some unilateral conditions to the release, such as the vendor having to provide its written prior approval before the source code is released by the escrow agent, upon the materialisation of a release event. Additionally, many escrow agreements require parties to participate in lengthy alternative dispute resolution proceedings, such as arbitration or mediation, in the event of a dispute relating to the release of the source code. A commonly disputed issue is whether a release event actually occurred, even when the software licensor has gone into bankruptcy! The long delay and expensive legal battle needed to obtain the source code release, may become very heavy burdens for a licensee, compounded by the difficulty to keep the licensee’s computer program and software working – as the licensor, and its technical support, have faded away. In order to avoid such delays and complications in the release of the escrowed source code, the terms of the escrow agreement must initially be reviewed, and negotiated, by an IT lawyer experienced in this area, so that all clauses are watertight and can be executed immediately and in a smooth manner, upon the occurrence of a release event.
Another cost consideration is that the expenses related to the opening and maintenance of an escrow agreement are high, and typically borne by the licensee. In addition to the fees paid to the escrow agent, the customer will often incur significant legal expenses related to the drafting and negotiation of the escrow agreement, as explained above. Software licensors being really resistant to providing their proprietary source code to anyone, escrow agreements are often subjects of long negotiations, before they are signed. However, while doing a costs/benefits analysis of getting the source code escrow, the licensee must assess how much it would cost, in case a release event occurred (bankruptcy of the licensor, case of force majeure, etc) but no prior software escrow had been put in place. If the licensee has made a considerable investment in the software, the cost to protect this asset via an escrow agreement may be trivial.
Some companies say that, since they now rely on Software-as-a-Service solutions (‟SaaS”) for some of their IT needs and functionalities, there is no need for software escrow because the SaaS relies on a cloud-based system. However, SaaS implies that you need to think about both the software and your company’s data, which is indeed stored on the cloud – which adds a level of complexity. Since most SaaS provider’s business continuity/disaster recovery plans do not extend to a company’s application and data, some new insurance products have entered the market, combining both the source code escrow and disaster recovery and risk management solution. For example, Iron Mountain markets its SaaSProtect Solutions for business continuity.
To conclude, licensees need to conduct a costs/benefits analysis of having an escrow agreement in place, alongside the licensing agreement of their major software applications, in respect of each computer program which is perceived as absolutely paramount to the economic survival, and business continuity, of the licensees. Once they have balanced out the pros and cons of putting in place escrow agreements, they need to draft a list of their essential ‟wants” to be set out in each escrow agreement (for example, a detailed list of the release events which would trigger the release of source code to the licensee, the quarterly obligation borne by the licensor to maintain the source code in up-to-date form and working order, the secondment of a highly qualified computer programmer employee of the licensor to the offices of the licensee, on a full-time or part-time basis, in order to train in-house IT staff about the intricacies of the software and its source code) and then pass on such list to their instructed lawyer – who should be an IT expert lawyer, seasoned in reviewing and negotiating escrow agreements – for his or her review and constructive criticism and feedback. Once the licensees have agreed an ‟escrow insurance plan” strategy internally, and then with their counsel, they need to contact the licensor, its management and legal team, and circulate to them a term sheet of the future escrow agreement, in order to kick off the negotiation of the escrow agreement.
An escrow agreement is, and should remain, an insurance policy for the licensee, as long as it – in coordination with its legal counsel – has paved the way to a successful and well thought-out escrow rescue plan. This way, the user of the software will avoid all the pitfalls of poorly understood and drafted escrow agreements and source codes, for the present and future.