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

This allegation concerns three alleged scrubbing failures.

The first, recorded in a Bugzilla ticket dated 21 October 2020, concerned an incident in which Winsopia used CPX to process a number of load libraries in response to DR-191 but scrubbing failed in relation to certain C programs with the result that IBM copyright material was found by LzLabs in one of the load modules.

In cross-examination Mr Whittingham agreed that this was an example of a scrubbing failure:

“Q. So what's happened here, see if you agree with me, is that Winsopia has attempted to scrub a number of load libraries in response to a DR, DR-191, but scrubbing has failed in relation to some C programs with the result that what's described as IBM copyright material has been found by LzLabs in one of the load modules; do you agree with that?

A. Yes.”

As a result of this scrubbing failure, Mr Whittingham made a commit to the Git repository, adding a substantial number of additional CSECTs to the scrub list.

Mr Althen of LzLabs UK raised this issue with Mr Rockmann and others at LzLabs by email dated 21 October 2020:

“We have discovered an issue in the CPX Load Module scrubbing process. Not all Copyright Material is being removed. We have obviously imported those load modules on a number internal and [a customer] based SDM nodes. Do we have to do something, remove them, clear instances out ?”

At the request of Mr Rockmann, Mr Althen sent an SDM AMBLIST output, identifying many IBM CSECTs containing IBM copyright statements that had been missed from the scrubbing exercise. The output included, in relation to the IBM CSECTs: (i) a hexadecimal dump of the binary content code of the CSECT, (ii) a plain text interpretation of any EBCDIC encoding and (iii) a plain text interpretation of any ASCII encoding.

On the following day, Mr Rockmann sent an email to Mr Althen, stating:

“Given the tight timelines of this engagement we currently have to continue. We will need to clean up later on.”

Mr Swanson and Mr Stephens agree that all but four of the unscrubbed CSECTs were members of the SCEELKED or SEZACMTX libraries distributed with z/OS. As such, they were ICA Programs as defined by the ICA. Although they appear to have originated with a third-party customer, Mr Whittingham acknowledged that the load modules were processed by Winsopia using CPX and sent to LzLabs.

The second allegation concerns OS/VS COBOL CSECTs. On 22 October 2020 Mr Bowler commented in a Jira ticket:

“I am sorry but the load libraries in DR-189 package … will have to be sent back to Winsopia and scrubbed again because they contain some proprietary csects. Please can you request a redelivery and advise Winsopia that all csects whose names begin with ILBO must be added to the scrub list. ”

The following morning, Mr Vitale of LzLabs UK sent an email to Mr Whittingham regarding CSECTs that were outside the conventional three letter prefix and needed to be added to the scrub list:

“In a recent CPX package we had some OS/VS COBOL programs it appears they still contain some proprietary IBM csects. Can you update the scrub list to include ILBO*,

The load library in question on WINSP system is …

Once you have tested and the csects are scrubbed correctly, can you recreate a CPX package with the scrubbed library.”

In cross-examination, Mr Whittingham accepted that the relevant CSECTs in fact used a standard IBM prefix, albeit a four letter prefix, and would have been caught by the use of wild cards, not yet implemented. He added all CSECTs he could find that shared the relevant OS/VS COBOL prefix to the scrub list.

On 23 October 2020, Mr Whittingham circulated an email, stating:

“As mentioned in the meeting on Thursday, it has become apparent that the LZSLIST entry in CPX has become out of date. I have spent the last couple of days adding all the CSECTs I could discover that were missing.

I would like to request that, for the time being, scrubbed libraries, especially from newly arrived customer files, are scanned for copyrighted CSECTs using … You can see the JOB I have been using … brazenly plagiarised from something John put together (thanks JB!) Please notify me of any new CSECTs which need to be added.

I see this as an interim solution until I can implement something more permanent.”

Mr Swanson and Mr Stephens agree that the unscrubbed CSECTs were members of the SCEELKED or SEZACMTX libraries distributed with z/OS. As such, they were ICA Programs as defined by the ICA. As above, although they appear to have originated with a third-party customer, Mr Whittingham acknowledged that the load modules were processed by Winsopia using CPX and sent to LzLabs.

The third allegation concerns IMS RESLIB CSECTs. DR-216 was opened on 8 September 2020, requesting Winsopia to process and scrub a customer dataset, and create a new CPX package for the SDM. Winsopia duly created a new CPX package and sent it to LzLabs using the LzLabs FTP server.

By email dated 25 October 2020 Mr Vitale informed Mr Maddison of Winsopia that the CPX package created by Winsopia included the IMS SDFSRESL load libraries, in which some modules had been scrubbed but others still contained IBM copyright messages.

It is common ground that IMS Versions 12, 14 and 15 are ICA Programs. SDFSRESL is a library that contains standard IMS resources supplied as part of IMS. It follows that these IMS CSECTs are components of an ICA Program, and therefore an ICA Program.

In summary on this issue: