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

IBM alleges that Winsopia disassembled code in the IGZCUST module, sent it to LzLabs and Mr Moores, and failed to prevent unauthorised use of such code, in breach of clauses 4.1, 4.1.2(b), 4.1.3(a) and 4.1.3(b) of the ICA.

The defendants’ case is that this allegation concerns an isolated historic instance of alleged disassembly for the purpose of diagnosing and correcting an error in a customer application. As such, it was permitted by the ICA, the disassembled code was not used by LzLabs and caused no loss.

In July and August 2014, Mr Lynch of Winsopia observed high CPU usage while testing a customer supplied program on the Winsopia mainframe. He traced the high CPU usage to a series of instructions contained within a COBOL support module called IGZCUST, a component of load module IGZCPAC.

IGZCPAC is an IBM supplied load module that contains a number of general COBOL library routines supplied as part of z/OS Base. It is supplied in object code only. IGZCUST handles the ‘UNSTRING’ statement employed in COBOL programs, decomposing a text string into discrete fields according to a specified set of delimiters.

Following a request by Mr Rastall of Winsopia to document his findings, on 22 August 2014 Mr Lynch sent an email to Mr Rastall, stating:

“When we were initially testing program from [a customer] we thought it might be infinitely looping due to its high CPU consumption and low I/O rate.

So I took a series of dumps while it was running to try to discover if this was true or not. This is the results of the dump analysis.

… this cluster of instructions are … part of a COBOL support module called IGZCUST which is a component of load module IGZCPAC. As a loaded program IGZCPAC was not supplied to us by [the customer] but was loaded from the COBOL Language Environment libraries on our z/OS 1.13 system. IBM describe IGZCUST as ‘UNSTRING VERB LIBRARY SUB-ROUTINE’.

In order to understand further what the program was doing in this cluster of instructions it was necessary to disassemble the code.

Analysis of this code shows that it is a search loop where the following registers and storage are being used …

I have also worked back along the save area chain to find the point where [the customer application] calls IGZCUST. I’m still trying to determine what parameters are passed in the call but this is proving rather difficult at the moment.”

Mr Lynch included in his email an analysis of four dumps taken during the execution of the program, line-by-line annotation of the disassembled code and partial extracts from each of the four dumps taken.

Mr Rastall forwarded the email to Mr Galewsky and Mr Rockmann of LzLabs, and to Mr Moores, who provided comments by return email:

“This thing EXecutes a TRT? Ask JJ about the performance implications of a TRT. Massively slow … My guess is that stuff like this is gonna have to be rewritten in C or C++.”

The SDM Git repository commit history shows that development of the SDM implementation of the functionality of IGZCUST was started in February 2012, prior to this incident of disassembly. It also shows that, following Mr Lynch’s email, 15 further commits were made to the relevant SDM code between 3 September 2014 and 3 October 2014 by Mr Bowler of LzLabs.

The experts’ second joint statement includes the following agreements:

It is common ground that Winsopia disassembled part of the IGZCUST module and sent the disassembled code to LzLabs and Mr Moores. The issues are:

The defendants’ case is that the portion of IGZCUST that was disassembled is not an ICA Program because it is merely a part of the z/OS Base V1 product. I reject that argument for the reasons set out above, namely, that component parts of a program fall within the definition of an ICA Program for the purpose of the ICA. The experts agreed that the disassembled code included the object code of the IGZCUST runtime CSECT that formed part of the SCEERUN library provided with z/OS.

It is said by the defendants that on its true construction the ICA does not contain any provisions specifically prohibiting error correction. Therefore, Winsopia was entitled to disassemble the code for the purpose of diagnosing or correcting errors in a customer program, pursuant to Winsopia’s rights under the Software Directive.

The ICA does not contain an express prohibition against error correction but Clause 4.1.3(a) of the ICA contains an express prohibition against reverse assembly, reverse compilation, translation or reverse engineering of an ICA Program. The experts agree that Mr Lynch carried out disassembly and Mr Lynch stated in his email that he disassembled the code. Clause 4.1.1(d) contains specific and limited permission for Winsopia to use any portion of an ICA Program in source form for resolving problems related to use of the ICA Program but this did not extend to object code. The portion of the IGZCUST module disassembled by Mr Lynch was in object code. It follows that the ICA contained provisions whereby Winsopia was prohibited from carrying out disassembly of object code for any purpose, including error correction.

Article 5(1) of the Software Directive provides that:

“In the absence of specific contractual provisions, the acts referred to in points (a) and (b) of Article 4(1) shall not require authorisation by the rightholder where they are necessary for the use of the computer program by the lawful acquirer in accordance with its intended purpose, including for error correction.”

This does not assist the defendants. The permission to use the program for error correction is expressly subject to “specific contractual provisions”. The ICA contains a specific contractual provision that prohibits disassembly (subject to the exception permitting the use of source code for error correction). Article 8 of the Software Directive, precluding the use of contractual terms to override the rights conferred by the Directive, does not apply to Article 5(1).

In any event, in cross-examination, Mr Moores stated that the purpose of this testing on the Winsopia mainframe was to improve performance on the SDM. Therefore, it was not carried out to correct any error in the ICA Program or the customer application.

The defendants submit that Mr Lynch’s actions fell within permitted observation, study and testing of the IGZCUST module pursuant to Article 5(3) of the Software Directive. This requires consideration of what Mr Lynch did and for what purpose.

In his first witness statement, Mr Lynch stated that he used XDC to carry out the disassembly of the code:

“I used XDC to examine the cluster of instructions in the IGZCUST module to identify whether there was a bug in the system which might explain why it was causing the customer's application to run slowly, or whether the slow running and high CPU usage were caused by something else. XDC displays the code in disassembled form by default; this is essentially its primary user interface. ”

As explained earlier in this Judgment, XDC is a commercially available debugging tool that enables a breakpoint to be set at a specific point in a load module, stopping execution and transferring control to XDC. It allows the user to step through the code examining the execution of each instruction, view data areas and registers, disassemble object code and display dumps of memory.

Mr Lynch’s explanation that he used XDC to carry out this disassembly was echoed by Mr Rastall, who stated in his second witness statement:

“Mr Lynch was using standard debugging facilities to identify the source of the problem. To be clear, Winsopia (including Mr Lynch) used the XDC tool in the way it was designed to be used.”

In his third witness statement, Mr Lynch stated that, on further reflection, he could not be sure that he used XDC, although he did not know for certain that he did not use XDC in connection with this exercise. This uncertainty appears to have arisen as a result of an email exchange between Mr Palmer and Colesoft (suppliers of the XDC tool) in October 2014, indicating that XDC was not installed at Winsopia prior to that date. In cross-examination, Mr Lynch stated that he thought that he manually disassembled the code but could have used an alternative IPCS disassembly tool supplied by IBM. When pressed, he conceded that he had no recollection as to what he did.

In the light of this additional evidence, Mr Stephens’ opinion was that Mr Lynch could have reviewed the dumps manually using a tool like IPCS. He noted that there were two errors in the disassembled code and commentary by Mr Lynch, which could point to manual disassembly as opposed to use of a disassembly tool such as XDC. However, in cross-examination he accepted that Mr Lynch could simply have made those errors when transcribing into the email the output generated by a disassembly tool.

Although the state of the evidence on this matter is unsatisfactory, it is not material to the issues in dispute. Regardless of whether the method of disassembly was manual or through use of a tool, Mr Lynch accepted that he disassembled part of the IGZCUST load module. Such disassembly involved translating parts of the module object code into assembly code. Mr Lynch did not confine his actions to observation, study and testing of the functioning of the IGZCUST module, which could be achieved simply by running the customer application and examining the input and output. On the contrary, he carried out a detailed analysis of the execution of each instruction within the disassembled portion of the module. Such detailed analysis investigated, not just the output of the program but how the program achieved its output, that is, expression of the program, rather than its functioning.

There is a dispute between the experts as to the amount of code disassembled. In the email sent by Mr Lynch, there were 35 disassembled instructions, out of about 1,369 lines of code. Mr Stephens and Professor Donaldson estimated that this represented about 2% of the IGZCUST module. However, Mr Swanson noted that there was an ‘offset gap’ between the penultimate and final lines of code in the email, suggesting that Mr Lynch must have disassembled substantially more lines of code than the areas of interest reproduced in the email. Mr Stephens agreed that more of the module must have been disassembled. He considered that it was likely that Mr Lynch disassembled the code above and around the TRT statement but it did not necessarily follow that he disassembled all the code between the penultimate and final lines of code in the email.

In cross-examination, Mr Lynch stated that he would have targeted his disassembly on the instructions of interest but this was qualified by his explanation that:

“Once I had the disassembled code, then I know – I know where to look, and I know where not to look, because I’m not interested in it. ”

This does not assist in answering the question how much code was disassembled before he knew where to look and could target the relevant instructions. As Mr Lynch accepted, he did not recall what he did. Regardless of the amount of code actually disassembled, none of the experts suggested that it was de minimis or superfluous code. The substantive quantity of disassembled code is evident from the extracts set out in Mr Lynch’s email. Indeed, Mr Stephens’ opinion was that all code was of more or less equal importance, observing that if it was unimportant, it would not be in the program at all.

I find that it is likely that a substantial amount of functional code was disassembled, the purpose of which was to discover the specific form, parameters, sequence and effect of each instruction. Such disassembly was not permitted by the terms of the ICA and did not fall with the observation, study and testing exception of the Software Directive.

It is not disputed that the disassembled code was sent by Mr Rastall of Winsopia to LzLabs and to Mr Moores. This amounted to a transfer of an ICA Program outside Winsopia’s Enterprise in breach of clause 4.1.3(b) of the ICA. This was accepted in cross-examination by Mr Rockmann.

The defendants submit that no use was made of the disassembled portion of IGZCUST by LzLabs. The experts agreed that the portion of disassembled code sent to LzLabs was not the basis of nor sufficient for creation of the entire SDM IGZCUST module, which was developed some considerable time before August 2014 and included a functional UNSTRING routine. However, IBM’s case is not that the disassembled code was used to create the SDM module but rather that it was used to make improvements to the same.

Support for IBM’s case can be found in the proximity of time between Mr Lynch’s email of 22 August 2014 and the Git repository commits by Mr Bowler during the period 3 September to 3 October 2014. First, the Git repository commit made on 8 September 2014 substituted a standard C library function with a bespoke searching function that would avoid unnecessary conversions between ASCII and EBCDIC (different representations of textual data in computer memory). Mr Swanson’s opinion was that this change provided an equivalent function to the code analysed in Mr Lynch’s email. Professor Donaldson agreed that the change made was a substantive change, in that it would make the SDM more accurate functionally and it would improve performance of the SDM code by avoiding the unnecessary conversions. However, his opinion was that, although this could lead to improved performance, copying the logic of such code would be unnecessary, as the search function in question could be easily written from scratch.

Second, on 12 September 2014, although he did not modify the existing code, Mr Bowler added an explanatory comment regarding interpretation of the parameters that were passed to IGZCUST. There is no explanation as to the source of this information, which is not published by IBM.

Third, on 3 October 2014, a commit was made, introducing new data types that described the structure of arguments to IGZCUST. Professor Donaldson considered that this was the most significant commit made during this period, adding the most substantive functionality. He was unable to identify any source code comments indicating what led to this improved understanding of IGZCUST parameters. Although this was the focus of part of Mr Lynch’s work, as evidenced by the last paragraph of his email dated 22 August 2014, Mr Swanson and Professor Donaldson agreed that these improvements could not be attributed to any information set out in the email.

Unfortunately, the DR process was not used for this aspect of Winsopia’s work on the mainframe and there is no record of any discussions between LzLabs and Winsopia. Mr Rastall agreed in cross-examination that the direct communication between Winsopia and LzLabs was in breach of the Code of Conduct then in force. If the DR process had been used, there would have been a clear audit trail of information requested and received by LzLabs and the disassembled code would or should have been redacted.

Mr Jaeger’s evidence was that he started to investigate performance issues in the SDM module from early August 2014 and made changes to improve the runtime speed of the customer application in question which were incorporated into the Git repository on 18 August 2014, before Mr Lynch’s email of 22 August 2014. He was adamant that he did not use the analysis provided by Mr Lynch or the suggestions by Mr Moores in development of the SDM code. Mr Jaeger also stated that subsequently, Mr Bowler began looking for other ways to further improve the performance of the program. He asserts that there was no connection between the specific changes made by Mr Bowler and any of the material in Mr Lynch’s email but he does not have direct knowledge as to the reasons for Mr Bowler’s revisions, there was no explanation for the revisions in any contemporaneous records and Mr Bowler did not give evidence.

Mr Bowler’s commits to the Git repository during the period 3 September to 3 October 2014 referenced a Jira ticket RC-2805, which was created by him on 2 September 2014 with the title “IGZCUST performance improvement” and referred to the time taken for the UNSTRING operations in respect of the customer application. In the comment section entry dated 19 September 2014, Mr Bowler recorded that the modification to the SDM code, eliminating the conversion between ASCII and EBCDIC, resulted in approximately 20% reduction in elapsed time.

Having regard to the timing and content of Mr Bowler’s comments and commits, and in the absence of any direct evidence from Mr Bowler, I find that it is very likely that Mr Lynch’s disassembled code and analysis was used to give LzLabs insight into how this part of the IGZCUST module worked and that it informed at least some of the changes to the SDM module to improve functionality and performance.

In summary for the reasons set out above: