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

The allegation is that Winsopia reverse engineered part of the IBM z/OS Binder, software which assists in transforming object code modules into executable programs. Specifically, it is alleged that Winsopia reverse engineered the mechanism in the Binder for compressing program objects, including disassembly of modules IEWBXZIP and/or IEWBXZP6 (“the Compression Modules”).

The defendants’ case is that no disassembly or decompilation tools were used by Winsopia to perform its analysis of the compression used by the Binder. The analysis carried out by Mr Lynch by searching for the relevant hexadecimal instructions amounted to observation, studying and testing permitted by Article 5(3) of the Software Directive. Alternatively, the information gleaned from any disassembly was necessary to achieve interoperability between the CPX/CPI and compressed program objects.

The z/OS Binder is a utility provided with z/OS that converts the output of language translators and compilers into an executable program object, which can either be read directly into virtual storage for execution or stored in a program library. Within the Binder there is a compression option that can be used to compress the additional data that the Binder stores, which reduces the disk storage needed.

On 4 September 2015, LzLabs opened DR-1254, seeking information from Winsopia about the program object compression performed by the z/OS Binder.

Mr Lynch was unable to find the required information about the Binder compression in published documentation. Therefore, he took an available program attached to an earlier DR and used the Binder to link it, both with and without the compress option, identifying patterns within the data that indicated use of dictionary compression.

Mr Lynch then used AMBLIST, a batch utility provided with z/OS, to display a list of the CSECTs in the load module and to show them in hexadecimal form. An analysis of the CSECTs indicated that the Compression Modules were responsible for dictionary compression. Mr Lynch also searched the hexadecimal code of the modules and discovered the specific instruction responsible for dictionary compression within the Binder, verified by decoding the surrounding instructions. Subsequently, this was confirmed by publicly available information.

On 21 September 2015, Mr Lynch responded to DR-1254 with the following comment:

“What you are missing is the dictionary.

We do not have any source code available as this is a hardware implementation.

Further analysis of the Binder compression process shows that both the dictionary and data to be compressed are held in a Data Space.

The dictionary used appears to be exactly the same as that in the … load module member ...

The output of the compression process results in data consisting of sequences of 9 bits.

I think it is likely that the dictionary is propriet[a]ry to IBM so will need legal clearance before documenting.”

In his further answer to DR-1254 on 24 September 2015 Mr Lynch stated:

“The dictionaries used for the compression and expansion are not part of the Program Object data, they are hard coded in [the program]. I am sure therefore that they are proprietary to IBM which is why I am concerned about copying them into this case.

There are in fact two compression dictionaries and two expansion dictionaries in [the module]. I believe there is one each for the two 'zip' areas seen in program … as mentioned in the case description.

I have written a small test program to test these dictionaries against a small section of compressed and uncompressed data … and successfully compressed and expanded it using both the … instruction and with a service routine … So I can be certain that these are the correct dictionaries used by the Binder.”

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

The disputed issues are:

The Compression Modules form component parts of the z/OS Binder supplied by IBM with z/OS Base V2, an ICA Program. For the reasons set out above, the modules within the Binder are ICA Programs for the purpose of the ICA.

Mr Lynch’s evidence was that he ran the AMBLIST utility against one of the Compression Modules within the Binder program to display the hexadecimal form of the CSECTs contained within the sub-modules. Mr Stephens agreed in cross-examination that the use of AMBLIST gave Mr Lynch the means to look at the structure of the IBM Binder load module and then look at the code and data in some of the CSECTs.

Mr Lynch decoded the instructions surrounding the compression instruction in the load module to ascertain that the Binder relied on hardware compression. In cross-examination he accepted that this amounted to disassembly of part of the code. His evidence that he carried out the disassembly in his head does not change the characterisation of his action as disassembly.

Mr Lynch stated in his DR response that he carried out further analysis of the Binder compression process which showed that both the dictionary and data to be compressed were held in a Data Space. From that analysis, he deduced that the dictionary used appeared to be exactly the same as that in the compression load module member. Although he could not recall exactly what he did, he agreed that he must have carried out runtime analysis of the Binder software:

“Q. The DR itself doesn't say what further analysis you carried out for this and you don't deal with it in either of your statements but in order to do this you presumably must have done one of two things: either you disassembled the relevant part of the Binder code or you used a tool like XDC, or a trace or something, to analyse the IBM Binder software as it was executing?

A. Well, I certainly didn't analyse the Binder as it was executing. It’s a large complex piece of software, trying to analyse it would be an impossible task. I don’t recall how I did this analysis to determine it was using what’s called a data space.

…

Q. In order to conclude that the dictionary being used by the binder compression process is the same as the one in that module we see the name of, you must have compared the data and the binder’s working memory as it executed decompression with the hexadecimal in that module?

A. I presume so but I – I just can’t recall.”

Mr Swanson’s evidence was that Mr Lynch’s further analysis must have involved runtime analysis and decoding the instructions, either by hand, using a tool such as XDC, tracing, or disassembly. In cross-examination, Mr Stephens agreed that, based on Mr Lynch’s oral evidence on this issue, he must have performed some sort of runtime analysis and, if so, he could have used tools such as a SLIP trap or XDC.

The above steps amounted to reverse engineering in breach of clause 4.1.3(a) of the ICA.

The defendants submit that Mr Lynch’s analysis was a quintessential example of observing, studying and testing the Binder modules in order to understand their ideas and principles of operation. I reject that submission. It is clear that Mr Lynch’s analysis went far beyond observation, study and testing of the ideas and principles underlying the Binder modules. It extended to a detailed disassembly and decoding of the object code of the Compression Modules, followed by an analysis of the execution of each instruction involved in compression and decompression. Such analysis investigated, not just the input and output of the Binder program but how the Binder program implemented its compression function. That amounted to analysis of the expression of the program, rather than its functioning.

I reject the defendants’ contention that Winsopia is entitled to rely on Article 6 of the Software Directive because the analysis was not necessary for interoperability. As explained by Mr Lynch in his first witness statement, the information from the analysis was required to avoid the need for customers to recompile their applications and to improve marketability of the SDM:

“LzLabs needed to decompress the executable application program in order for it to execute on the SDM. Building the decompression functionality into the SDM would avoid the need for customers to recompile their application with the compression feature turned off at the binder stage. To decompress a load module, you need to understand how it was compressed in the first place.

…

Given that a big selling point for the SDM is that it would allow customer applications to be migrated off the mainframe without the need to recompile them, LzLabs did not want to have to ask its customers to do this recompilation to get around the compression.”

In summary, on this issue: