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

The allegation is that Winsopia carried out reverse engineering of Enterprise PL/I for z/OS v4 and the Language Environment PL/I runtime to develop support for PL/I condition handlers and transferred to LzLabs load modules containing code fragments and data blocks relevant to PL/I condition handlers in breach of clauses 4.1, 4.1.1(a), 4.1.3(a) and 4.1.3(b) of the ICA.

The defendants’ case is that these features are interfaces and/or other functionality provided by the relevant programming languages; as such, they are not ICA Programs and Winsopia was entitled to study, test and observe them pursuant to rights conferred by Article 5(3) of the Software Directive.

Condition handling is a feature of the PL/I programming language that allows a customer application to specify, by the inclusion of “ON” statements, what action should be taken in response to events and errors that might occur during execution of the program.

During compilation, the PL/I compiler generates machine code CSECTs in the application representing the presence of condition handlers of a particular type. This code is used to initialise what I will refer to as the “I” and “C” data structures in the dynamic storage area of the runtime. These structures are populated with values representing the PL/I condition handlers that feature in the load module. Another area of the runtime contains pointers to what I will refer to as the “A” data structures, a set of chained structures, each one representing a different ON statement invoked by the application during runtime. When a qualifying condition occurs, the runtime cycles through the “A” data structures to find a relevant statement that matches the condition.

Mr Jaeger’s evidence is that the SDM’s support for PL/I condition handling was primarily written by Tim Sneddon, a PL/I developer at LzLabs. Mr Jaeger states in his second and third witness statements that in order for the SDM to provide alternative support for a PL/I application compiled and link-edited to run on an IBM mainframe, it needed to be able to locate and identify PL/I conditions in the load module. Winsopia produced PL/I compiler listings and load modules through the DR system, which were used to understand and document data structures and constants used in the process. In particular, PL/I compiler listings, containing pseudo-assembly language representation of the “I” and “C” code, were studied to determine the function, variable location and means by which the “I” structure could be identified, the layout for the “C” structure and the constant values or signal codes for both. Further, the “I” initialisation routine in load modules was studied to understand how the relevant area in memory was generated.

Mr Jaeger’s evidence as to the source of LzLabs’ understanding of the “A” structure was unsatisfactory. In his second witness statement, Mr Jaeger stated that the layout of the “A” structure was identified from sample materials in the z/OS Language Environment Debugging Guide, rather than through DRs. However, he was unable to identify the relevant part of the guide that contained such information or explain in evidence how such information was obtained. Although published IBM documentation makes reference to the relevant structures, it does not disclose full or detailed information about location or layout of the same, as is agreed by the experts. In his third witness statement, Mr Jaeger stated that the compiler listings contained references to the “A” structure but he accepted in cross-examination that this was incorrect.

The discoveries by LzLabs were reflected in the SDM source code file, which replicates, at least in part: (i) the means by which the “I” and “C” structures are located at runtime; (ii) the layout and structure of the “I” and “C” data structures; and (iii) the role of the “A” structure and its relationship with the “I” and “C” structures. In cross-examination Mr Jaeger agreed that the layout and fields of the “I” data structure were exactly replicated in the SDM.

Professor Donaldson agreed in his evidence that it would have been very difficult for LzLabs to derive these details from the compiler listings.

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

The disputed issues are:

IBM’s case is that the PL/I compiler is part of Enterprise PL/I for z/OS v4 and the IBM Language Environment runtime is part of z/OS. As such, they are components falling within the definition of an ICA Program.

The defendants submit that none of the data structures falls within the definition of an ICA Program. They are aspects of the PL/I programming language condition handling feature. As such, they are inherently unprotectable data formats and/or programming language features. The object code output by the PL/I compiler gives effect to the programmer’s choice of condition handlers in their PL/I source code, their bespoke source code for implementing specific condition handlers, and any custom conditions specified by the programmer. The specific values put into these data structures will reflect the programmer’s decisions. The data structures are not alleged by IBM to be supplied in any particular form by IBM to Winsopia. Rather: Structures “I” and “C” are generated dynamically, in response to instructions being given by Winsopia to the PL/I compiler, causing the compilation of test programs; and structure “A” is populated dynamically.

I reject the defendants’ submission. The “I” and “C” data structures are code generated by the PL/I compiler; the “A” data structure is present in the runtime. It is correct that the specific values generated by the compiler give effect to the programmer’s choice of condition handlers in the PL/I source code but that is true of all IBM mainframe processing. The fact that the structures are generated dynamically during compilation or at runtime does not detract from their characterisation as components of the PL/I compiler and Language Environment runtime. As such, each structure is an ICA Program within the meaning of the ICA.

Winsopia used compiler listings generated by test programs to disclose the pseudo-assembly language representing the object code generated by the IBM PL/I compiler. The purpose was to expose the location, layout, structure and inter-relationship of the “I”, “C” and “A” structures. That amounted to reverse engineering of the PL/I compiler. It is not clear what method was used to obtain an understanding of the “A” data structure. Professor Donaldson confirmed in cross-examination that he agreed with Mr Swanson’s conclusion in his first report that the “A” structure was not referenced in compiler listings. Mr Swanson agreed in cross-examination that the “A” structure for an older version of PL/I was documented in a 1973 IBM Manual but Professor Donaldson agreed in cross-examination that, although it represented the same concept, the layout, flag and field names, and overall size of that structure were different to the “A” structure under consideration in this case. The defendants’ suggestion that the source could have been the IBM published sample dumps does not stand up to scrutiny because, as Professor Donaldson accepted in cross-examination, the sample dumps relied on did not give any explanation as to the meaning of the disclosed fields, the meaning of the values in the fields, the fact that the data areas related to PL/I condition handlers or their function. In cross-examination, Mr Swanson accepted that LzLabs could have deduced the detail of the “A” structure and constant values from a combination of what was published and observation of compiler listings. Professor Donaldson stated that this was “plausible” but put it no higher than that. Considered in the light of Mr Jaeger’s unsatisfactory evidence on this issue, the evidence as to the method used to understand the “I” and “C” structures, and in the absence of a plausible explanation from LzLabs in the Git comments, it is likely that this was also the result of reverse engineering.

The defendants’ case is that Winsopia’s actions amounted to permitted observation, study and testing. The use of test programs to generate compiler listings in order to determine the underlying ideas and principles relating to the relevant data structures contained within compiled customer applications.

I reject that submission. Winsopia’s production of the compiler listings disclosed the pseudo-assembly language representing the object code generated by the IBM PL/I compiler. This enabled Winsopia to follow each instruction in sequence to gain an understanding as to the compiler-generated code inserted into a PL/I load module by the IBM PL/I compiler to implement language features used in the PL/I source code of the application. That concerned expression of the program, rather than its functioning.

Winsopia transferred to LzLabs pseudo-assembler code generated by the IBM PL/I compiler, together with load modules, containing data blocks and code fragments inserted into the application code by the PL/I build toolchains. This amounted to breach of clause clauses 4.1, 4.1.2(b) and 4.1.3(b) of the ICA.

In summary, on this issue: