Jumar Solutions Ltd v McKee

This is an action for infringement of copyright, breach of confidence and breach of contract brought by the Claimant (Jumar) against a former employee (Mr McKee) and it arises out of the writing and use by Mr McKee of some software, called the McKee Software, which may compete with one or more of Jumar’s key software products and, in particular, Jumar MAPS.

Jumar is a substantial IT services and solutions company which specialises in migrating and updating client computer software systems and platforms. In particular Jumar focuses on large software deployments in the Government and Enterprise area and uses a suite of software which it has developed and which it calls MAPS. To understand the function of MAPS and its components it is necessary first to know a little about a product called CA Gen.

CA Gen is an application development environment marketed by CA Technologies. Its purpose is to enable IT departments within large organisations to develop their own computer systems. It is capable of generating code for a variety of technical platforms from application designs constructed as models. It was designed for building large scale business systems and the systems built with it tend to be at the heart of many of the organisations which use it, making it critical technology for their success. Typical users are government departments and Fortune 500 type organisations, i.e. very significant players in the world economy.

Although CA Gen has been a very successful product, Jumar has taken the view that it is too complicated for many modern users and, moreover, that there is a growing shortage of skilled software engineers who are able to use it effectively. Some years ago it decided to develop a product which would enable CA Gen users to convert their CA Gen applications to other technologies such as native COBOL or Java. Mr Michael, the technical director of Jumar, and some of his colleagues claim to be amongst the few outside CA Gen who understand the product sufficiently well to develop such a product and much of the development work has been through the use of trial and error.

MAPS software is Jumar’s modernisation and migration solution for CA Gen. It exploits CA Gen’s Applications Programming Interfaces (APIs), which give very low-level access to the information held in a CA Gen installation, and enables that information to be extracted and manipulated.

The MAPS CA Gen migration solution includes one primary API, known as CEXUAPI, and three substantive components, G2X, XCG and the Runtime Libraries. In arriving at its solution, Jumar used the Visual Basic programming language (VB) as its standard for developing software products.

CEXUAPI is a VB product which engages with CA Gen APIs so as to aggregate and extend their functionality thereby making them much easier to use and integrate with other, more modern, software programs. CEXUAPI gives Jumar the flexibility to assemble applications which work directly with CA Gen. It provides a base for interrogating a CA Gen database so as to extract from it the necessary data pertaining to any particular CA Gen application model.

CEXUAPI exists as a source code version and as a compiled, object code version. It applies algorithms, formulae and processes (called the CEXUAPI Algorithms) to perform its interactions with CA Gen and make them available to software that uses it.

G2X is a piece of software written in VB which connects to/interfaces with CEXUAPI and thereby gives access to CA Gen data. G2X converts CA Gen data by extracting information about an application design from a CA Gen model and then reformats and processes it into XML (another programming language) output which is stored in an XML database.

G2X exists as a source code version and a compiled object code version. It uses what were called G2X functions and applies algorithms, formulae and processes (called the G2X algorithms) to use the G2X functions.

The next component of the Jumar MAPS solution is called XCG. This works by querying the XML Database/XML Outputs generated by G2X and CEXUAPI with tools called XQueries which have been specifically developed by Jumar. By using a series of ‘targeting formulae’ the results from querying the XML database are converted into Java Code, C# Code or COBOL code as required.

In version 1 of XCG (known as XCGv1) source code files are directly output from XCG in a form ready to be compiled into object code by a relevant compiler for the relevant language.

XCGv1 exists as a source code version and a compiled object code version and uses a series of queries to interrogate the XML outputs (the XQueriesv1) and reads, interprets and translates the XML outputs using XCGv1 Functions. It applies algorithms, formulae and processes (the XCGv1 algorithms) to perform the XCGv1 Functions.

In early 2014 and as a result of customer feedback, Jumar decided that the XCG element of MAPS needed to be redesigned to increase its flexibility and make it more convenient in use. In this redesign Jumar wished to improve the structure of the Java output and to provide that the output be more easily customisable for different customer requirements. It did so by introducing template-based code generation. The result was XCG version 2, known as XCGv2. It comprises XQueriesv2, XCGv2 Functions, XCGv2 Source, XCGv2 Object, XCGv2 Algorithms in a similar way to XCGv1.

XCGv2 outputs its code into a series of pre-defined ‘templates’ (the Output Templates) via a third party intermediary program. This intermediary program takes the XML output from G2X and, essentially, performs a kind of ‘find-and-replace’ on the templates so that the proper code appropriate for any model is placed in the proper place on the templates.

Further, XCG generates code to emulate the complex and often idiosyncratic behaviours of a CA Gen application which are not represented in the XML but are found in the CA Gen runtime libraries. To achieve this Jumar created its own runtime libraries or common code routines. These were described as ‘helper’ pieces of software that perform certain core functions of the generated software application.

Jumar Common Code Routines (JCCR) are written mainly in COBOL and Java and function together to replicate core behavioural aspects of CA Gen by JCCR Functions. They apply algorithms, formulae and processes (the JCCR Algorithms) to perform the JCCR functions.

Complementing the above MAPS also includes the XML Schema which defines XML/XMI tags and elements with which XML output from G2X must comply to function properly. The XML output is expressed in XML files and is generated by G2X to comply with the XML Schema.

During the course of the development of MAPS Jumar devised a testing model (the Demo Model), expressed as CA Gen Data, to ensure that MAPS could produce functional equivalence to CA Gen Data types and scenarios. The package consists of Demo CA Data, Demo XML Output Data, Output Code Data (called Demo Code). It operates as a control over the functionality and, therefore, value of the MAPS product at any particular stage of development.

By developing MAPS Jumar has built and can offer to clients a software solution which enables those clients to build a new functionally equivalent version of its original CA Gen application, a version which is in a modern programming language (such as Java) and which is, therefore, more useful to clients with skills only in modern languages.

Jumar contends that its MAPS software solution comprises a very large number of copyright works which it or its predecessors in title created and which it now owns. It also contends that the development of, operation of and functioning of the MAPS solution and each of the various aspects thereof is the product of many years of sustained endeavour and that it comprises a substantial body of valuable and highly confidential information. Jumar claims ownership of that body of confidential information.

When Jumar decided that XCG should support the generation of code for the Java technical platform it recognised the need to hire a technical architect with extensive knowledge of Java development. Jumar appreciated that the generated Java code had to be well organised, easily maintainable and perform well and the principal responsibility of the architect was to define in detail how that output should be structured, reflecting the original CA Gen application. There was no one in house who could satisfy that role so in February 2013 a technical architect was appointed. That person turned out not to be satisfactory and was released at the end of April 2013. Jumar decided upon Mr McKee to fulfil the role of replacement technical architect and Java developer for its MAPS suite.

Mr McKee is a software engineer. Having previously worked for Jumar’s Australian arm in 2012, he was engaged by Jumar from 8 April 2013 to 31 May 2013 via a company called APSE Consulting Ltd and then, via the same company, from 3 June 2013 to 27 July 2014.

By virtue of his engagement by Jumar and his access to the confidential information embodied in the MAPS software in the course of that engagement, Mr McKee was privy to Jumar’s confidential information for the purposes of furthering Jumar’s interests. Mr McKee accepted that the MAPS suite comprised valuable confidential information and that he knew this to be so.

In common with other consultancy contracts, there were terms in the APSE/Jumar contract which obliged Mr McKee to keep confidential Jumar confidential information and not to use it for his own or any other person’s benefit. There were also terms which provided that any intellectual property rights which derived from the provision of Mr McKee’s services under the contract shall belong to Jumar.

Mr McKee was also party to a Non-Disclosure Agreement (NDA) with Jumar dated 17 September 2013. This included similar obligations in relation to confidentiality as those in the consultancy contract.

The McKee Software complained of in this action was created in about the second half of 2014 and there is a dispute about whether or not it was created during the performance of any consultancy contract with Jumar.

Jumar contends that Mr McKee, in developing the McKee Software, has infringed Jumar’s copyright in two major respects. First it contends that Mr McKee has, without its permission, used various aspects of the MAPS product in his development of the McKee Software and, since use of a computer program inevitably involves copying it, has thereby infringed the numerous copyrights in MAPS. Second it contends that the software components of the McKee Software are themselves copies of and an infringement of its copyright in components of MAPS. Thus, Jumar contends that the McKee Software was not only made using Jumar’s copyright works in an infringing manner but also is an infringement of Jumar’s copyright. Jumar claims injunctive relief and damages.

Further Jumar claims Mr McKee’s actions were flagrant and it claims additional damages pursuant to section 97(2) of the Copyright Designs and Patents Act 1988.

Jumar also contends that Mr McKee misused its confidential information in devising the McKee Software and that it is the direct product of that misuse. As with its case in copyright, Jumar claims injunctive relief and damages.

Jumar also contends that Mr McKee has acted in breach of contract, the contracts relied upon being (a) that between Jumar and APSE and (b) the NDA between Jumar and Mr McKee.

With regard to the APSE contract, Jumar’s difficulty is that Mr McKee was not party to it. Jumar sought to overcome this hurdle in 5 ways, the first two of which are effectively the same, as are the fourth and fifth. First it is said that Mr McKee was a member of ‘Consultancy Staff’ at the relevant time and accordingly he is bound by the contract. Although the contracting party is defined to include “APSE and any third party to whom the provision of consultancy services is assigned or sub-contracted” I do not think this definition extends to APSE’s employees. Accordingly this route does not get Jumar home. Second it was said that APSE contracted as agent for Mr McKee. This seems to me clearly not to be the correct position. Thirdly it was said that there was a collateral contract between Jumar and Mr McKee on the same terms as the APSE contract alternatively there was an implied collateral contract on the same terms as the APSE contract as a matter of necessity to give effect to the covenants under it. I reject this proposition also. Had the parties wished Mr McKee to be contractually bound to any of the express terms of the APSE contract it would have been very easy for them to achieve this. The fact that they did not do so in these circumstances points strongly against the existence of any collateral contract.

In relation to the APSE contract, Jumar argued at trial that, because of this contract, it was entitled to ownership of the McKee Software. However, this was not part of Jumar’s pleaded case and Mr Hill, for Mr McKee, objected to it being raised for the first time at the trial. Mr Hill was right so to object for at least two reasons. First, it was too late to raise the matter. Second and in any event, Jumar’s pleaded case was that the McKee Software was developed otherwise than as part of the authorised XCG project and contrary to any authorisation given to him.

Regarding the NDA, Mr Hill accepted that this bound Mr McKee but contended that it did not require separate consideration since the obligations thereunder are co-terminus with his equitable obligations. Mr Cregan did not contend otherwise so it is not necessary to consider the matter further.

A number of witnesses gave evidence and each party led expert evidence.

Mr Michael is the technical director of Jumar and he was the first witness. I found him to be very well informed and he appeared to me to be a good and reasonable witness who was doing his best to assist me. He explained how the MAPS solution came to be developed and the effort that went into it. He also explained the involvement of Mr McKee within Jumar and the fact that Mr McKee had been engaged because of his software engineering skills using Java as the programming language.

Mr Michael also explained that Mr McKee was very keen that Jumar use Java in place of VB as its standard processing language to develop its software products. Mr Michael took responsibility for rejecting this proposal since all the existing Jumar engineers were skilled in VB and not many in Java – he did not want Jumar to be unable properly to service or manage its software solutions. The debate between the use of VB and Java as the preferred development language was one of the causes of disquiet in Jumar during the latter period of Mr McKee’s engagement.

Mr Michael also explained the complexity of MAPS and the fact that it represented years and years of effort by reason of the complexity of CA Gen and the difficulty of understanding the significance of any of the particular data components within any CA Gen Application model. A major difficulty, Mr Michael pointed out, in migrating data from a CA Gen model into a functionally equivalent model in a different language is finding out what any particular set of CA Gen data signifies. Jumar now have that knowledge and, Mr Michael explained, it is extremely valuable confidential information.

The next witness was Mr Scott who is the client director at Jumar. His main role is in business development and his main responsibility was driving forward Jumar’s modernisation and migration initiatives. He was subject to some hostile cross examination but stood up well and answered questions directly without any evasion. He was good at explaining matters and I found him to be an honest witness doing his best to assist the court.

The next witness was Mr Flynn who is a principal consultant with Jumar. He is a CA Gen expert who began work on XCGv2 in about October 2013. His responsibility was to ensure that that XCGv2 functioned as required and generated the output required. On a day to day basis he focussed on ensuring XCGv2 properly interfaced with CA Gen and was much involved with Mr McKee. He was not as clear or careful about some of the relevant matters as I thought he should have been but, on the whole, I think he was doing his best to assist me. He is an important witness because of his involvement with Mr McKee in the early days of the development of the McKee Software.

The next witness was Mr Tate who is the operations manager at Jumar. He is responsible for the day to day running of Jumar’s Solutions business and this included overseeing the project to renovate the XCG software. This involved managing the relevant team including Mr McKee. He was a good clear witness.

The next witness was Ms Rao who is a senior development engineer at Jumar. She was part of the team renovating the XCG software and her responsibility was to update the tooling to produce output in accordance with the architecture designed by Mr McKee. She was an honest witness.

In addition there was no challenge to the witness statements of Ms Trueman who was Jumar’s finance director at the relevant time. She spoke to the contractual relationship with Mr McKee.

Mr McKee was the only witness of fact in support of his defence. I am completely satisfied that he is a very highly skilled software engineer with extensive skills in the Java technical environment. He is also a man who thinks that he is a very good engineer, possibly better than others around him, and, in the context of software engineers and their skill sets, he may appear arrogant and intolerant of less skilled personnel.

Mr McKee was subject to very hostile cross examination and in closing argument Jumar’s counsel, Mr Cregan, submitted that he was telling lies from beginning to end. Mr Cregan presented a number of examples which he submitted demonstrated that this was the case. For example, much was made of a statement made by Mr McKee to the effect that he had developed the McKee Software “from the ground up” whereas in fact it incorporated code which Mr McKee accepted had been developed earlier.

Mr McKee is not a lawyer and my impression of him was that he does not think like a lawyer and he does not use language as precisely as lawyers. Having heard Mr McKee and listened to his use of language, I interpret his expression of “from the ground up” at the time he used it to convey the message that the overall framework or architecture of his solution to CA Gen Migration was different from anything else he had come across and, in particular, was different from Jumar’s (for example the McKee Software does not, like Jumar’s CEXUAPI and G2X, interrogate a CA Gen data model in order to understand it, it just extracts the whole of it and dumps it into a MongoDB database) and that he had worked out this architecture and how it would work from scratch. I do not think he was intending to convey the message that none of the ideas expressed in the Software or code used in the expression of those ideas had been used by anyone before.

In this context it is noteworthy that Mr McKee said in evidence that he considered the XCGv2 project to be “a complete rewrite of the software from the ground up”. What I understood him to mean by that is that the architectural approach in XCGv2 is different from that in XCGv1 (which is true) and not that there is no commonality at all between them.

A second example used by Mr Cregan to illustrate Mr McKee was untrustworthy is that he did not properly comply with his disclosure obligations. In particular, in his development work, Mr McKee did not maintain a full history of all the changes which he made as development progressed. There is no doubt that he should have done but I do not find it very difficult to understand why a man like him did not properly appreciate his litigation disclosure obligations.

Having had the benefit of the oral examination of Mr McKee I do not think Mr Cregan’s portrayal of him is fair. I consider that Mr McKee was honest in his evidence, in that he believed that what he was saying to be true. However, I think Mr McKee was mistaken in what he believed he was entitled to do with Jumar’s property. This mistake may have been due to ignorance or to some advice he had received very early on in this saga, but I do not think it is a consequence of dishonesty.

I turn now to the experts. Jumar relied on Mr Jasper who recently retired from an extensive career in computer programming. His main expertise is in the field of CA Gen, the C computer language, Unix/Linux, Shel/K-shell/Bash scripting and XML/HTML. He said he had a working knowledge of debugging CA Gen generated Java code but accepted that he was not an expert in Java or VB (although he had some familiarity with these languages). He was not aware of various available tools used to refactor Java processes for automatically generating code and he was not familiar with the open sources available to Java or VB developers. These were important omissions from his tool box.

Mr Jasper was instructed quite recently (due to the unavailability of Jumar’s original expert), however, and one consequence of this is that he did not have as much time to work on his report as he might have had. Either as a result of lack of time or because he chose so to do, Mr Jasper, when considering the McKee Software looked only for similarities between it and the MAPS software. He did not look for or remark upon any differences between the two suites of software (although he accepted these could be relevant) and he did not look for or offer explanations (other than copying) for any similarities. Nor did he attempt to assess the significance of any similarities in the context of any particular item of software as a whole. On occasions Mr Jasper was argumentative rather than helpful and I gained the impression that he thought that part of his brief was to be an advocate for Jumar’s case. Since the instructions he had been given were very clearly to the opposite of this, I have concluded that this was something he had taken upon himself.

Mr McKee called Mr Dickson for his expert testimony. Mr Dickson is the principal of Framley Ltd, a software engineering practice. He designs and programs software and provides consultancy services in relation to a range of software matters such as the architecture and design of new systems, fault diagnosis and performance tuning in existing systems and the process of developing software. Mr Dickson was criticised because of his lack of experience working with CA Gen but I am satisfied that he had sufficient appropriate skills to assist the court.

I found that Mr Dickson was a good and clear witness who was performing his role as expert properly. He was not an advocate for Mr McKee’s case and the reasons and explanations he gave for his opinions were persuasive.

In the context of assessing the experts together, on the whole I considered Mr Dickson to be much more helpful than Mr Jasper. The reasoning behind Mr Dickson’s views was more cogent and compelling than that of Mr Jasper who, in my view, was much more concerned with me thinking that he believed Jumar should win than why that should be so.

Of particular relevance in the context of assessment of the experts is the use made by Mr Jasper of various tools such as the COCOMO model to estimate the time taken to write particular software based on the length and complexity of that software. Mr Jasper applied that and other similar tools to the McKee Software and used the results as some basis for his conclusion that the McKee Software could not physically have been written in the time available without copying from Jumar. Mr Dickson explained the limitations of these tools and provided examples of how Mr Jasper’s conclusions were misleading. He explained, for example, that Mr Jasper’s methodology would suggest a particular item would take 7 months to create whereas modern techniques for automation would enable relevant source code files to be generated within a few minutes.

I preferred Mr Dickson’s explanations in relation to the use of these tools and did not find the results obtained by Mr Jasper through their use to be helpful.

I turn now to the issues in the case, the first of which was ownership of the copyrights which Jumar relies upon. These are identified in paragraph 35 of the Particulars of Claim:

This list comprises a very large number of works, many if not most of which were poorly particularised or evidenced as to their content (in the context of a copyright infringement action). Nevertheless there was extensive evidence as to the creation of the various works as they were identified by name (rather than by content) and none of it (save in respect of the common code content) was seriously challenged. Jumar has satisfied me that, in so far as copyright subsists in the works comprising the MAPS suite, it owns that copyright. However, some parts of some of those works are, individually, not original and, as such, are not part of Jumar’s copyright arsenal. The consequence of the latter is that mere similarity between content in the MAPS suite and the McKee Software is not enough to establish copying or infringement although it will call for an explanation.

Moreover, copyright is unlikely to subsist in algorithms or schemas in the abstract and I am not satisfied that Jumar has made out its case on subsistence in relation to these items. In any event there are no details in either the pleadings or the evidence of the content of any algorithm or of the schema and in these circumstances it would not be possible for Jumar to prove its case.

Also and importantly, there was very little evidence about the time when any of the copyrights alleged to subsist in works connected with XCGv2 were made. Mr McKee’s evidence was that by late July 2014 the Jumar development team had barely started on the XCGv2 solution and that there were no templates, XQueries or XCG target algorithms in existence. There was no effective challenge to this evidence. He also said that, as of Autumn 2014, XCGv2 was not reliably generating compilable source code and this was not effectively challenged.

The next issue is whether Mr McKee infringed any Jumar copyrights during his development of the McKee Software. To determine this I must consider how the McKee Software came into being.

In early 2014 Mr McKee was the sole Java specialist within Jumar and he was the technical architect of the XCGv2 project. It will be recalled that XCGv2 was being written and developed in VB and that its purpose was to complete the migration of a CA Gen application model into a more maintainable application in Java (for example). In about April 2014 Mr McKee proposed that the use of VB be abandoned and that since the purpose of XCGv2 was to generate Java it should be written in Java, and that Jumar should build an in-house team with Java skills for that purpose.

Mr McKee gave what he considered to be cogent reasons for proposing that the use of VB as the language for XCGv2 be abandoned and there was no challenge to them. They support my conclusion that Mr McKee genuinely believed that Jumar would benefit from a Java implementation of the conversion of XML data into Java code representing the original CA Gen model and that the work he subsequently did to demonstrate that was intended to be for Jumar’s benefit, at least initially.

Jumar, and in particular Mr Michael, however, was not convinced. It rejected Mr McKee’s proposal because the in-house development team were primarily .NET developers (Microsoft’s .NET languages include VB) and all existing products were written in one of these languages.

Mr McKee considered Jumar’s decision to be a mistake and, according to Mr Flynn, he suggested that he develop a version of XCGv2 in Java to prove his point. Mr Flynn went on to say that he was supportive of Mr McKee’s proposal and was content that he carry out his development of a version of XCG in Java in Jumar time so long as it did not impinge on the other work he was doing, i.e. designing Java output for XCGv2 to generate (using the VB implementation already in place). Mr Flynn’s evidence was that Mr McKee could only have been working on his Java development by reference to CEXUAPI, G2X, G2X’s XML outputs and other works in the MAPS suite and that this was what he expected him to do. If all this were so, then it would be clear evidence that the McKee Software was devised, at least in part, using Jumar proprietary materials.

Mr McKee contended that Mr Flynn was mistaken in his recollection and that he did not propose that he develop and nor did he do any work towards a Java implementation of XCGv2 prior to August 2014. He provided a time line for his code generation product development created using folder and file creation dates, his Skype chat history and his recollection. It was detailed and persuasive and was not effectively challenged. I accept it.

Mr McKee’s second APSE contact was due to expire towards the end of July 2014 and two or three weeks prior to that he asked Mr Flynn if he could take a four week break from his consultancy role. It appears that this was agreed and since it was anticipated that Mr McKee would return to continue working with Jumar, his access to Jumar’s software and data repertoire was not suspended. Mr McKee did not visit Jumar’s offices during August 2014 but, from a remote location, he assisted Mr Flynn and other members of the Jumar development team in relation to a number (three) of inquiries concerning the XCGv2 project. All this is consistent with the parties being in harmony and with Mr McKee being expected back by Jumar after his break. As set out above, it was during this break that Mr McKee began working on a new system for CA Gen migration, initially by devising a Java solution to Java code generation from XML output (i.e. in place of the VB solution then being used for XCGv2).

On or around 2 or 3 September 2014 Mr McKee visited Mr Flynn at Jumar’s offices and, in the words of Mr Flynn, demonstrated a version of XCGv2 written in Java. In a witness statement made on 11 February 2015 and in the context of the McKee Software and XCGv2 Mr Flynn said this:

If these statements were true, they would be powerful evidence in support of Jumar’s case. They were challenged in cross examination, primarily on the basis that XCGv2 was not a working product at that time and there were no XQueries or templates. Mr Flynn was forced to concede that what he meant was that the McKee software was doing something which Jumar had planned for XCGv2, a proposition which is quite different from his original proposition. Mr Hill submitted this was an example of the care I must take with the Claimant’s written evidence and he is right in that respect, certainly with Mr Flynn.

Mr McKee explained in his written evidence how he prepared for the demonstration to Mr Flynn. He used Jumar’s J2.xml file as input and using some BaseX queries he put together he manually transformed the J2.xml file to the XML format which his code generation solution required (i.e. Mr McKee’s demo model XML data was prepared from G2X generated XML data). Since he had only implemented a small subset of the CA Gen action statement functions required, he stubbed (i.e. blocked to pass the compilation step) the remainder such that he could show Mr Flynn how the code generation, compilation and execution of a few block function objects worked. He said the demonstration lasted only 10 minutes or so and he did not present the XML model data, BaseX query logic or common code so Mr Flynn could have learned nothing about those matters.

There was no effective challenge to Mr McKee’ evidence about the demonstration and I accept it. It shows two things. First that there is no reason to believe from this demonstration that the McKee Software infringes any of Jumar’s copyrights. The demonstration merely showed that Mr McKee has written some Java code which will convert a demo model in XML format to an equivalent model in Java format. Second, the demonstration showed that Mr McKee was using Jumar confidential model materials to test and develop his product (although, in so far as they were used for the purposes of a demonstration to Mr Flynn, that use was not a misuse).

In relation to this second point, Mr McKee’s evidence was that he continued to use the CA Gen modelling tool on Jumar’s system to progress his code generation solution until 25 September 2014 when Jumar cancelled his log in credentials and this dispute effectively commenced. I am satisfied that he did so believing it was permitted by Jumar since he retained the hope and expectation that Jumar would adopt his Software in place of the problematic XCGv1 and XCGv2 developments.

Regarding the common code module used for the September demonstration, Mr McKee said it was based on work he had done prior to the Jumar project rather than on Jumar’s common code module. This is a matter to which I will return. What is clear at this stage, however, is that Mr Flynn did not have opportunity to consider the common code during the demonstration and could, therefore, reach no conclusions about it.

There were discussions during this period between Jumar and Mr McKee with respect to a new consultancy contract and a sticking point emerged. Mr McKee had sought advice from a commercial solicitor and he wanted a term in any new contract to the effect that any software developments he made in his own time be excluded from a provision that they belong to Jumar. In effect, I have concluded, Mr McKee wanted to own the McKee Software for CA Gen Migration based on Java and not see it adopted or annexed by Jumar without his consent, especially since Jumar had insisted in persisting with a VB solution, Mr McKee believing that a Java solution would be superior. Jumar and Mr McKee were unable to agree upon the terms of a new contract despite efforts from Mr Michael, who wanted Mr McKee as part of the XCGv2 development team, albeit insisting that the product be written in VB to migrate a CA Gen model to a, for example, Java equivalent.

On 16 October 2014 Jumar wrote to Mr McKee informing him that a decision had been taken not to renew his consultancy contract, requesting him to return all copies of Jumar proprietary information and putting him on notice that any attempts by him to commercialise what is now known as the McKee Software would be met with proceedings for infringement of copyright and breach of confidence. Further hostile correspondence followed but there was no resolution of any issues.

Since there was no renewal of the APSE contract which expired in July 2014 and since I have concluded Mr McKee did not start on his Java migration solution until August 2014, any work Mr McKee did on the McKee Software was done outside any relevant contract between Jumar and APSE in relation to his services.

In January 2015 there was an exchange between Mr McKee and an American firm called eCube Systems, a competitor of Jumar. Mr McKee said he made the contact because he wanted to know what materials they had which might assist with his development of the McKee Software and in the end the matter went nowhere. However eCube contacted Jumar and led Jumar to believe that Mr McKee had been passing himself off as a Jumar employee. Jumar feared that he was offering eCube a CA Gen migration product which infringed its rights. Solicitor correspondence followed shortly thereafter and this led to an application for interim injunctive relief and these proceedings.

Jumar alleged that Mr McKee was attempting to sell or otherwise communicate the McKee Software to eCube. There was no reliable evidence to support this allegation and Mr McKee’s evidence was to the contrary. I am satisfied that Mr McKee contacted eCube to see if they had information relevant to his work and that, in conversation with eCube, he did no more than explain why he wanted the information. This explanation was that he had the idea of offering a CA migration solution to Java consultancy services. The allegation is not proved.

By January 2015 the McKee Software had developed such that it was capable of interfacing with a CA Gen Model and outputting functionally equivalent software in Java code. However, there was no expert evidence as to how comprehensive it was or how well it worked. Mr McKee’s evidence was that its functionality was limited. He said its capability of extracting data from a CA Gen model and migrating that model to a Java equivalent was limited to developments which could be made from public sources. There was no effective challenge to that evidence and I consider I must accept it. Even if, as Mr Cregan contends, Mr McKee was lying hand over fist, there is nothing to gainsay this evidence. There was no evidence to the effect that the McKee Software had anywhere near the functionality of MAPS.

The consequence of the limitations of the McKee Software is very important. Throughout their testimony, a number of the Jumar witnesses stressed how MAPS was the product of years of research and painstaking trial and error endeavour. One of the purposes of this evidence was to illustrate that Mr McKee must have copied MAPS for it would be physically impossible for him to have prepared the McKee Software in such a short period of time without so doing. The force of that point falls away if the McKee Software does not emulate MAPS, if it can only migrate when there is publically available information enabling a competent software engineer to program a technical migration solution.

The evidence established that the overall architecture of the McKee Software is quite different from that of MAPS. Thus the McKee Software does not use an equivalent of CEXUAPI which, in combination with G2X, interactively interfaces with a CA Gen API to interrogate a CA Gen Model in order to populate an XML database and provide XML output equivalent to the original model.

In the McKee Software a Model Exporter Service (written in C#) dumps the whole of the CA Gen data for any model into a MongoDB Database. The McKee Software provides a Scala based Model Exporter Utility to extract data from MongoDB and represent the CA Gen Model in XML which, like MAPS, can output to a BaseX database. Whereas MAPS has XCGv2 which interrogates the BaseX Database through BaseX queries and uses Templates and Common Code to produce Java output, McKee’s code generator uses both BaseX Queries and Templates to interface with the BaseX Database and the Common Code is imported directly into the Java output.

Moreover the McKee Software uses different XML files as input from those used for XCGv1 or XCGv2 (being those output by G2X) and the XML data structure is different, pointing to the methodology being designed independently. This was confirmed by Mr Dickson’s analysis.

In the MAPS solution, the whole of the process is organised according to Jumar’s proprietary materials. In the McKee Software the Model Exporter Service, Model Exporter Utility and Code Generator are organised by an industry standard product called Maven. Furthermore, Mr Dickson carried out a methodical comparison of the two XML Schemas and found that they differ. He concluded that the differences were so numerous and varied that it is unlikely that the McKee Schema was derived from the Jumar Schema.

There was a good deal of assertion in Jumar’s evidence to the effect that the code generated by MAPS and by the McKee Software was identical, and this was used as a basis for a conclusion that there must have been copying of Jumar copyright works. It is not necessary to analyse what these works might be because I am not satisfied that the assertion was made out. There were very few examples relied upon by Mr Jasper and no consideration of whether similarities might be due to functional similarity, the use of open source materials or a feature of the CA Gen input. Mr Jasper accepted that he was not a Java expert and this may be the reason why his evidence was lacking in this respect.

Except in one respect (to which I will come), there was, in my judgment, no evidence of any sufficient similarity between the various components of the MAPS product and the McKee Software to raise a prima facie case of copyright infringement. Mr Cregan dealt with this by submitting that Mr McKee had merely translated the MAPS solution in VB using Java rather than VB and that, accordingly, there was infringement. He likened it to translating a book from English into French.

I reject this analogy. First, there was no real evidence to support it and second, the fact that the McKee Software handles the CA Gen Model data differently has the consequence that a translation of the MAPS software would not work. Mr Cregan was driven to submitting that because the inputs are the same (i.e. the CA Gen Model data) and the outputs are the same (i.e. a Java interpretation of the CA Gen Model input) there must have been a translation of the MAPS solution to arrive at the McKee Software. I reject this as a proposition. It seems to me to have no logical basis and, in any event, it fails to take into account the totally different ways in which each solution achieves its end product.

The one area where there is similar code in the McKee Software and MAPS is in respect of the common code. Mr Jasper noted these similarities and his conclusion was that they proved copying. In my view he did not properly consider other possible explanations for the similarities. Mr Dickson, on the other hand, did. His conclusion was that it was not possible to establish by technical evidence any conclusive view as to how and when the two bodies of common code came into existence, as to what extent their origins lie in common precursor code or as to which was created first. One thing that he did think was very likely, however, is that Mr McKee was the author of the great majority of the common Java code in both source trees. Mr McKee has given an explanation for this.

The explanation lies in what was called the demo_refactored project which Mr McKee said he started work on in October 2013. Mr McKee said that he carried out this project in his own time to demonstrate to the Jumar team what a function object centric code generation solution should look like. He said that to accelerate development he introduced Mybatis coding patterns from his personal code base which he had established during his career prior to joining Jumar. He said that he created the demo_refactored project because he felt that the XCGv1 project was fundamentally flawed, a conclusion Jumar itself reached during the summer of 2014. He said that the Jumar development team only started working seriously with the demo_refactored project in June 2014 and that his final contribution to it was in July 2014. He claimed that he coded the entire demo_refactored project himself and that the Jumar common code project was created using common folders in the demo_refactored project. In the work on XCGv2, Jumar followed the coding pattern implementations in the demo_refactored project as the basis for its template centric code generation.

Regarding the McKee Software, Mr McKee accepts that the same or substantially the same code exists in both the demo_refactored project and the McKee Software and he says that this is because they are both based on the function object centric data processing work which he had done prior to joining Jumar. He explained that the folder hierarchy structure was not complex but was a standard Maven structure, Maven being an open source project which standardises the way projects are built.

Jumar’s witnesses gave evidence about the demo_refactored project and each was adamant that any work being done on it by Mr McKee was being done for the benefit of Jumar. I accept this evidence and, to be fair, Mr McKee accepted it as well. Although he had referred to some of the work as being done in his own time, what I consider him to have meant by that was that it was not part of what he had been asked to do by Jumar.

Jumar’s witnesses also gave evidence to the effect that the demo_refactored project was a team effort and this is also probable. However, nobody was put forward as authoring or being party to authoring any of the relevant code, i.e. that which is common to both the McKee Software and the demo_refactored project. In the circumstances of this case, the fair inference is that it was Mr McKee. This inference is also consistent with Mr McKee’s attitude to code generally, which is that code which he creates is better suited to a particular purpose than code which anyone else can create.

In my judgment there was no effective challenge to the authorship of the relevant demo_refactored code and so Mr Dickson was right in his opinion that Mr McKee was the common author of that code and the equivalent in the McKee Software.

Mr Cregan submitted that Jumar was the owner of the copyright in the demo_refactored code (although Mr Dickson doubted, rightly in my view, whether it was part of Jumar’s case as pleaded in the Particulars of Claim – see paragraph 57 above) and that, even on Mr McKee’s story, there was infringement of copyright. He submitted that once a software developer has created some code for an employer from pre-existing materials, he cannot develop the same code again without infringing the copyright of that employer.

In my judgment the matter is not so straight forward. I would accept that a developer cannot slavishly copy works created for an employer on the basis that the works were themselves created from the developer’s pre-existing materials. But I do not consider the law of copyright prevents a developer from creating those or similar works again in circumstances where they flow naturally from the pre-existing materials and are the most appropriate codes for the particular purpose under consideration. If the law were otherwise, there would be a serious impediment on software developers with libraries of prototype code which they had put together either for fun (and I am satisfied on the evidence that software engineers such as Mr McKee do consider experimental code generation to be fun) or to remain competitive in the market place (they are part of their tools of trade).

My conclusion, therefore, is that Jumar’s claim for infringement of copyright fails. To recap, apart from the common code, there is insufficient similarity or evidence of derivation for a case to succeed and in respect of the similarities in the common code, Mr McKee’s evidence of independent creation defeats the claim.

I turn to the case in misuse of confidential information. It seems to me to be accepted on the evidence that in the early days, that is to say prior to October 2014, Mr McKee was using Jumar confidential materials to develop the McKee Software.

Mr McKee accepted in cross examination that he was using Jumar’s servers, including those containing Jumar’s licensed CA Gen Services and its CA Gen installation and its models for his development work. As an example, it is clear that Jumar’s demo model was used for the purpose of carrying out the September demonstration to Mr Flynn. Another example is that Mr McKee accepted that he analysed an XML version of a Housing and Urban Development model (which had been provided to Jumar by the US Federal Government) resident on Jumar’s servers to develop his BaseX queries. The significance of this is, as Mr McKee accepted, the analysis enables the identification of which parts of the XML data matter for code generation. Mr McKee used Jumar’s information to help him identify relevant XML data and work out protocols for subsequent use in code generation.

It was put to Mr McKee that he could not possibly have thought that Jumar would permit him to make this sort of use in the development of software which would compete with MAPS. His response was that, at the time, he was not thinking of competing software. This is entirely consistent with other evidence, including that of Mr Flynn, that Mr McKee was hoping that he could persuade Jumar to adopt his proposal of using Java in place of VB as the development language for CA Gen migration software. I have also inferred that he was also hoping that Jumar would adopt his migration solution in preference to that using CEXUAPI and G2X. However since the development at that stage was far removed from anything equivalent to those software implementations, such hope was probably little more than a dream.

At the time, I am satisfied that Mr Flynn was privy to what Mr McKee was doing, at least at a high level, and encouraged it. In these circumstances, the use of Jumar confidential information was not a misuse, it was use with consent in circumstances where there was a reasonable anticipation that Jumar would ultimately benefit therefrom. However, although the use was not a misuse when it was made, I am satisfied that Mr McKee built upon that use when he continued to develop his Software after the fall out in October 2014. This use was primarily in that part of the Software which interfaces with the XML database and converts the model into Java code.

There is also a confidential information issue in the context of the common code. It will be recalled that I have concluded that the relevant demo_refactored code (i.e. that common to Jumar and to the McKee Software) was written by Mr McKee as part of his work for Jumar. He accepted in evidence that in refactoring the code he took some functions from the Jumar common code used in XCGv1 (which, as explained above, is a different code generating tool from either XCGv2 or the McKee Software).

There was no exploration in the evidence as to how much or what was the significance of any use of XCGv1 functions in the demo_refactored project in the context of the content of the McKee Software, the purpose of the relevant cross examination being to establish that the demo_refactored project was for Jumar’s benefit and not otherwise (or, that is what I understood the purpose to be).

In these circumstances, and since the architecture of and mode of operation of XCGv1 is so different from that of the Java code generation part of the McKee Software, there is no reason to conclude that any confidential information pertinent to XCGv1 was used in the development of the latter and I do not so conclude.

As far as the duration during which Mr McKee used Jumar materials to assist in the development of the McKee Software, I consider it more likely than not that he did so after the September demonstration, there being no reason at that time why he should think that he should not do so. I think it likely that he continued to use Jumar confidential information to assist with the McKee Software until October 2014 when he ceased all work on integrating his code generation solution with Jumar’s XCGv2 environment.

Subsequent to October 2014, Mr McKee continued working on the McKee Software and he did so because he knew, from his experience at Jumar, that a product which would enable migration of a CA Gen model to a functionally equivalent Java implementation would be a valuable product and he also knew that Jumar was having difficulties developing XCGv2 or any other Java code generating solution. At least the latter of these matters was confidential to Jumar but it is not relied upon in these proceedings.

My conclusion in respect of the confidential information side of the case is that the McKee Software was devised in part using Jumar’s confidential information, in particular, that in relation to its demo models and testing criteria. There was no evidence that use or distribution of the McKee Software would disclose any of that confidential information.