HT-2021-000363 - [2025] EWHC 532 (TCC)

In November 2013 the Winsopia mainframe was moved from RSM to Winsopia’s Farnborough office.

An early idea, conceived by Mr Galewsky, then at Texas Wormhole, was to develop “the Appliance”, a non-mainframe machine comprising both hardware and software, to which some batch processing would be offloaded from a customer’s mainframe. A version of the Linux-based COBOL runtime environment could then be used to run the batches on the Appliance. The project, and the software that ran on the appliance, was referred to as “Rent Control”.

As part of the development process, a version of the Appliance was installed at Winsopia’s premises. The Appliance operated under the control of mainframe software that became known as “the Agent”, which was written by Mr Palmer at Winsopia. The Agent was a z/OS program that was intended to run on the customer’s mainframe and which would intercept batch jobs from the customer application and redirect eligible job steps to the Appliance via a connection. The intention was that the Appliance would be configured to receive batch jobs in the Linux environment, execute them in LzLabs’ software runtime environment, and then return the results to the mainframe for use in the customer application.

On 4 December 2013, Winsopia and LzLabs entered into a consultancy services agreement (“the Services Agreement”), whereby Winsopia agreed to perform discovery, quality assurance and software development work for LzLabs. The services were described in Schedule 1 of the agreement as: (i) discovery and QA services to LzLabs as described in the Winsopia Code of Conduct; (ii) software development services to LzLabs in respect of the Agents; and (iii) managerial and operational support and cooperation as necessary, including attendance at meetings and conference calls.

Mr Rastall’s evidence was that Winsopia used the mainframe and IBM licensed software for the sole purpose of assisting LzLabs in its software development. The main services provided by Winsopia comprised work on the Agent program, from 2014 until 2015, when the Agent and Rent Control Appliance project was abandoned; discovery work by Winsopia engineers through the DR process to assist LzLabs in developing the SDM; and testing work. This included testing existing compiled mainframe applications to see if they operated successfully in their native environment, and creating and compiling test applications on the mainframe so that their output could be compared to the behaviour of those applications on early versions of the SDM.

The defendants set up clean room procedures to ensure compliance with the terms of the ICA during development of what became the SDM. The clean room procedures included: (i) codes of conduct to be followed by Winsopia and LzLabs; and (ii) the Discovery Request (“DR”) system.

The intention behind the codes of conduct was to impose:

The DR System was designed to minimise the risk of infringing contractual and intellectual property rights of IBM or third parties, by preventing LzLabs developers from seeing and copying any IBM or third-party material they were not entitled to see or copy. Mr Rockmann described the operation of the DR System as follows:

There were a number of different versions of the Codes of Conduct throughout the development of the SDM.

The first version of the LzLabs Developer Code of Conduct was dated 4 November 2013. It applied to LzLabs Developers, who were listed in Schedule 1, including Mr Galewsky, Mr Bowler, Mr Jaeger, Mr Bond and Mr Taylor. The introduction explained the context for the LzLabs Developer Code of Conduct as the development of what became the SDM:

“2.1

LzLabs GmbH (“LzLabs”) will develop the RentControl Appliance (the “Appliance”). The Appliance will be a binary-compatible drop-in replacement for certain functions of an IBM z Series mainframe running z/OS. To develop the Appliance, it is necessary to perform discovery work on a z/OS system in order to determine how the Appliance should behave.”

The original Winsopia Employee Code of Conduct was dated 19 November 2013. It applied to all Winsopia Employees, including employees, managers and consultants providing services to Winsopia. It also applied to “Winsopia Researchers”, that is, all people employed by Winsopia as developers, researchers or managers of developers and/or researchers, and all consultants carrying out such work for Winsopia. It provided that LzLabs and Texas Wormhole would each develop aspects of the Appliance; Winsopia would carry out discovery work on the IBM z/OS system mainframe, together with QA and development work pursuant to the Services Agreement entered into by Winsopia and LzLabs.

The material terms of the LzLabs Developer Code of Conduct and the Winsopia Employee Code of Conduct (together, “the Codes of Conduct”) were the same.

The purpose of the Codes of Conduct was stated to be to set out rules which Winsopia and LzLabs were required to follow in order to respect third party intellectual property rights, even if they resulted in inefficient working. Both Codes of Conduct contained a warning that failure to follow the code might expose LzLabs, or Winsopia, to legal risk and potential injunctions preventing sale of the developed software.

The Codes of Conduct provided that development of the Appliance would be carried out using a strict controlled access environment process. Winsopia had acquired a mainframe and licences for z/OS components, which were listed in Schedules to each code. The controlled access environment depended on separation of the development work at LzLabs and Texas Wormhole from the discovery and testing work at Winsopia. To that end, only Winsopia would have access to a version of the Appliance and the mainframe. Winsopia would carry out tests to be run on the Appliance, tests to be run on the mainframe, and tests to be initiated on the mainframe but intercepted by the Agent (developed by Mr Palmer at Winsopia) and diverted to the Appliance for processing.

There were restrictions on communications between Winsopia and LzLabs/Texas Wormhole. These included the following.

There was a procedure for dealing with customer programs and/or data that would be supplied to LzLabs or Texas Wormhole. The customer would supply the data to LzLabs on a removable storage disk (such as a USB stick) and LzLabs would deliver it to Winsopia. Winsopia would remove from the data and/or replace with LzLabs equivalents all material subject to a third party’s copyright, such as z/OS Language Environment CSECTs in COBOL load modules and/or IBM CSECTs. The cleaned data would be copied by Winsopia to a directory on its FTP server accessible by LzLabs Developers.

Compiler listings requested through the DR system would be redacted by the legal team to remove comments and other non-essential material inserted by the compiler before being sent to LzLabs or Texas Wormhole. One hard copy of the unredacted compiler listing could be sent to the individual who had submitted the request.

Winsopia and LzLabs were required to keep a record of the sources referred to during their work. In particular, the Codes of Conduct provided that Claire Wilmot of Winsopia would organise and maintain records of all visitors to Winsopia and a log of unredacted hard copy compiler listings sent by Winsopia to LzLabs or Texas Wormhole Developers.

By March 2014 it is clear that Mr Moores was unhappy with the rate of progress achieved by LzLabs and considered that the Codes of Conduct were hindering development, as set out in his email dated 25 March 2014. Mr Moores considered that maintaining the Chinese Wall processes was a waste of time and money. He wanted the LzLabs Developers to have direct access to a mainframe and to unredacted listings, including assembly listings, traces and other information obtained through analysis of programs on the mainframe.

In April 2014 the Codes of Conduct were revised to remove references to Texas Wormhole and to relax some of the restrictions imposed on Winsopia and LzLabs. Under the revised Codes of Conduct, developers at LzLabs were able to access a test instance of the Appliance, which was housed at Winsopia. The purpose of such access was to test and update the developing LzMatrix software on the Appliance. This was done through a remote network connection called “the Airlock”. The purpose of the Airlock was firstly, to ensure that LzLabs developers could only access the Airlock for the purpose of testing the Appliance, without being able to access the wider Winsopia network; secondly, to provide a reliable mechanism for recording everything that those LzLabs developers did.

It was determined that communication between LzLabs Developers and Winsopia would be required to develop the Agent and ensure that it communicated correctly with the Appliance. For that purpose, a number of exceptions to the strict communications rules were introduced. To be permitted access to the Airlock, LzLabs Developers had to be located outside the USA and have an absolute requirement to test network communications with the mainframe in order to perform the assigned tasks.

Further, it was decided that it might be necessary for LzLabs Developers to visit Winsopia and interact with Winsopia system administrators in order to troubleshoot problems with the Airlock or the Appliance. This was required to be subject to legal oversight by Daniel Hedley or other legal advisers in attendance and the LzLabs Developers were not permitted to log in to or directly access the mainframe.

The existing procedure for redaction of electronic compiler listings was revised to allow Winsopia to provide LzLabs with compiler listings or traces of network traffic (such as IP packet traces or GTF traces), subject to redaction of English-language strings of three words or more.

Additionally, on 28 May 2014 further amendments to the Codes of Conduct were made, whereby communication was permitted by instant messaging outside the DR system and some of the LzLabs Developers were re-designated as LzLabs Support Engineers, named as Ulrich Weibel and John Cassidy. Mr Weibel and Mr Cassidy would agree with customers the means by which they would deliver their programs or data to Winsopia (by email or upload to Winsopia’s FTP server). As set out in earlier versions of the Codes of Conduct, Winsopia would remove from the data and/or replace with LzLabs equivalents all material subject to a third party’s copyright, such as z/OS Language Environment CSECTs in COBOL load modules and/or IBM CSECTs. The cleaned data would be copied by Winsopia to a directory on its FTP server accessible by LzLabs Developers.

On 22 August 2014, a new LzLabs Support Team Code of Conduct was introduced. This new code applied to LzLabs Support Engineers, who were defined as employees of LzLabs who: (i) worked in customer support, field service or QA; (ii) did not meet the definition of LzLabs Developer in the LzLabs Code of Conduct; and (iii) did not write code which would form part of the Appliance.

The LzLabs Support Engineers were not subject to the Codes of Conduct but the overriding principle identified in their dealings with customers was that they must not cause the customer to breach its licence agreements with IBM. Examples of potential breach included: (i) directly using the customer’s mainframe when the customer did not have the right to permit such use; (ii) taking copies of IBM Licensed Material in source code form, such as IBM copybooks; and (iii) attempting to reverse engineer aspects of the customer’s mainframe.

The overriding principle identified in dealings between the LzLabs Support Engineers and LzLabs Developers was that they must not enable, assist or cause any LzLabs Developer to breach the LzLabs Developer Code of Conduct. Examples of potential breach included: (i) involving LzLabs Developers in troubleshooting a customer problem where debugging of LzLabs code was not necessary to resolve the problem; (ii) providing excessive or unnecessary debug data from customer mainframes to LzLabs Developers; (iii) providing LzLabs Developers with access to the raw encrypted diagnostic feed from Winsopia’s Appliance; and (iv) holding conference calls with both LzLabs Developers and Winsopia in attendance. Similar guidance was provided in respect of dealings with Winsopia and Texas Wormhole.

In August and September 2014 the Codes of Conduct were revised, permitting Winsopia employees to communicate directly with LzLabs Support Engineers, by email or face-to-face, where necessary. Changes included the addition of a secure, monitored instant messaging system (“the IM System”) to enable LzLabs Developers with access to the Airlock to communicate with Winsopia in respect of integration and functional tests. In particular, provision was made for LzLabs Developers to be seconded to Winsopia on a temporary basis, pursuant to a Supply of Staff Agreement dated 14 August 2014.

Dissatisfaction with the restrictions imposed by the Codes of Conduct continued to be raised. By email dated 28 May 2015, Chris Cole forwarded to Mr Moores an email chain with Mr Rockmann and LzLabs’ lawyers, that appeared to show that legal issues were causing a delay with a DR response. In response, Mr Moores stated that there needed to be further changes to the Code of Conduct because development progress was being substantially impacted. He was clear that continuing the existing clean room system would not work.

Mr Moores was vociferous in his calls for LzLabs developers to be given direct access to the mainframe. Although in evidence he stated that he did not put pressure on the legal team to make any specific changes to the Codes of Conduct, very shortly after this exchange, further revisions to Codes of Conduct were made.

On 10 June 2015 the LzMatrix Code of Conduct for LzLabs Employees and Winsopia Employees was published, replacing the earlier Codes of Conduct (“the Integrated Code of Conduct”). This introduced a significant change, namely, that under the Integrated Code of Conduct, access to the mainframe would be granted to LzLabs:

“4.1

Winsopia, based in Farnborough, England, has acquired a z Series mainframe, DASD devices and licences for various z/OS components (each, a "Component" and together, the "Mainframe"). Save as otherwise provided in this code of conduct, only Winsopia Employees will have access to the Mainframe.

4.2

LzLabs Developers may now additionally have access to the Mainframe provided that (i) the visit and its purposes (to be set out in writing when seeking approval) are pre-approved by (a) Winsopia and (b) a member of the LzLabs executive team; (ii) that access occurs at Winsopia's premises; and (iii) is solely for the purposes of assisting Winsopia Employees in testing (including debugging) already developed code.

4.3

LzLabs Support Staff may access the Mainframe provided that they do so at Winsopia's premises for the purposes of supporting Winsopia's operations and activities.

4.4

All visits to Winsopia by LzLabs Employees will be logged.”

On 23 September 2015 LzLabs UK was incorporated as a wholly-owned subsidiary of LzLabs, to provide a UK base for LzLabs and to carry out QA services. Mr Cresswell and Mr Rockmann were appointed as directors.

On 13 October 2015 the Integrated Code of Conduct was revised to include LzLabs UK employees. Under this revised code, LzLabs UK employees were not permitted to carry out discovery work on the mainframe for use in developing LzLabs code. However, under this revised Code, additional provision was made for permitted direct communications between LzLabs Developers and Winsopia Employees at clause 6.1:

“In addition to performing discovery and QA work, Winsopia is developing a tool for recompiling load modules into x86 native code, as well as certain other mainframe- based tools, utilities and agents to facilitate customer migration (together, the "Winsopia Development Projects") using the Mainframe. It is acknowledged that communication between relevant LzLabs Developers and Winsopia Employees is required in order to develop the Winsopia Development Projects and to ensure that they work correctly with the Product. However, please note that development of the Winsopia Development Projects is subject to the same communications restrictions applicable to all interactions between LzLabs Employees and Winsopia Employees …”

Further amendments permitted LzLabs, LzLabs UK and Winsopia employees to communicate by instant messaging, support systems, email, Skype, videoconference, phone or face-to-face, although they were required to use their company systems and record all such communications.

Thus, the evolution of the Codes of Conduct, following their introduction in late 2013 can be summarised as follows: