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

Fecha: 10-Mar-2025

Customer applications

Customer applications

176.

The defendants’ case is that the ICA terms and conditions do not apply to third party customer applications. If, and to the extent that, IBM modules, data and code fragments form part of compiled and link-edited load modules which originated from third party customers, rather than IBM, they do not constitute ICA Programs and therefore their use is not restricted under the ICA.

177.

IBM’s case is that the ICA does not distinguish between ICA Programs provided by IBM and those obtained through other means. Therefore, if Winsopia obtains a copy of an ICA Program from a third party, it is subject to the ICA. IBM does not contend that a customer application becomes an ICA Program when compiled and link-edited. Rather, its case is that a compiled and link-edited customer application contains elements of ICA Program code, inserted or generated as a result of the compilation and link-editing process.

178.

When considering this question, it is important to recognise that the court is not concerned with ownership of physical objects. The ICA is concerned with intellectual property rights and the terms on which permission is granted to use software. Whether a third-party customer application, or any part of it, becomes subject to the terms and conditions of the ICA depends on the use made of the application by Winsopia.

179.

The starting point is to consider the process of creating an executable load module using a customer application.

The customer application is written by the customer in high level language source code or assembly code.

ii)

If the source code includes an EXEC CICS command, it is pre-processed by the CICS translator, which replaces each EXEC CICS statement by generating a sequence of language specific source code statements; those sequences invoke a CALL to a CICS routine called DFHEI1, with a particular parameter list.

iii)

An optimised version of the source code is compiled using an IBM compiler that: (a) translates the business logic of the source code into object code; (b) inserts data or other code invoked by copybook statements in the source code; and (c) generates initialisation code that sets up data structures in working memory and instructions for executing this sequence of code at runtime.

iv)

Where the customer application is written in assembly code, the assembler: (a) converts each assembler mnemonic instruction into its corresponding machine instruction; and (b) expands any macro by executing a call to the relevant macro library and inserting the code instructions or data from the macro definition.

The resulting executable machine code from the compiler or assembler is known as a “User CSECT”.

vi)

The User CSECT is link-edited (or bound) with other User CSECTs and IBM CSECTs, comprising additional executable machine code instructions invoking Language Environment runtime services and/or data to form an executable load module.

vii)

The load module is loaded into the storage area of the mainframe where it can be executed.

180.

It is apparent from the above summary that IBM CSECTs, other code fragments and data are inserted into the customer application during the process of compilation and/or link-editing. They are machine-readable instructions and data generated by the ICA Programs; as such, they each fall within the definition of an ICA Program.

181.

The process of compilation and link-editing does not transform a customer application into an ICA Program. However, the process adds or inserts into the customer application components that form part of the ICA Programs. Use of such ICA Program components is subject to the terms and conditions of the ICA.

182.

Test applications written by, or on behalf of, Winsopia that are compiled and link-edited on the Winsopia mainframe contain IBM CSECTs that are subject to the restrictions on use in clause 4 of the ICA.

183.

Likewise, third-party customer applications that are compiled and link-edited on third party mainframes and supplied to Winsopia contain IBM CSECTs that are subject to the permissions and restrictions on use in the relevant licence. The customer applications may be owned by the customer but such intellectual property rights in the application do not extend to the IBM CSECTs. As is made clear in clause 4.1 of the ICA, ICA Programs are copyrighted and licensed, not sold. In order to study, test and observe the load modules supplied by third-party customers, Winsopia must load them into memory and/or run them on the mainframe. The acts of loading, displaying, running and storage of applications containing IBM CSECTs involve reproduction of the IBM software and are subject to authorisation. Winsopia’s permission to do this derives only from the terms of the ICA. As explained above, permission to use the ICA Programs is subject to the restrictions in clause 4.

184.

It does not follow that all IBM proprietary code in third-party customer applications will be subject to the ICA just because it passes through Winsopia’s possession. If Winsopia loads a third-party customer load module on its mainframe and packages or scrubs it using CPX, this invariably involves copying or reproduction of IBM code within the application. Further, any use of the runtime environment is subject to the terms and conditions of the ICA, as is any code inserted or generated at runtime. However, mere possession of an application does not necessarily convert all IBM code in the application into an ICA Program (although it is likely that such code will be subject to the terms of the licence under which it was originally generated, potentially imposing restrictions on use by the customer under its licence agreement). In each case, it is necessary to examine Winsopia’s actions in respect of the customer application, to determine whether they fell within or outside the scope of permitted use under the ICA.