Delivery up of code on termination of an IT infrastructure project

An application by a purchaser of an IT platform for an order requiring delivery up of the software and source code failed.

09 February 2022

Publication

Customers for an IT project frequently face a difficult decision if delays and problems with the software cause them to lose faith in the contractor. Terminating the agreement may lead to the customer recovering damages, provided they can show that the circumstances give them a right to terminate for material breach. But it may leave the customer with no IT platform and a lengthy delay while it finds another contractor who then has to start again. If the original software showed enough promise, the customer may wish to keep what has been achieved so far, but switch to another provider to finish the job.

Delivery up

Growth Capital Ventures Limited (GCV) was selected to carry out the development of a novel IT platform for Transparently Limited (TL), ironically designed to facilitate dispute resolution. The contract price was a cash sum of £200,030 together with equity value of £139,570 in TL. Delays occurred and TL ultimately terminated the agreement for material breach, claiming that the software product was incomplete, late and defective, with less than half the promised functionality and a number of errors and bugs. GCV denied that the software was defective, blaming problems on changes in the scope of the project requested by TL.

Thus far, thus familiar. The positions of the parties are familiar from any number of IT infrastructure project disputes. But as well as damages, TL sought delivery up of “the software and all related documentation for the software… as it has been developed to date including all software change and configuration control records and test specifications and test results”. TL proceeded to apply for an interim injunction to this effect, in other words for the delivery up to occur immediately, in advance of it issuing a claim.

Mandatory injunctions

Courts are more reluctant to grant an injunction of this kind, which compels a party to take an action rather than refrain from acting. The overriding consideration for the court is which course is likely to involve the least risk of injustice if it turns out to be wrong. With a mandatory injunction, the risk of injustice is greater than with a prohibitory injunction, which maintains the status quo.

The court considered whether there was a “high degree of assurance” that TL would be able to establish its right to delivery up of these things at trial. It concluded that there was not, for two reasons. The first was that the injunction had been applied for before any claim form or particulars of claim had been filed, so TL’s case had not been fully set out. The second was that under the software development agreement, while a termination triggered completion and therefore the transfer to TL of all the software and source code, completion also required the transfer to GCV of the shares in TL. While GCV had been paid the cash sum under the contract, the issue and allotment of shares had not occurred and the judge concluded that TL’s argument that it has a contractual entitlement to the software in these circumstances was weak.

Financial position

One of TL’s arguments in favour of the injunction was that its financial situation was perilous and that if its access to the software was delayed, it might become insolvent. This would seem a strong argument that damages at the end of the trial process would not be an adequate remedy. However, the judge noted that if it were true, the logical solution would be for TL to issue and allot the shares to GCV and then exercise its right to the software and source code.

The plea of impecunity also had another negative effect for TL’s application. Any party applying for an injunction must give an undertaking in damages, agreeing to pay for any losses caused by the injunction if their claim fails at trial. TL’s evidence of its weak financial position undermined the value of its offer of an undertaking in damages.

Learning points

There are many different ways to provide for the early termination of an IT project agreement, but for the customer it is crucial to consider whether it will be able to continue the project from the point reached rather than start again. Clear drafting is needed as to the ownership of the software, source code and related documentation in this situation.

The contract in this case was clear and provided “a complete code in the event of termination”, providing that the customer would be entitled to the software and source code. However, that was contingent on the customer paying the contractor in full. There is commercial sense in such an arrangement, as the customer is able to proceed with the project from the point that has been reached, but only if the contractor is paid, leaving the question of damages for any defects in the product to be decided later.

This document (and any information accessed through links in this document) is provided for information purposes only and does not constitute legal advice. Professional legal advice should be obtained before taking or refraining from any action as a result of the contents of this document.