The collapse of one of Telecom’s software providers Aldous demonstrates that the value of source code escrow is only as good as its implementation. This column looks at the Telecom situation, and outlines key components to a robust escrow arrangement.
Aldous was the developer of software used by Telecom’s XT network. In Court documents, Telecom estimated it had spent over $7 million on the software in the last four years, to the point that the software had become entirely bespoke to Telecom.
Presumably in recognition of the strategic importance of the software, in 2007 Telecom and Aldous entered into a source code escrow arrangement that required Aldous to deliver the software’s source code to an escrow agent within 10 days of each update. On the happening of certain events (such as Aldous’ insolvency), Telecom was entitled to demand the release of the source code from the escrow agent.
For a while, the arrangement appears to have worked, with the source code being duly deposited by Aldous to the escrow agent. However, four important things subsequently occurred:
• In June 2008, Telecom and Aldous entered into another agreement that (according to the receivers) superseded and ended the 2007 escrow agreement;
• Aldous ceased depositing updated source code with the escrow agent;
Telecom apparently did not notice (or was not notified) that updated source code was no longer being deposited with the escrow agent (the escrow agent was obliged to notify Telecom whenever it received a code update); and
• In 2009, a security interest was registered in favour of a third-party secured creditor over Aldous’s assets, including the source code used in the Telecom software.
The result was that when the New Zealand branch of Aldous went into receivership in April this year, the only version of the source code available to Telecom was very outdated. Aldous’ receivers, presumably mindful not to diminish a potentially valuable asset, refused to provide the latest code to Telecom, and took steps to sell the source code. If it was acquired by another company, Telecom could be left unable to update or debug the software.
Telecom claimed rights to the source code and in June obtained an interim High Court injunction preventing the receivers from selling the source code until a full hearing.
While more detail will come to light if the matter continues to a full High Court hearing (though it would not be surprising if the matter is resolved out of court, e.g. Telecom simply buys the assets from the receiver), the immediate lesson is that if you have an escrow arrangement in place, make sure it is being performed. It seems that had Telecom simply checked the code was being deposited with the escrow agent, or learned that it had ceased and enquired why, much of the dispute (and publicity) could have been avoided.
It also shows that not only can the customer (in this case Telecom) be left in a precarious position, but the vendor can also be put to the expense of legal proceedings, with the result that there may be less funds for creditors.
More broadly, it highlights that source code escrow these days can be a curious beast.
While a seemingly simple solution for assuring customers that they will not be left high and dry if a vendor collapses, without proper documentation and administration, it can leave both parties in an uncertain position.
A complicating factor in the Telecom case was the third-party security interest registered (on the PPSR website) over all of Aldous’s assets, including its intellectual property.
“All assets” security interests are commonly granted when banks or other creditors lend money to a company. Such a security interest (if valid and registered) typically takes priority over unregistered security interests, such as a customer claiming a right to a licence or intellectual property, although it depends on the facts in each case. If the loans are not repaid, a receiver may be appointed to sell the collateral in order to recover the loans. A receiver is not necessarily bound to observe an escrow agreement or other “onerous” contracts, and the unsecured customer or licensee may lose out.
Yet another complication arises from Telecom’s claim to own the intellectual property in the source code.
On a practical level, it may be difficult or even impossible for many users to successfully use escrowed code unless the escrowed material includes all related essential resources such as documentation or database schemas.
Robust escrow arrangements
A robust source code escrow arrangement will include three key components:
• The practical ability for the customer to obtain up-to-date source code and other relevant material if allowed. Escrowed code is often held by a third-party (an agent) who is contractually required to release the code to the customer upon certain events. The customer should ensure updated code is being deposited as intended.
• An appropriate licence allowing the customer to use the source code upon release from escrow. In most cases, the customer simply wants to be able to continue to maintain the software if the vendor cannot, and the licence should ensure this can occur. But consideration should also be given to whether the licence needs to permit further uses of or dealings with the source code, e.g. whether the source code can be redeveloped into a substantially different system, and sale or redistribution to third-parties.
• An appropriate contract clearly documenting these arrangements (which may be rolled into another contract, such as a licence agreement).
Other options or considerations include:
• Taking an option to buy the source code, e.g. giving the customer a legally-enforceable option to acquire the relevant intellectual property at an agreed price, exercisable upon certain events (such as the vendor’s insolvency). This may be a good idea in situations where the code is (or may become over time) highly bespoke to the customer;
• Registering a security interest over the relevant intellectual property. Whether this is possible and appropriate will depend on the detail of the escrow / option arrangements, but can prevent a third-party creditor from claiming a higher-ranking entitlement to the source code if the vendor collapses.
It may be argued that the increasing use of open source and “shared source” licensing has reduced historical assumptions of value attached to proprietary code itself, and in many cases may be a better alternative than traditional escrow. For specialised or high-end situations, where source code escrow is required, robust arrangements should be in place or else the supposed assurance can turn out to be illusory.
This article provides general information and does not constitute advice. Professional advice should be sought on specific matters. Burgess is a lawyer specialising in IT solicitors. He can be reached at email@example.com