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

The allegation is that Winsopia transferred to LzLabs or third parties load modules containing IBM CSECTs and other proprietary material in breach of clauses 4.1, 4.1.2(b) and/or 4.1.3(b) of the ICA. Although Winsopia purported to “scrub” the IBM CSECTs and other proprietary material, the methods adopted were flawed and incomplete, with the result that not all such material was removed from the load modules.

The defendants’ case is that the IBM CSECTs and other proprietary materials were not ICA Programs and, once bound into a customer application during the compiler or link-editing process, became part of the customer application. Additionally, many of the IBM CSECTs the subject of these allegations did not relate to material licensed to Winsopia under the ICA but were licensed to third parties, licensed for distribution under Licensed Program Specifications or sample program licence terms, or historic IBM CSECTs relating to old versions of products not licensed to Winsopia.

The disputed issues are:

During the compilation and/or link-editing processes, IBM CSECTs, code fragments, routines and other IBM proprietary materials are inserted into the application, as explained earlier in this judgment. Clause 4.1.3(b) of the ICA prohibits Winsopia from transferring any ICA Program outside Winsopia’s Enterprise. Further, clauses 4.1.1(b) and 4.1.2(b) restrict the use of any ICA Program to the permitted use identified in the ICA.

Winsopia transferred load modules and other materials to LzLabs for the purpose of developing the SDM and to assist third party customers in migrating their applications and data to the SDM. Prior to such transfer, it was necessary for Winsopia to remove IBM CSECTs and other IBM proprietary materials from the load modules. There were two material purposes served by such removal: first, it would ensure that IBM proprietary material would not be transferred out of Winsopia’s business enterprise in breach of the ICA; and second, it would enable the transferred load modules to be processed and run on the SDM, using instructions inserted by the SDM loader invoking alternative API calls to compatible runtime services.

Prior to 2015, a manual process of “stubbing” was used, whereby Winsopia replaced IBM CSECTs with empty “Winsopia stubs”, dummy routines that would indicate to LzLabs where “wormholes” (instructions to call replacement runtime routines) should be inserted. This process did not involve any removal of IBM CSECTs. At the link-editing stage, Winsopia specified a NOCALL (“NCAL”) option that prevented the binder or linkage editor from calling runtime libraries other than the Winsopia stub dataset. This process prevented the inclusion of IBM CSECTs at the link-editing stage but did not remove any CSECTs already inserted, for example, at compilation stage. Further, it required Winsopia to re-link-edit load modules supplied by customers, referred to by Simon Payne of Winsopia as “a real pain” in his email dated 27 October 2016.

Between 2015 and 2016, Winsopia developed a tool to migrate data, including load modules, initially known as the Data Migration Assistant (“the DMA”), later referred to as Centerpiece Export (“CPX”). CPX, which ran on the mainframe, used a LZMPDSE batch program to scan the load modules, deconstruct them into individual CSECTs, automatically remove the IBM CSECTs and replace them with placeholder binary zero code.

Mr Palmer of Winsopia wrote the CPX code and explained its various functions in his first witness statement:

Mr Palmer’s evidence was that LZSLIST, the load module scrub list, was created by him through the discovery request process, with input from developers at LzLabs, including Mr Bowler. Initially, it was based on the full names of CSECTs that were supported by the SDM, that is, where there were replacement wormholes.

In cross-examination, Mr Rastall stated that CPX identified the CSECTs to be redacted by reference to the scrub list. The scrub list was compiled based on Winsopia’s understanding at any given point in time of the IBM CSECTs which needed to be redacted. It was updated manually as and when Winsopia became aware of new CSECTS to be added to the list but if the precise name of a CSECT was not on the scrub list, it would not be scrubbed by CPX.

“Q. It was inherent in the process that there would be certain IBM CSECTs which were not contained on the manually updated scrub list?

A. Yes, I think we've established that in previous points.

Q. And if those CSECTs were contained in a load module being passed to LzLabs, it would follow, would it not, that those CSECTs would be transferred in unscrubbed form?

A. Yes.”

Mr Whittingham, a Senior Software Developer at Winsopia, took over Mr Palmer’s role on CPX. He made changes to the scrub list that would prompt the batch program to look for specific code signatures and sequences within the modules rather than simply looking for names. The scrub list was expanded on an incremental basis as he was asked by various people at Winsopia and LzLabs to add items. In addition, he conducted checks to maintain the scrub list and requested LzLabs and Winsopia staff to notify him of any new CSECTs discovered that should be scrubbed.

In addition to the scrub list, Winsopia maintained LZXLIST, an exclusion list of module names, that would be excluded from migration to the SDM but not replaced by wormholes, and LZSRULE, a list of CSECTs that were not subjected to any scrubbing.

Mr Whittingham’s evidence was that CPX contained algorithms that could have been used to facilitate wild cards, using search patterns to match generic names, such as “*” to capture all variations of CSECT names that required scrubbing. From the outset, it was suggested to Mr Palmer on a number of occasions that wild cards should be used to identify and remove IBM CSECTs from the load modules but this suggestion was not adopted until after he left in 2020.

The allegations are that there were a number of scrubbing failures or exclusions, resulting in IBM CSECTs and other proprietary materials being sent by Winsopia to LzLabs.