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

IBM’s case is that, in respect of those parts of the claims that are found to be prima facie statute-barred in contract and/or tort, the defendants are deprived of any limitation defence by reason of section 32(1)(b) and/or 32(2) of the Limitation Act 1980.

The defendants’ case is that they did not deliberately conceal the link between LzLabs and Winsopia (section 32(1)(b)), or deliberately commit any breach in circumstances in which it was unlikely be discovered (section 32(2)). Further, IBM has known about the link between LzLabs and Winsopia since 2013 and could with reasonable diligence have discovered the link from that date onwards.

The relevant provisions in Section 32 of the Limitation Act 1980 are:

“(1)

… where in the case of any action for which a period of limitation is prescribed by this Act, either—

…

(b)

any fact relevant to the plaintiff’s right of action has been deliberately concealed from him by the defendant;

…

the period of limitation shall not begin to run until the plaintiff has discovered the … concealment … or could with reasonable diligence have discovered it. References in this subsection to the defendant include references to the defendant’s agent and to any person through whom the defendant claims and his agent.

(2)

For the purposes of subsection (1) above, deliberate commission of a breach of duty in circumstances in which it is unlikely to be discovered for some time amounts to deliberate concealment of the facts involved in that breach of duty.”

Thus, there are two alternative legal bases from which IBM argues that the defendants are deprived of reliance on their limitation defences:

The section 32(1)(b) test was considered in Canada Square v Potter [2023] UKSC 41:

“[96] What section 32(1)(b) requires is that the defendant has “deliberately concealed” “a fact relevant to the plaintiff’s right of action”. The words “the plaintiff’s right of action” must refer to the right of action asserted by the plaintiff in the proceedings before the court. That follows from the terms of section 32(1), so far as material: “… where in the case of any action for which a period of limitation is prescribed by this Act … any fact relevant to the plaintiff's right of action has been deliberately concealed from him by the defendant …” The right of action asserted by the plaintiff may or may not be well-founded: that is a matter which will only need to be determined if the plea of limitation is rejected. As to the words “a fact relevant to the plaintiff’s right of action”, that phrase has been interpreted as referring to a fact without which the cause of action is incomplete: see, for example, Arcadia Group Brands Ltd v Visa Inc [2015] EWCA Civ 883; [2015] Bus LR 1362. That interpretation is not in issue in this appeal, but it makes sense: if the claimant can plead a claim without needing to know the fact in question, there would appear to be no good reason why the limitation period should not run.

…

[98] … the word “conceal” means to keep something secret, either by taking active steps to hide it, or by failing to disclose it. A person who hides something can properly be described as concealing it, whether there is an obligation to disclose it or not.

…

[109] The elaborate and confusing analyses of section 32(1)(b) put forward in Williams, The Kriti Palm and the present case represent a wrong turning in the law. It should return to the clarity and simplicity of Lord Scott’s authoritative explanation in Cave (para 60):

“A claimant who proposes to invoke section 32(1)(b) in order to defeat a Limitation Act defence must prove the facts necessary to bring the case within the paragraph. He can do so if he can show that some fact relevant to his right of action has been concealed from him either by a positive act of concealment or by a withholding of relevant information, but, in either case, with the intention of concealing the fact or facts in question.”

What is required is (1) a fact relevant to the claimant’s right of action, (2) the concealment of that fact from her by the defendant, either by a positive act of concealment or by a withholding of the relevant information, and (3) an intention on the part of the defendant to conceal the fact or facts in question.”

The section 32(2) test was summarised in Canada Square at [153]:

““Deliberate”, in section 32(2), does not include “reckless”. Nor does it include awareness that the defendant is exposed to a claim. As Lord Scott said in Cave at para 58, the words “deliberate commission of a breach of duty” are clear words of English. They mean, as he added at para 61, that the defendant “knows he is committing a breach of duty.””

In this case the relevant fact that was concealed is said to be the connection between Winsopia and LzLabs; in particular, that Winsopia was a wholly-owned subsidiary of LzLabs, whose sole or primary purpose was to assist LzLabs to develop the SDM, using access to the mainframe software and breaches of the ICA, as set out in Paragraph 11 of the Further Particulars of Concealment dated 21 October 2022:

“11.1

It was decided to use the Second Defendant as a “shell” for the purposes of entering into the ICA and acquiring access to IBM proprietary materials licensed thereunder, including the IBM Mainframe Software…

11.2

From the moment of its incorporation onwards, the sole or primary purpose of the Second Defendant was to assist the First Defendant and its associates (including at least Texas Wormhole and OnTarget Group) and later the Third Defendant in the development of the SDM, including by committing multiple breaches of the ICA.

11.3.

At the same time, the Defendants went to great lengths, and took repeated steps, to hide the fact and nature of the connection between the First and Second Defendants. Those steps, which are further particularised below, were taken so as to give to any external observers, and in particular the Claimant in the event of audit or litigation, the false impression that the SDM had been developed lawfully by the First Defendant, without any involvement of the Second Defendant and thus without any breaches of the ICA being committed or procured. In the premises, each and every one of those steps was taken in order to conceal (i) the multiple breaches of the ICA committed by the Second Defendant during the development of the SDM; and (ii) the First and Third to Fifth Defendants’ procurement of those breaches.”

IBM’s case is that it did not discover, and could not with reasonable diligence have discovered, the concealment prior to 25 August 2020. Accordingly, the six-year limitation period runs from 25 August 2020, with the result that all the Original Claims and New Claims were brought within time.

The defendants’ case is that there was no deliberate concealment and that IBM had sufficient knowledge to trigger time running for the purposes of section 32, more than six years before the date of issue of proceedings, either because it had actual knowledge of what it alleges was concealed or because it could with reasonable diligence have discovered it.

The allegations of deliberate concealment are that the defendants:

In respect of the first allegation, IBM’s case is that Winsopia was set up as an independent corporate entity to create the appearance of separation between the ICA licensee and LzLabs.

On 13 March 2013, following a meeting and conference call with LzLabs and Texas Wormhole, Mr Rastall sent an email to Mr Rockmann, stating:

“We have a common initial understanding of the long term goal and how we may proceed in the short term. Much will depend on if and when we have mainframe access. In summary we have a green light from everybody. The next step is creating a company structure for us to operate with here”.

In cross-examination, Mr Rastall agreed that the long term goal was the use of a UK company which would operate a mainframe for the purposes of assisting in the development of the SDM. He also confirmed that, from the outset of his involvement in the project, he was concerned that if IBM learnt that Winsopia was using its mainframe to assist in the development of a competitor product, IBM could take steps to thwart the development of the SDM by, for example, terminating the software licence:

“Q. The fact that Winsopia was assisting in the development of the SDM was not a fact which you would have wanted IBM to know; is that fair?

A.

Yes.

Q. And similarly, the fact that Winsopia was owned by LzLabs was not a fact which you would have wanted IBM to know?

A. I thought it was inevitable that they would know.

…

Q. So your evidence is that you would not have wanted IBM to know that fact; is that right?

A. Yes.”

On 15 March 2013 Winsopia was incorporated.

On 18 June 2013, David Janicek of Texas Wormhole emailed Mr Moores and Mr Rockmann with an outline scope of work for Winsopia:

“This document will serve as a starting point as to the workload I will be deferring to Keith's company due to my inability to access IBM copyrighted materials as well as the fact that I'm an admittedly poor QA. :)…

A)QA 1) I won't begin to try to list every single test that QA will need to attempt. Let's just say there will literally be thousands…

B)

Research - this is the research I have to throw over the “Chinese wall” …

C)

Development - tasks that need to be built to execute on the z/OS systems…”

Mr Moores made the following observation regarding recruitment of employees for Winsopia:

“It would be preferable, as Thilo implies, for these folks to be in the UK. I.e., no business or personal relationship with anyone here, etc. I don't think this is gonna be much of a problem for Keith. ”

Mr Moores agreed that it was important that there was no outward appearance of a relationship between LzLabs and Winsopia, stating that would be “a real plus” but disagreed that there was any intention to conceal this from IBM.

On 5 July 2013 Winsopia was acquired by LzLabs as a wholly-owned subsidiary.

On 9 July 2013, Mr Rastall emailed Mr Wilson at RSM, asking RSM to obtain pricing for an IBM software licence. Mr Moores and Mr Rockmann discussed whether they should buy a new mainframe from IBM or a used mainframe from a third-party reseller. Mr Moores’ view was that it would be preferable to buy a new mainframe. However, Mr Rastall explained to Mr Moores and Mr Rockmann in his email dated 27 July 2013 that the advantages of buying a used machine went beyond reduced costs:

“IBM would not be involved AT ALL with supply of hardware, install, de-installs, upgrades, capacity planning, monitoring usage, visiting Winsopia premises. IBM’s only involvement with Winsopia once User Agreement signed would be to deliver the software to RSM partners on our behalf”.

On 29 July 2013 Mr Rastall forwarded to Mr Rockmann a quotation for the purchase of a used mainframe from GMT360, stating:

“Only GMT360 would be involved in supply, install, de-install, maintenance, including spare parts”.

Notwithstanding Mr Rockmann’s protestation that this discussion was solely about cost-savings, on the face of the emails the advantages identified by Mr Rastall extended to the absence of usage monitoring by IBM or visits by IBM to Winsopia. In cross examination, Mr Rastall agreed that if IBM had been involved in the supply, relocation and maintenance of the mainframe, there would be an obvious risk that IBM would learn that Winsopia was using the mainframe to enable the development of the SDM. By purchasing a used mainframe, in addition to the cost saving, it would avoid IBM learning that Winsopia would be using it to assist in SDM development:

“Q. So, if IBM was involved in the supply, relocation and maintenance of the mainframe, there would be an obvious risk that IBM would learn that Winsopia was using the mainframe to enable the development of the SDM; is that fair?

A.

Yes.

Q. And buying a used mainframe, as you were suggesting in the email we just looked at, was a suggestion you were putting forward to cut IBM out of the loop in order to avoid it learning that Winsopia would be using the mainframe to assist in SDM development?

A. The main focus of buying a used mainframe was cost. The cost differential was absolutely huge. This was --this would be a byproduct of that.

Q. Well, when you say "a byproduct", I think what you mean is an additional reason?

A. Yes.”

On 1 August 2013 Winsopia purchased the used mainframe from GMT360, which was initially installed at RSM’s offices and later moved to Winsopia’s office in Farnborough.

RSM negotiated the terms of the ICA for Winsopia, avoiding any direct contact between Winsopia and IBM, although the ICA was signed by Mr Rockmann and Mr Rastall for and on behalf of Winsopia. Mr Rastall’s evidence was that he had a close working relationship with Mr Wilson at RSM and expected him to keep Mr Rastall’s exchanges with RSM confidential.

During an exchange of messages between Mr Cresswell and Mr Rockmann on 25 March 2020, Mr Cresswell referred to Winsopia as “a shell” and suggested that his proposal to shut down Winsopia would create “even greater separation between LzLabs [and] the ICA”.

Contrary to the defendants’ submissions, LzLabs did need, or more accurately chose, to use a mainframe in breach of the ICA licence to develop the SDM. Winsopia was incorporated by Mr Rastall but was almost immediately taken over by LzLabs and, thereafter, operated under LzLabs’ direction and control for no other purpose than to assist and facilitate development of the SDM. Although there may well have been other factors involved, such as cost and convenience, a material factor in the decision to use RSM to acquire a used mainframe was the desire to avoid scrutiny by IBM.

From the above evidence, I find that steps were taken by LzLabs, Winsopia, Mr Rastall, Mr Rockmann and Mr Moores to ensure that Winsopia was seen as an independent entity with no obvious links to LzLabs, concealing from IBM the fact that Winsopia was a wholly-owned subsidiary of LzLabs and whose sole purpose was to assist LzLabs in development of the SDM.

In respect of the second allegation, the SDM project launch took place in March 2016. On 21 September 2016, Mr Rastall of Winsopia contacted Mr Wehrli of LzLabs, proposing that Winsopia should be directly involved in discussions with potential customers to gain a rapid understanding of their needs. Mr Wehrli responded, saying that he could see the benefit of such direct communications but that he would need to discuss with this with Mr Rockmann, Mr Cresswell and the sales team. Mr Wehrli forwarded this email exchange to Lukas Do of LzLabs, asking for his feedback and stating:

“… we also don’t want to reveal the Winsopia name (as in the trade register directly as a subsidiary and IBM might therefore terminate Winsopia’s license for “Z”).”

Mr Do responded (as translated by Mr Wehrli during his evidence):

“The situation you described below is tricky. On the one hand it would be good to have an intermediate who has the required mainframe skills to communicate both with external clients and with Winsopia staff. On the other hand I see a potential large problem that we would provide IBM with large attack surface and we would lean ourselves out of the window quite heavily.”

Mr Wehrli sent a further email to Mr Rastall, stating:

“After discussions, we feel that involving Winsopia with the customer is beneficial in certain cases, and we should do that.

However we have to be aware of the following things:

- We do not want Winsopia’s name advocated out there, this is due to the IBM license agreement. We would not like to advocate the Winsopia name associated with LzLabs, because IBM could cancel the agreement for z/OS. Meaning, Winsopia Employees when talking to prospects or customers have to identify as LzLabs employees …”

Mr Rastall issued this instruction to all Winsopia employees. It is clear from the above exchanges that Winsopia employees were told to pretend that they were LzLabs employees when talking to existing or prospective customers so that IBM would not discover Winsopia’s involvement in the SDM.

In about May 2020, certain Winsopia and LzLabs employees were provided with two email addresses, @lzlabs.com and @winsopia.co.uk. On 28 May 2020 Markus Liebenberg of LzLabs sent the following instructions regarding the use of these LzLabs and Winsopia email addresses:

“Hi, here is the procedure we have to follow with regards LzLabs and Winsopia emails

1.

A block will be implemented stopping Winsopia emails from reaching LzLabs and vise versa

2.

All internal communications (e.g. Dev or Delivery) must be done using LzLabs emails. We must remain extremely careful with what we share in these internal emails

3.

All external communications (IBM and customers sharing IBM mainframe details/resources) must be done with Winsopia email

One idea I have to help minimize the switching between emails is to use a second laptop.. .there may be a few extra laptops available at the moment.”

Mr Playford responded:

“… it does put more strain on replies to emails, meaning we have to be very cognisant of to whom we are replying, and is also likely to lead to (human) lapses from time to time - which could be costly or disastrous?!”

Mr Playford was asked about this email in cross-examination:

“Q. At this point in time, is this correct, you had a suspicion that IBM UK or IBM Corp may have known about the connection between Winsopia and LzLabs, but it's not something you knew for certain?

A. That's correct.

Q. And your understanding is that it would be a disaster if IBM were to learn of that connection; is that right?

A. Possibly.

…

Q. Now, in this email, you don't spell out the reason why you think it would be a disaster, or possibly a disaster, and presumably there was no need to spell that out because you understood it would have been equally obvious to everybody else on this email chain; is that fair?

A. I suppose that's fair, yes.”

In a subsequent email dated 12 June 2020, Mr Playford stated:

“Does Duncan Love have a Winsopia email account?

The only reason I ask is that Mark Cresswell said that Duncan Love may be the person to take over IBM administrative rights (for granting access to problems, software ordering, SCRT reporting etc). And that wouldn't be possible if he only has an LzLabs email account?!

Goes again[st] the Code of Conduct and rules surrounding how we contact external agencies etc.

And IBM would certainly smell a rat! :-)”

Mr Rockmann stated in cross-examination that he approved this policy of dual email usage to separate communications with IBM about mainframe matters between Winsopia, the ICA licensee, and LzLabs, who was not an ICA licensee:

“Q. … You do not want communications with IBM taking place on LzLabs email, do you? That is the point of this, Mr Rockmann.

A. It is the point, because obviously whatever IBM sends to Winsopia is supposed to stay at Winsopia.

Q. Mr Rockmann, it is also to ensure that no communications were happening with IBM other than on a Winsopia email?

A. It is, as I described, for that purpose.”

Mr Rockmann’s suggestion that this arrangement was simply to accommodate the transfer of LzLabs UK employees to Winsopia might explain the decision to issue dual email addresses but it does not explain the policy decision to ensure that communications with IBM should only be through the Winsopia email address.

The emails are clear. From 2016, when the defendants started to market the SDM, they took steps to conceal Winsopia’s links to LzLabs and its role in developing the SDM. I acknowledge that the defendants have identified a number of customers or potential customers with whom Winsopia had direct communication without disguising its identity. However, they did not include IBM and the policy of using false identities was not revoked. The defendants submit that there was no need for, or obligation on, LzLabs to advertise the role played by Winsopia to potential customers and it would have made no commercial sense to do so. It is said that there was nothing unusual, controversial or dishonest about that; it is standard commercial behaviour. That may well be the case but it does not detract from the fact that the defendants did conceal, or not disclose, to IBM, Winsopia’s role in developing and marketing the SDM.

In respect of the third allegation, in May 2016, LzLabs and Winsopia were planning to release a public video demonstration of the DMA (subsequently re-named the CPX). The purpose of the video was to show a test application running on a mainframe, followed by migration of the application from the mainframe to the SDM. Part of the video involved a segment recorded at Winsopia showing the test application running on the Winsopia mainframe.

In an email dated 10 May 2016, Mr Tyneski of LzLabs explained that there would be no mention of the customer site (i.e. Winsopia):

“… - Mark and Thilo will approve the final script and seek legal approval of content

- The video will be shot in Farnborough by Recipe / post production will be by BLC in Zug

- No mention of the customer site - and perhaps no mention of the narrator…”

As part of this dialogue, on 11 May 2016, Mr Palmer expressed his concern that the source of the application to be used should be concealed. I note that this appears to be concerned with customer confidentiality rather than Winsopia:

“The obvious preference would be to use an existing application that has been tested on the LzAppliance and contains both CICS and DB2 objects, so is there something we can just grab? We may need to change data set names etc. to conceal the source of the application and then re-test and we will also need to confirm this with legal and LzLabs (Thilo & Mark).”

On 25 May 2016 Mr Tyneski sent an email following a conference regarding the demonstration:

“- The new application is not yet ready for testing; Winsopia will try to have this done by early next week (asap).

- Once the app is ready, Chris will run another test video to include showing the app actually running on the M/F.

- The updated video will allow us to check for time & also to ensure that the app can be unpacked on our side & actually works.

- In addition to the updated QT video, it would be useful to have an updated script that can be run past Legal for a quick review the first one went OK.

- Everyone was reminded that it is vital not to show the actual location of the demo & also to avoid the use of registered IBM Trademarks wherever possible… ”

On 26 May 2016 Adrian Hudson of Winsopia sent an email stating:

“OK, so there is nothing on the IC07/IC08 screens to indicate they came from Winsopia. The DMA ftp strips my UserlD from the front of transmitted datasets. So, are we saying that documentation should not show and names starting "WlNxx"?”

Mr Palmer responded:

“Yes because the DMA demo will show those names in the interface when we perform the migration. Please check with Thilo/legal is you have questions I am just sharing my experiences and trying to prevent last minute problems.”

Mr Hudson replied:

“OK, I will change the form and remain cognizant of this requirement.

BTW, the Winsopia company records, available on the Web, show us as a subsidiary of LzLabs.”

Mr Rastall confirmed in cross-examination that he gave the instruction to strip out from the public facing demonstration all references which could identify the involvement of Winsopia, the purpose of which was to conceal the link between LzLabs and Winsopia from the public eye. Mr Cresswell was dismissive of the notion that the “WINxxx” pre-fix was sensitive but the fact remains that those concerned agreed that it should be obscured.

The final version of the video was approved by Mr Cresswell and Mr Rockmann. It showed the LzLabs logo but did not contain any references to Winsopia.

The defendants accept that these exchanges show that some individuals at Winsopia and LzLabs were concerned about advertising the link between LzLabs and Winsopia to IBM but submit that they do not establish a policy to conceal the link or amount to concealment. Taken in isolation, the above exchanges could be interpreted as examples of over-zealous concern to preserve confidentiality of third parties and focus attention on LzLabs. However, when read in conjunction with the other concealment evidence, it is apparent that they formed part of a concerted strategy to disguise Winsopia’s involvement with the SDM from IBM.

In respect of the fourth allegation, consistent with the desire to hide from IBM Winsopia’s connection with, and work for, LzLabs, during the project, Winsopia avoided contacting IBM for technical support through problem management records (“PMRs”).

For example, in his emails dated 6 and 7 September 2018 to Mr Taylor and others, in response to a suggestion by Douglas (“Dougie”) Lawson of Winsopia that an IMS DB function failure should be the subject of a PMR, Mr Rastall stated:

“…Raising a PMR with IBM (if and when we are ready) will require discussion and agreement with Thilo and Legal it is not something we have done previously.

… if we consider the function is not working as documented by IBM I need to decide if you recommend raising a PMR with IBM, if you do I will need further discussion with legal and Thilo about opening pandoras box to IBM who could request information we may not want to disclose.”

Likewise, in an email dated 16 April 2020, Alan Playford stated that he wanted to exhaust all possible avenues before reporting a possible bug to IBM. On 17 April 2020 Mr Bleach suggested opening an APAR to which Mr Playford replied:

“Will certainly do if absolutely necessary?

But that's why I'm almost begging Dougie to run our tests on a different Customer machine that he might have access to, just to see where the actual problem is?

Once I know we can't possibly attribute it to ourselves, then I'll certainly raise a PMR!”