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

The Load Module Decompiler (“the LMD”) was a batch utility that was intended to supply an alternative migration path to the SDM for customer load modules that were compiled and link-edited for an IBM mainframe. The LMD was designed to transform the load modules into C language source code macros that could be re-compiled by the Load Module Compiler (“the LMC”) to run natively on x86 systems, including the SDM.

IBM’s case is that, in breach of clause 4.1.3(a) of the ICA, Winsopia used the LMD to decompile and translate, into C language macros, modules and code fragments which constituted ICA Programs. Although a scrubbing process was introduced, it was ineffective in preventing IBM CSECTs or other IBM modules from being processed by the LMD.

The defendants’ case is that the modules and code fragments did not constitute ICA Programs. The LMD was not a decompiler (despite its name) and it did not carry out reverse compilation, reverse assembly or reverse translation. It was designed to filter out IBM proprietary material and there is no evidence that it was ineffective in doing so. Alternatively, it was necessary in order to achieve interoperability of the customer applications with the SDM and was permitted pursuant to Article 6 of the Software Directive.

From 2015 Tom Grieve, a Winsopia developer, worked on developing the LMD, whilst Mr Jaeger worked on the LMC at LzLabs.

Mr Grieve explained in the document attached to his first witness statement that the LMD was designed to convert a z/Architecture load module into C language source code, generally by taking each machine instruction in turn and creating a corresponding C macro.

LzLabs developed the set of C language source code macros, based upon Winsopia’s analysis of the object code in COBOL load modules, using compiler listings and XDC, as set out in Mr Lynch’s COBOL object code analysis reports sent to Mr Rockmann and Mr Cresswell at LzLabs on 1 April 2016.

The LMD used the binder APIs to load the load module into storage for inspection on the Winsopia mainframe and identify the entry point in the program for each CSECT. The LMD processed each of the binary machine code instructions in the load modules in sequence, by transforming them into assembly language mnemonics. It then converted the resulting sequence of assembly language mnemonics into a matching sequence of C language macro calls, one for each type and format of mnemonic. The LMC took the output of the LMD and used the C language macros to create a new executable load module that mimicked the sequence of machine instructions used in the original load module.

There were three versions of the LMD:

In 2016 the LMD was integrated into CPX as a diagnostic tool and was made available to customers as part of the CPX package. Ultimately, the LMD/LMC project was abandoned, following development and completion of the SDM.

The experts’ second joint statement includes the following agreed matters:

The disputed issues are as follows:

The defendants’ case is that filtering rules built into the LMD and additional checks prevented the LMD from operating on IBM CSECTs. Mr Grieve’s evidence was that code in the LMD used two independent checks to implement the filter. First, it checked the name of the CSECT against a list of prefixes, using wildcards (“the Exclusion List”). A second-stage filter checked the CSECT metadata of non-excluded CSECTs to confirm whether any CSECT was produced by a compiler other than the COBOL v4 compiler (“the Compiler Test”). If either the Compiler Test or the Exclusion List resulted in a match, the CSECT would be skipped over and not processed by the LMD.

Mr Stephens elaborated on the system adopted in his second report. In version 1 of the LMD, CSECTs were excluded by comparing the first three characters of the CSECT name with known IBM module name prefixes. Professor Weissman pointed out in his third report that, as at 13 April 2016 in version 1 of the LMD, the exclusion prefix list was limited to eight IBM CSECT prefixes. Mr Stephens explained that, in version 2 of the LMD, the system was enhanced to compare CSECT names with known IBM prefixes of different lengths, using wildcards.

Mr Grieve confirmed in cross-examination that wild cards were not introduced until version 2. Therefore, if the CSECT did not match any of the initial Exclusion List, version 1 of the program would process the CSECT into the corresponding C language instruction. Mr Grieve stated that the Exclusion List was expanded on an incremental basis, as and when it was discovered that the LMD had processed, or attempted to process, IBM CSECTs, such as the CSQ CSECT, which was discovered by Mr Grieve in December 2016 as set out in his email dated 8 December 2016.

Mr Grieve explained that he carried out a further manual check, reviewing the output of the LMD on a line by line basis but in cross-examination he clarified that of the thousands of lines of code produced, he checked probably the first half dozen files.

Mr Grieve accepted in cross-examination that the LMD would process and decompile initialisation code inserted into a user CSECT by the IBM COBOL compiler. For the reasons explained above, I find that such code amounted to an ICA Program within the meaning of the ICA.

Mr Jaeger explained that the purpose of the LMD/LMC was to remove and replace IBM stub CSECTs. Even if a stub CSECT inadvertently was not excluded, so that it was processed into a C language macro by the LMD and compiled by the LMC, it would not be possible for the LMC to execute it, as it would point to an address in the IBM runtime library that would not exist outside the IBM mainframe. That is no doubt correct but it does not detract from the weight of evidence that the LMD was not programmed to exclude all IBM CSECTs and other code fragments.

In his second report Mr Stephens analysed the Compiler Test and concluded that it would be impossible that IBM CSECTs would be processed by version 1 of the LMD (or versions 2 and 3 with the appropriate flag set), on the assumption that no IBM CSECTs were written in COBOL or PL/I. However, Professor Weissman examined that issue in his third report and identified a number of IBM supplied modules that were written in COBOL. On that basis, he concluded that the Compiler Test would not have been effective at removing all IBM supplied CSECTs which were written in COBOL.

In the light of the admitted limitations of the initial filtering system implemented by the LMD, although it improved over time, it is highly likely that the LMD processed IBM CSECTs and other code fragments.

It is not disputed by the defendants that there was transformation of the load module machine code into C language macros. Clearly, this amounted to translation (from one computer code to another) on a natural and obvious meaning of the word.

The defendants contend that the proper characterisation of what the LMD did was not reverse compilation or reverse assembly.

There is a dispute between the experts as to the definition of “disassembly”. Professor Weissman defines disassembly as “the conversion of binary object code into the equivalent human-readable assembly instructions.” IBM assembler language is created in the LMD process implicitly as part of the conversion to C language code, in that an assembly operator must be first determined from the object code representation before it can be mapped to a C macro. Professor Donaldson defines disassembly as “disassembling all or part of the program into its assembler language source statements and then trying to understand the resulting assembly code”. On the basis that the assembler language was an intermediate step and not intended to be read, it did not amount to disassembly.

Professor Weissman described the LMD process in his first report as follows:

“LMD takes the original load module and performs a disassembly on the machine-code instructions in sequence one by one (as described by Tom Grieve in his First Witness Statement). That is, it performs an automatic transformation from the load module’s machine-code (sequences of executable hexadecimal codes), into assembly language (human-readable) mnemonics. This process produces a 1:1 mapping between machine-code representation and assembly language representation, which can be performed in either direction …

LMD disassembles the load module and decompiles the resulting sequence of assembly language mnemonics into a matching sequence of C-language macro calls, one for each type and format of mnemonic. The resulting C-language program therefore appears as a linear set of C-language macro calls, directly tracking the assembly-language representation of the load-module…

… the load module machine-code instruction … is, component by component, disassembled and decompiled by LMD.”

Although he disagreed with the description of the operation as reverse assembly, Mr Stephens agreed with the above summary in his report.

In cross-examination, Mr Grieve accepted that the LMD process involved disassembly before creation of the relevant C macros:

“A. It's -- it's translating 390 machine instructions to C macros.

Q. Yes, but … it does that by disassembling and obtaining the disassembled machine instructions in assembly language, doesn't it?

A. It doesn't disassemble. It doesn't try and produce Assembler source from the object code. It produces C language macros, which is not the same thing at all.

Q. No, but the C language macros correspond to the assembly language, don't they?

A. Yeah, mostly one to one.

Q. Yes. So, as it were, the assembly language is an intermediate step in the production of the C language macros, isn't it?

A. Well, it's the input. It's not -- it's not an intermediate step.

Q. Well, so -- yes, I mean, the macro generator, if that's the correct term, couldn't have operated unless it was fed an input, could it?

A. Yes, that's correct.

Q. And that formed -- that took the form of IBM assembly language instructions?

A. That's correct, yeah.

Q. And those were obtained by disassembly?

A. Yes, okay.”

In August 2018 Mr Moores asked Mr Jaeger about the way in which the LMC could compile an unconditional branch instruction. Mr Jaeger explained:

“We take care of the branch in the LMD part of LMC.

It disassembles the code, and say if the branch is B 20(R11), then it will look where Rl1 was previously loaded, where it was loaded from and what the contents was. So, it effectively disassembles it back to B Label, where we generate a GOTO In C …”

It is clear from the above evidence that the load module object code, including IBM CSECTs and other IBM code, was disassembled by the LMD as part of the process to translate the object code into C language macros.

Professor Weissman states his understanding that “decompilation” is the conversion of object code into any high level language, not necessarily the language from which the object code was originally compiled. The output of decompilation is a program that is in a human readable higher level language than the object code and itself can be compiled. He does not consider that decompilation is restricted to recovery of code written in the original programming language but includes the recovery of code in a different programming language that performs the same function as the machine code from which it was derived as part of the decompilation process. Professor Donaldson notes that the LMD is different from a traditional decompiler because it does not produce high-level language code that can be understood by human developers, but rather rewrites machine instructions into a corresponding C-macro form.

The fact that the high-level language code produced as the output of the LMD was used for an unconventional purpose does not affect the analysis of the process involved, which was self-evidently decompilation of compiled object code into high-level language. This was expressly recognised in the CPX Guide drafted by Mr Palmer, in which he described the LMD as follows:

“The Load Module Decompiler (LMD) is a loosely coupled independent LzLabs component that is shipped with the Centerpiece Export (CPX) software by default, where it provides the ability to de-compile a load module into a format that can be executed natively on the SDM Linux operating system offering significantly improved performance.”

It follows that the LMD process amounted to disassembly, decompilation and translation of the load module, including IBM CSECTs and other IBM modules that were not filtered out.

The defendants submit that the LMD processing was necessary in order to achieve the interoperability of customer applications with the LMC tool and the replacement x86 runtime environment. I reject that submission for the following reasons.

Firstly, the Article 6 exception provides that the authorisation of the rightholder is not required where reproduction of the code and translation of its form are indispensable to obtain the information necessary to achieve interoperability. Decompilation and translation of the load modules by the LMD was not carried out to obtain information to facilitate interoperability with the LMC; rather, it was carried out to transfer every machine code instruction in the entire load module (save for the excluded IBM CSECTs), in the form of C language macros, to the LMC.

Secondly, the LMC was not an independently created program. As set out in Mr Lynch’s reports, the C language macros were part of the LMD/LMC project and were developed through analysis of the COBOL object code using compiler listings and XDC.

Thirdly, Article 6(2)(c) provides that information obtained by reproduction of the code and translation of its form is not permitted to be used for the development, production or marketing of a computer program substantially similar in its expression, or for any other act which infringes copyright. Development of the LMD/LMC was intended to provide an alternative program to execute the load module in an x86 environment by mapping all machine code instructions in the load module to C language macros in sequence on a one to one basis. This included code that was substantially similar in expression to the IBM CSECTs and other IBM code in the load module.

In summary, on this issue: