Here’s a story, where a developer lost rights to software it developed, that’s similar to others we see: a developer doing work for a customer on the basis of evolving and fuzzy arrangements. Equally, the customer could have lost out too as the arrangements weren’t clearly documented.
In this case, there were deferred payments, sweat equity, and so on. In the end, the court said in this May 2013 decision that the developer couldn’t even use the software it developed for other projects for a different market.
The case is a reminder: always, but always, agree a clear basis as to who owns and who licences software and other IP, and how that happens including as to specifics. And sort out payment and equity arrangements clearly, such as by shareholders’ agreement. Don’t assume a court can unravel the answer satisfactorily.
Over the years we’ve written about this problematic area that can cause so much grief for both developers and their customers.1 Yet another case,2 this time an English case, finds a developer caught out.
Destra Software Ltd was a one-man vehicle by which Mr Hughes provided development services. He worked with other developers to develop software called FundNexus for a customer. It was developed in the Delphi language. Mr Hughes and the others each developed separate components in FundNexus. But the customer abandoned the project; so some of the developers, apart from Mr Hughes, decided to move the project in a different direction, using DotNet and C# instead of Delphi, based on in-house and softwareas– a-service options. It was intended that the product be supplied to the market in optional modules, and “white labelled” as well. So the new venture needed the software rights to all of the new platform, one way or another. Important for the new venture, to ensure the ability to market internationally, was to own the software outright, instead of licensing some of it (as owning, following assignment or initial ownership, is a better vehicle to enforce rights than licencing).
Mr Hughes was also taking some steps down a similar path but the others never knew this.3
The new venture between the developers was called Comada (the main defendant in the case brought by Mr Hughes’ company, Destra).4
The other developers asked Mr Hughes to help on the new project, and he started doing so on an unpaid and speculative basis. The work between the developers including Mr Hughes was collaborative, broadly continuing the way they had worked together previously. The understanding was that Mr Hughes would not invoice his usual fees: he would be offered shares in a Comada vehicle that could then be sold. Then some revised detail was agreed, and then varied, by which he would get a percentage of the shares and some money later. This was not formally documented and the IP issues weren’t clearly addressed.
Those facts outline the basis of the second issue covered by the court. Now we turn to the facts for the first issue it covered.
Formal consultancy agreement?
Comada couldn’t pay the money when due under those arrangements. This led to the offer of a fuller agreement, the Consultancy Agreement (CA). The draft of the CA confirmed Comada got all the IP developed by Mr Hughes. But it was never signed. So, Mr Hughes argued that the draft was never agreed, even though both parties acted as though it had been.
Things turn sour
Mr Hughes then claimed that he owned the IP in the system, even though his contribution was to, said Comada, “not just code, it’s [to] a working system”. The relationship between Mr Hughes and the others ended, and Comada started a new company – in which Mr Hughes had no shares - to distance Mr Hughes from the software.
First question – Consultancy Agreement binding
The court had no difficulty in finding that the series of events, including both parties proceeding on the assumption that the CA was binding, was enough to make it legally enforceable. That was so even though the draft CA envisaged it would be binding only when signed.
On that basis, Mr Hughes was bound by the clause giving IP to Comada.
Second question – what if the CA was not binding?
Even if the CA was not binding, the judge said that Comada would still own the IP including the IP developed by Mr Hughes. That analysis takes the facts as they existed before the draft CA.
There are cases that outline the factors courts consider in deciding who owns and/or licences software. On that basis, Mr Hughes argued that he should own and that there should be minimalist intrusion on his ownership to meet Comada’s needs, by implying a grant of licence to Comada to use the IP for limited purposes. In this way, Mr Hughes should be able to use the platform in other contexts and in other ways.
The judge didn’t agree, including because:
- The very foundation of the Comada venture was the software package as a whole, and it makes more commercial sense that the software belongs to Comada. A third party shouldn’t be able to veto what Comada does with the software: everyone’s efforts are reflected in the Comada shareholding including Mr Hughes’ holdings.
- One of the objectives was to sell the enterprise to maximum advantage for the participants: to achieve that, Comada should own the IP.
- The software was a collaborative effort.
- “One of the principal means of exploiting the software was by licensing; it was necessary for Comada Cayman to have full rights of enforcement in multiple jurisdictions. That is secured by assignment but not by licensing.” 5
- This was not a case where there should be an implied term that Mr Hughes could use and develop software in parallel: unlike another case where the developer did get rights, here the other developers did not know that Mr Hughes was taking steps in parallel. Implied terms only apply where there are relevant shared understandings.
The Broader picture
All was not lost for Mr Hughes. The fact that the other developers moved the software rights from the company in which he had shares to another company may well, said the judge, be the basis of a claim. But that claim was not raised in this proceeding.
Further, the judge did not go into the detail of pre-existing IP, as opposed to newly created IP, although that may be because of the way the case was pleaded.
As part of not clarifying carefully the IP rights, the parties also did not carefully sort out their financial and other arrangements. That highlights also the importance of shareholders’ agreements in shared ventures such as this. In early days of projects such as this, there can be challenges in carefully documenting these things, when funds are tight, and it’s not clear where the project will go in terms of success. But, unfortunately, without clarity and careful documenting, there are real risks, especially if the small venture turns into a goldmine.