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

The allegation is that Winsopia carried out reverse engineering of features of Enterprise COBOL for z/OS v4, designed to support I/O declaratives, and transferred to LzLabs load modules containing initialisation code fragments and data relevant to I/O declaratives and branching statements 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.

Initialisation is a service provided by the runtime environment when execution of a COBOL program commences, whereby the data structures within the system memory are defined and populated with compiler-generated code necessary to execute the program. The COBOL compiler generates (i) the object code of the application program, (ii) the COBOL initialisation code, a sequence of machine code instructions and data; and (iii) a data structure that is specific to the storage requirements of each compiled customer application. A routine inserted into the load module calls the COBOL runtime to begin initialisation. The initialisation process involves an inter-dependent arrangement of the initialisation code instructions with the application program and data structures in the load module and the runtime.

COBOL I/O declaratives are a COBOL exception handling feature that allow I/O errors to be handled according to instructions set out by the application developer in application source code. COBOL branching statements, such as “GO TO DEPENDING ON” and “ALTER GO TO DEPENDING ON” statements permit branching to blocks of code according to a variable set out by the application developer in application source code.

During initialisation, the data structures in the runtime are populated with information reflecting the presence of I/O declaratives or COBOL branching statements in the application and their particular characteristics.

For the SDM to support the above functionality, it needed to be able to resolve conflicts between nested declaratives. Nested programs, whereby programs are contained within other programs, are a feature of COBOL. Each nested program might contain one or more I/O declarative statements and there are complicated rules for determining which declarative should gain control. Further, the SDM needed to replicate functionality enabling past executions of certain branching statements to be refreshed. Without support for a compatible interface in the SDM, it could not execute COBOL load modules.

Mr Jaeger’s evidence was that LzLabs’ initial development of these functions was carried out before 2013 using an SDM prototype product running on the Hercules emulator. LzLabs developed functionality for the SDM to execute IBM compiler-generated initialisation code by executing customer compiled and link-edited load modules on the prototype and using a Linux tracing tool, GNU, to step through the initialisation and execution process. It developed support for COBOL branching statements using IBM compiler listings in addition to execution of load modules and use of the tracing tool. LzLabs determined how the SDM COBOL run-time needed to interact with COBOL programs containing EXCEPTION/ERROR declaratives by running different test programs on the SDM prototype. An I/O error was forced, and the various control blocks which form part of the compiled object code were inspected to discover how the COBOL program makes the presence of the declaratives visible to the run-time.

It was accepted by Mr Swanson in cross-examination that, prior to August 2013, the SDM provided initial support for initialisation, I/O declaratives and branching:

“Q. And I think it's also common ground that the initial support for all three of these was in place in the SDM code before August 2013?

A. The initial implementation, yes.

Q. And you will agree that support had been developed by LzLabs based on compiler listings, a modified version of the Hercules emulator and an early prototype of the SDM?

A. Along with use of the GNU debugger, yes.

Q. And that was all before Winsopia came on the scene and before Winsopia had any use for its IBM mainframe?

A. Initial development, yes. ”

By September 2013, LzLabs had a fully functioning COBOL initialisation process which code was added to the SDM Git repository. However, it was still necessary for LzLabs to gain an understanding and interpretation of the data structures that were produced following COBOL initialisation. Professor Donaldson agreed that such information is not publicly available.

In Annex 2 to his first statement, based on a document prepared by Mr Bowler, Mr Jaeger described how SDM support for I/O declaratives was developed through the DR system. Between 2014 and 2015 LzLabs created test programs, which were compiled by Winsopia on the mainframe to generate compiler listings. The compiler listings and load modules were then sent to LzLabs. The compiler listings disclosed the names and addresses within memory of the data structures related to I/O declaratives but not the values that populate them. The load modules included compiler-generated initialisation code and code relevant to I/O declaratives. LzLabs ran the load modules on the SDM, using a tracing tool to step through the processing so as to ascertain the way in which the data structures and fields were used in the IBM runtime.

In cross-examination, Mr Jaeger accepted that the development of compatible interfaces to support I/O declaratives was carried out by LzLabs, using Winsopia’s work:

“Q. … it relied upon Winsopia compiling code with the IBM compiler on its mainframe, didn’t it?

A. Yes, but the development was done by LzLabs.

Q. I see. So … you mean it’s correct to say the development was done by LzLabs but there were acts of Winsopia involved, weren’t there?

A. Yes, the DR system.

…

Q. … these DRs involved Winsopia, didn't they?

A. They did, yes.

Q. Yes, and that was part of the development of the I/O declarative support on the SDM?

A. Exactly… the use of Winsopia greatly speeded up our ability to deliver this functionality in a meaningful timeframe.

Q. It was actually more than that, wasn't it, because you needed to know what the compiler was going to do with the code? You had to have a compiler available to you, didn't you?

A. No … or a customer’s. Somebody would have to send us a load module, that's absolutely the case … ”

The third joint statement by the experts includes the following agreements:

The disputed issues are:

The defendants submit that none of Winsopia’s actions related to ICA Programs. Rather, they were features of the COBOL programming language. The COBOL initialisation data structures are an initialisation interface. I/O declaratives involve control blocks that interconnect with the runtime services that support I/O declaratives. Branching involves interconnecting different parts of the customer application. As such, they are features of the COBOL programming language, defined within compiled customer applications and visible in compiler listings for those customer applications, at least from COBOL v5 onwards.

I reject that submission. The development of support for COBOL initialisation, involving the creation of test programs, production of compiler listings and supply of load modules, was not limited to investigation of customer-defined features that acted as connecting interfaces to the runtime. As set out above, the initialisation process involves a complex inter-dependent arrangement of the initialisation instructions, the program and data structures in the compiled load module and the runtime. The purpose of the discovery process was to understand the operation of the COBOL compiler and runtime in generating and implementing code for the initialisation process and the conventions used to resolve I/O declarative conflicts or implement branching procedures. For the reasons set out above, the IBM COBOL compiler and the Language Environment runtime fall within the definition of an ICA Program for the purpose of the ICA.

Mr Jaeger’s evidence was that the compiler listings were used to discover the declarative data structures for error/exception handlers in programs compiled by COBOL version 4. Winsopia ran the test programs on the mainframe in order to expose elements of the undocumented interplay between the compiler, the program, the data structures and runtime components. The pseudo-assembly instructions in the compiler listings disclosed the names and addresses within memory of the data structures related to I/O declaratives. This amounted to reverse engineering.

Load modules supplied by Winsopia were executed on the SDM with forced I/O errors, enabling LzLabs to inspect the contents of memory, or using a tracing tool, to disclose how the data structures were populated. The interaction between the COBOL compiler and z/OS Language Environment runtime for I/O declaratives functionality is not fully documented publicly. This amounted to reverse engineering by LzLabs that was facilitated by Winsopia.

It is common ground that the compiler listings and load modules were sent by Winsopia to LzLabs. The load modules included initialisation code, data blocks and code fragments, data structures associated with I/O declaratives and COBOL branching statements.

The defendants submit that Winsopia’s acts were observation, study and testing within Article 5(3) of the Software Directive.

The purpose of Winsopia’s DR work was not confined to the functioning of the program to determine underlying ideas and principles; it was to determine how the IBM COBOL compilers and the corresponding runtimes worked together to implement initialisation. It included analysis of instructions generated by the compiler and implemented by the runtime routines. That amounted to expression of the program, rather than its functioning.

In summary on this issue: