IBM versus LzLabs

The IBM UK court case against Swiss-based LzLabs and UK-based Winsopia highlights a number of important issues. Firstly, it seems natural justice that if your company has spent money developing some technology that you should have every right to copyright it and prevent other people from using your original work without paying for it. Secondly, you should be able to choose who you licence your technology to, and they should be expected to pay for that licence. That is basically IBM UK’s case. It is saying that LzLabs has taken their tech and is using it as if it were their own. They want LzLabs to cease and desist.

LzLabs has a different view. It is saying that it has found a way to emulate a mainframe and do it in software. It is a completely different thing, and IBM, being a large organization, is using its size and weight (metaphorically) to prevent LzLabs from lawfully conducting its business.

At its heart, that’s what this court case is all about.

What exactly has LzLabs done? Their product allows customers to migrate off IBM mainframes and onto other hardware platforms without making changes to the software they are running. Obviously, if enough customers do that, it’s going to affect IBM’s revenue stream going into the future. But that’s not what this court case is about. What IBM is asserting is that it is “inconceivable” that LzLabs, and its UK subsidiary Winsopia, could have developed their migration software without illegally reverse engineering IBM’s technology.

By focusing on that aspect, IBM can make it seem they are not being bully boys and trying to prevent a potential competitor. They are, quite rightly, protecting their copyrighted material, which they have created, at great expense, over a number of years. And, put that way, it seems right and proper that IBM should sue.

Of course, LzLabs is saying that its tools were developed lawfully in keeping with the EU Software Directive and UK law, which encourages innovation by competitors. So, they have done nothing wrong.

We all know about IBM, its mainframes, its cloud, its work on AI, and its business in general. LzLabs, you may recall, launched the Software Defined Mainframe (SDM) in 2016, which, as mentioned earlier, provides a way for mainframe applications to run on other platforms, eg Linux.

IBM wants LzLabs to stop selling its product, which IBM claims is using IBM’s own software.

You might be wondering where the UK company Winsopia comes into all this. Well, IBM claims that Winsopia leased an IBM mainframe (that bit is not disputed), but it then breached its licence, and it was that breach which allowed LzLabs to develop SDM. What was the breach? Basically, it reverse-engineered and reverse compiled the mainframe software. That allowed LzLabs to understand the design and structure of the mainframe software, and allowed them to recreate it. That was prohibited by the contract between IBM and Winsopia. In fact, IBM is suggesting that Winsopia is a shell company whose sole purpose is to act as a front for LzLabs and gain access to IBM equipment and software.

LzLabs and Winsopia, not surprisingly, insist that the contract wasn’t breached and that they were able to build SDM because they had spent years observing, studying, and testing how customer applications interact with mainframes. LzLabs claims that it has a team of experienced engineers, and they used information published by IBM about its technology. Plus, there’s widespread industry knowledge about mainframes. In addition, LzLabs states that it could never directly access Winsopia’s mainframe.

The defence team also affirmed that SDM was functionally completed in 2013, which predates the creation of Winsopia.

Let’s turn our attention to a product from ColeSoft – its source-level assembler debugger, z/XDC, which first became available in 1980. IBM’s expert witness, Michael Swanson, has been in court proposing that LzLabs’ use of z/XDC was “invasive”, suggesting that LzLabs had used the debugger to disassemble IBM’s modules.

The LzLabs defence team, however, suggested that Swanson appeared “to have no real-world mainframe knowledge” since 1999. The lawyers showed that z/XDC is widely used by “big players” in the mainframe arena “for the purpose of developing commercial software”. Swanson agreed that using z/XDC for testing and debugging was not an “unusual or uncommon” use of the tool.

The court case continues.

LzLabs is owned by John Moore, and this is not the first time one of his companies has faced IBM in the courtroom. Moore founded NEON Enterprise Software (in 1995), which developed a product called zPrime.

As you know, IBM charges users by the amount of General Purpose Processor (GPP) they use, while also making specialty processors available for things like Linux and Db2. Now, doing your processing in a specialty processor saves money because you’re not using the chargeable GPPs – and, in real life, it can save money by putting off the need for an expensive upgrade. zPrime allowed users to run an estimated 50% of their workloads on specialty processors – that’s not just Db2, that was IMS, CICS, TSO/ISPF, batch, whatever. IBM sued NEON in 2009, and it was settled in May 2011. NEON Enterprise Software lost and disappeared.

It will be interesting to see how the LzLabs case goes over the next few weeks.

 

 

Making good decisions

Picture the scene: you’re sitting in the boardroom representing the mainframe team, and sitting with you are the new cloud team, and the established distributed team, and there’s also some people from finance, and even a couple of users. The meeting starts, chaired by the CEO, who wants to get involved in such an important decision for the organization. Maybe you’re deciding on the best platform for some new application that’s going to be used. Perhaps you’re making choices for what should be included in next year’s budget and where it should be spent. Or maybe your company wants to introduce artificial intelligence (AI) in all its customer-facing applications. Or, it might be some other big project.

I would guess, with very few exceptions, you’ll be championing the mainframe as the best platform to use. However, the other IT people will be championing their platforms equally enthusiastically. How does the CEO make a choice with the conflicting expert advice he’s getting and with his own biases?

Let’s look at cognitive biases first. These are biases people have (like thinking vaccinations are bad for you, or a political party is always bad, or mainframes are always best) leading them to draw erroneous conclusions. Your CEO can overcome his own biases by getting information from a variety of sources.

The CEO’s decision-making process means that they need to weigh up the various options and determine the best course of action. That means the mainframe guy (you) needs to come to the meeting with more than your gut feeling about what’s right and your natural biases. You need to bring some real-life examples. You need to be able to demonstrate where other mainframe sites have successfully implemented whatever is under discussion – or, at least, something similar. If no-one else has done something very similar, it might be possible to break down the task under discussion into smaller component parts and illustrate where they have been successfully used on a mainframe, and where they have been unsuccessfully used on any other platform.

The next stage for the CEO is to analyse the arguments that are being put forward by the different groups at the meeting. He needs to interpret what has been proposed, and then draw conclusions based on the information in front of him. He needs to judge the information’s merit, accuracy, and appropriateness. He needs to check that the information is from a reliable source – just on being the Internet may not always make it reliable. The CEO needs to identify any assumptions made by the people putting forward different proposals (such as “the cost of cloud computing is likely to remain low over the next three years”), and also identify any biases in individual’s arguments. This can be done by him actively questioning proposals or arguments being made.

For many big decisions, there is plenty of data available from different sources that can be checked for reliability (accuracy) and then analysed. The information drawn from this needs to be valid, relevant, and significant. This information can be used to support the claims or assertions of the different groups at a meeting.

Lastly, the CEO needs to summarize the arguments that have been put forward, ensuring that he has understood them completely. We all know companies that have moved applications off their mainframe hardware because the cost of software is much cheaper on distributed systems. It’s only later that they find they not only need to spend more on hardware to run their new software, they also need more people to run the additional hardware. In the end, their off-mainframe budget can be higher than staying on the mainframe. It’s looking at all aspects of a potential solution that’s important at this stage. The evidence put forward needs to be from credible sources and needs to be complete.

The mainframer at the meeting needs to be a good communicator in order to put forward well-reasoned arguments for their particular point of view, and argue against other opinions.

The CEO, in moving to a final decision, needs to weigh the competing evidence. Some evidence will corroborate or support a proposal. Some, from multiple sources, will be convergent and support the same conclusion. Some will be contradictory, and some may be conflicting. The CEO needs to keep in mind the issue that this meeting is trying to address, the desired outcome of the solution proposed. He needs to look at the outcome of the different proposals in computing terms, in terms of cost and profit, in terms of its impact on staffing numbers and morale, in terms of the reputation of the company, and many other aspects. Each proposed solution can then be evaluated against these and any other relevant criteria. A positives and negatives table could be drawn up to do this. Usually, different criteria are weighted differently. At the end, a final solution can be settled on, and a rational decision can be made.

The next stage is the impact analysis and communication with people affected. If the impact involves people losing their jobs, then plans need to be put in place to offer retraining for newly-created jobs in the organization or for filling other vacancies. Otherwise, staff must be helped to deal with redundancy and get work elsewhere.

If only customers are going to be affected, then advertising and social media can be used to explain how much better things will be. If employees will be impacted, it’s important to ensure that carefully-crafted messages are sent out explaining exactly what changes are taking place, and how that will benefit the people who will benefit, and how those impacted by the change will be helped into new roles.

This discussion uses ideas taken from critical thinking. This is a technique that can be used to find the best solution to a problem and then implement it successfully. It’s designed to identify alternative ideas and test them out. It should help overcome cognitive biases. And it should help to analyse data. The last stage would be self-reflection, where a person can review how well each stage was handled, what personal thoughts and experiences occurred, and what personal lessons were learned.

Using these ideas can help any mainframer prepare for those important meetings that may be coming up.