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

The scope of the licence granted and authorised use in clause 4.1 applies to the ICA Programs.

ICA Program is defined in clause 1.3 as:

“an IBM Program licensed under Part 4 of this Agreement.”

Other IBM Program is defined as:

“an IBM Program licensed under a separate IBM licence agreement (e.g., IBM International Program Licence Agreement).”

Non-IBM Program is defined as:

“a Program licensed under a separate third party licence agreement.”

It is common ground that the ICA Programs are as set out in section 6 of the Agreement for Third Party Program Access, signed by IBM, Winsopia and RSM on 15 August 2013 (together with the updated and supplemental ICA Programs) and listed above. The issue is whether, as submitted by IBM, the constituent parts of such programs fall within the definition of an ICA Program, or as submitted by the defendants, for the purpose of the ICA, the definition of an ICA Program is limited to the whole of any such program.

Program is separately defined in clause 1.3 as:

“the following, including the original and all whole or partial copies:

a.

machine readable instructions and data;

b.

components;

c.

audio-visual content (such as images, text, recordings, or pictures); and

d.

related licenced materials.

The term “Program” includes any ICA Program, Other IBM Program, or Non-IBM Program that IBM may provide to the customer. The term does not include Machine Code or Materials.”

The natural and ordinary meaning of the above words used is that an ICA Program falls within the definition of a Program; and a Program is defined as comprising any and/or all of the computer artefacts described in a. through to d. If the intention were to refer to an ICA Program only in its full, composite form, one would expect that to be stated expressly. The reference to the inclusion of whole or partial copies of those artefacts in the definition is a clear indication that a Program could be less than the sum of its parts. Analysis of the words used suggests that an ICA Program includes whole or partial copies of the program and any of the constituent parts described in a. through to d.

Each ICA Program is a collection of component parts, including function and data software code, code fragments, routines and sub-routines. The descriptions of the artefacts in (a) to (d) are general and broad. Machine readable instructions and data encompass software in source code, assembler language or object code. This includes control sections (“CSECTs”), macros (assembly code statements that are expanded to machine-readable code during assembly), copybooks (source code statements that are expanded to machine-readable code during compilation) and metadata (data about data). Components are distinct from the whole program, comprising any identifiable part of an ICA Program, including software modules, routines and sub-routines. Images and text include software manuals for the ICA Program. Related licenced materials is self-explanatory, including licensed materials necessary to enable the ICA Program to be run on the mainframe.

Support for that construction can be found by examining the design of computer software programs, such as the ICA Programs in this case. Professor Weissman’s evidence is that almost all non-trivial programs are built, not as a single, large component but as multiple, separate components that are interconnected. The number of individual components and the method by which they are interconnected is a matter for the designer of the program. The advantages of such a design approach include the ability to alter one of the components, such as the runtime component, without any impact on, or the need to alter, the other components, such as the application program component.

Similarly, it is a matter of choice for the designer of the program as to when and how code is inserted and/or generated by a program component in response to instructions in a customer application. A program component can generate and insert in-line code that implements functionality directly into an application program; alternatively, it can generate code that calls a service from another component; or a combination of the above. Functional code can be generated at the time that the instruction is processed by the program component or code can be inserted to generate functionality dynamically at a later stage, such as runtime. Regardless of when or how ICA Program code is generated or inserted, it forms an essential part of the computer program.

It follows that the natural and ordinary meaning of ICA Program encompasses each of its constituent parts as well as the whole program.

The defendants submit, correctly, that the identified ICA Programs have each been individually licensed as discrete units. However, it does not follow that the scope of the licence for each discrete unit is engaged only in respect of that product as a whole, rather than each component part of the program.

It is said by the defendants that where IBM intends to refer to “portions” or “parts” of the ICA Programs, that is stated expressly. There are express references to portions or parts of the ICA Programs where the context requires distinction between specific parts of a program and others. An example is the reference in clause 4.1.1(a) to “machine-readable portion”; it is logical to distinguish this portion from text or other parts of the program that are not read by machine because the context is the Designated Machine on which such portion may be used. A further example is the reference in clause 4.1.1(d) to “any portion” provided in source form or marked restricted; it is logical to distinguish these parts from other parts of the program because they are subject to specific additional restrictions on use. Those references do not override the clear definition of Program which includes “components” and other parts.

As submitted by IBM, the restrictions on use are inextricably linked to the authorised use under the ICA. The scope of the licence granted in clause 4.1 is for use of the ICA Programs. If the defendants’ construction were correct, Winsopia would not be permitted to use any component part of an ICA Program unless it involved use of the whole program, including all component parts. The defendants accept that an ICA Program may comprise many thousands or even millions of individual computer programs, routines and/or sub-routines, each themselves comprised of numerous pieces of code fragments, routines and sub-routines. Executing an application on the mainframe may use many different component parts of different programs but none uses any named ICA Program in its entirety. The defendant’s construction would entail a restriction on use that would deprive Winsopia of any real benefit from the ICA. In practice, it would be unable to compile, assemble, link-edit and execute applications. Such restricted use of the software is unrealistic and would not make commercial sense. It is a very strong indication that the defendants’ construction is wrong.

In conclusion on this issue, the permission granted and restrictions imposed in respect of the use of the ICA Programs under the ICA apply to the whole of each identified ICA Program and to any component part of such program.