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

It is not in dispute that in each of the above examples, LzLabs used the DR system to request Winsopia to document various IBM macros whose definitions created DSECTs. The experts agree that, in each case, it is likely that Winsopia created an assembler program that included a call to the macro in question. Winsopia obtained a listing from the assembly of the program, including an expansion of assembler code provided by the macro. From such listing, Winsopia created a word document, containing information about the data area, namely, the offset of the DSECT field, field name, field value and identifier describing the field. The document was sent to LzLabs through the DR system. LzLabs used the information received from Winsopia to create its own versions of the data structures and values in the SDM code, with an equivalent data structure to that defined by the IBM macro.

I accept Professor Weissman’s opinion that for the SDM to reproduce the functionality of the macros, it was necessary for LzLabs to ascertain the DSECT layout of particular data areas so that the SDM could access data fields in a manner equivalent to the IBM mainframe. Contrary to Mr Jaeger’s evidence, the DSECTS generated by expansion of the above macros were not customer specific and did not contain customer data. They were keys that could be used to decipher or interpret customer application data for its use in the SDM.

The parties agree that each of the above allegations raises common issues of principle. The disputed issues are:

IBM’s case is that the macros were provided in source code as part of IMS, z/OS Base or Db2. They are machine-readable instructions and data, or related licensed materials; as such, they are ICA Programs within the ICA definition.

The defendants submit that the macros in question were provided to Winsopia in libraries provided with IMS, z/OS Base or Db2. Each macro is not a discrete unit so as to constitute an ICA Program. Rather, each macro is a sample program or Other IBM Program for the purpose of the ICA.

I reject the defendants’ submission. The macros are supplied with, and form component parts of, IMS v14, IMS v15, z/OS Base v2 or Db2 v10 for z/OS. They are packaged as libraries and supplied in source code form but that does not detract from the fact that they are part of those programs. IMS v14, IMS v15, z/OS Base v2 and Db2 v10 for z/OS are ICA Programs licensed to Winsopia under the terms of the ICA. It follows that the macros fall within the definition of an ICA Program for the purpose of the ICA.

In each case, Winsopia created an assembler program that included a call to the macro in question in order to disclose the expanded assembler code provided by the macro. The resulting assembler listing revealed the structure of the data sets, including the offset of the DSECT field, facilitating location of the DSECT field in memory, the field name, field value, length and type. These details are not published and are not necessary for an application programmer to use the macro but they are needed to implement the DSECT. This amounted to reverse engineering of those parts of the ICA Programs.

The experts agree that the original IBM assembly code was not copied to the SDM, nor provided to LzLabs by Winsopia. Therefore, there was no breach of clauses 4.1, 4.1.2(b) or 4.1.3(b) of the ICA.

However, it is common ground that the information obtained from the expanded assembly code in the form of the source code of each of the expanded macros was sent by Winsopia to LzLabs and used in the development of at least parts of the replacement code in the SDM. The experts agree that for each of the data mapping macros there is a close correspondence between the information represented by the fields of the relevant data structures defined in the SDM code and the fields of the data structure mapped by the relevant IBM macro. Mr Bond’s evidence is that it was used primarily to check information that had already been obtained from an IBM manual but that some of the information was essential for processing the data sets by the SDM. It is clear from the number of DRs seeking similar types of information, that LzLabs needed the expanded assembly code details for implementation or development of the SDM.

The experts agree that the IBM macro data was not replicated in the SDM. However, they also agree that in each case the layout of the SDM C data structure corresponded to the data structure defined by the IBM macro in order to map the same data area. Professor Weissman compared the IBM source code defining some of the macros with the information in the Winsopia tables and its implementation in the SDM code. From this comparison, he found a high degree of similarity between the information in the Winsopia table and the SDM implementation. Based on this comparison exercise, his view is that, although written in different programming languages, a semantic equivalence could be established between portions of the IBM DSECTs and SDM C data structures.

Professor Weissman clarified what he meant by semantic equivalence in cross-examination:

“Q. … So by "copying", you mean semantic equivalence?

A. I mean the same IBM materials are in the SDM.

Q. No, you said "semantic equivalence"?

A. That's what I mean by semantic equivalence.

Q. Semantic equivalence, either you mean copying as in slavishly, which is syntactic equivalent to identity, or you mean semantic equivalence, which is it?

A. As I state clearly in the report, it is not syntactic, and that is not surprising given they're different systems, I make it clear that this is semantic equivalence.”

Professor Donaldson did not disagree with Professor Weissman in any material respect:

“What I see here is that the SDM code has clearly been informed by the information in the table. It's also clear to me that the information in a table has arisen from study of the IBM code in whatever form. What I don't see is reproduction of the IBM code directly in the SDM source code.

…

In my opinion, the information about this structure has been carried across and that's reflected in the SDM source code. I do agree that names have been carried across and very similar names appear in the IBM source code … but for some of the fields, but not all of them.

…

When I say that none of the IBM source code is reproduced in the SDM, I do mean literally reproduced. However, what I'm not saying is that the IBM code is basically there in the SDM, it's just been tweaked to look a bit different. The code in the SDM is fundamentally different from the IBM code, being written in a different programming language with different syntax. But I do agree that the information used to create that code has evidently been derived via this table.

…

What we see in the table is a representation of the information, so I think it would be fair to say that the IBM code had been turned into, or rather aspects of the IBM code had been put into tabular form, and then that table has been used to inform the creation of a data structure that does have the same structural layout as the original IBM data structure.”

The defendants submit that Winsopia’s acts were observation, study and testing within Article 5(3) of the Software Directive. Winsopia was entitled to assemble a program that included a call to the relevant macro and production of an assembler listing of the macro expansion as a licensed user of its mainframe. In so doing, it is said that Winsopia was observing, studying and testing interface information, namely the data fields, lengths, offsets, data types and descriptions of the data areas.

That submission is rejected. The purpose of Winsopia’s analysis was not confined to the functioning of the macros to determine underlying ideas and principles. It already knew the function of each macro; this was information that was publicly available. Winsopia’s analysis was to ascertain details of the DSECT field in memory, the field name, field value, length and type so that the same details could be replicated or mirrored in the SDM. That amounted to expression of the program, rather than its functioning.

The Article 6 exception in the Software Directive is not applicable. It was open to LzLabs to adopt a solution, whereby they designed their own macros and copybooks, using different data structures, and recompiled customer source code applications using the replacement macros and copybooks. Therefore, Winsopia’s analysis was not necessary in order to achieve interoperability of customer applications with the SDM. Further, although the replacement code mapping in the SDM was written in a different programming language to that used in the ICA Programs, it used Winsopia’s translation of the macro code to achieve semantic equivalence in the SDM code. That was substantially similar in expression to the IBM mapping of the data areas for the purpose of Article 6(2)(c).

In summary on this issue: