Broadcom pressures VMware customers with cease-and-desist letters over perpetual licenses

[Alfonso Maruccia]

Editor's take: After acquiring VMware in 2023, Broadcom has wasted no time reshaping the company into a profit-focused operation, often at the expense of good customer relations. The latest move in this contentious strategy involves cease-and-desist letters sent to VMware users, warning that they won't receive new patches or bug fixes unless they continue paying for official support.

Broadcom wants to push every single VMware customer "owning" a perpetual license to a new subscription-based contract, and is willing to antagonize the entire VMware userbase to reach this goal. Companies and professionals still using VMware products have recently started receiving a new kind of cease-and-desist letter, with Broadcom asking for new support contracts or even threatening an active "inquiry" into users' systems.

The letters are seemingly targeting VMware customers that acquired a perpetual license before Broadcom digested the virtualization giant. Some organizations are threatened because they chose not to convert the previous license to a subscription, as they are likely looking for alternative solutions or don't want to give in to Broadcom unreasonable requests.

The wording used by Broadcom in its letters focuses on official support services, which are no longer available if a software product was previously purchased with a perpetual license. Therefore, Broadcom "demands" that such customers stop installing new updates to VMware products, including maintenance releases, minor releases, patches, or security fixes. The only exception is about zero-day vulnerabilities for vSphere 7.x and 8.x, Broadcom said, and only when the flaws have a CVSS score greater than or equal to 9.0.

Broadcom now treats patches and bug fixes as part of its official support services, effectively forcing companies to pay for the right to install updates. According to the company, applying a patch without an active subscription violates VMware's software license and infringes on its intellectual property – grounds Broadcom appears willing to pursue in court.

Broadcom has escalated the situation by claiming the right to audit customers, aiming to catch anyone installing official patches on perpetually licensed software without an active support contract. Critics have dubbed these cease-and-desist letters "nastygrams," all signed by Mike Brown, who serves as Broadcom's Managing Director.

Dean Colpitts, CTO of Canadian service provider Members IT Group, told Ars Technica some customers received Broadcom's letter shortly after their support contracts expired. While a few organizations pushed back with legal teams, the tactic has spread confusion within online communities about Broadcom's motives.

Broadcom has repeatedly shown a willingness to force a subscription model on most VMware users. The company has imposed steep price hikes and taken legal action against major ICT firms refusing to pay for new support licenses.

Permalink to story:

Broadcom pressures VMware customers with cease-and-desist letters over perpetual licenses

 

[brucek]

So what did the terms accompanying the purchase of the perpetual license say?

Anyway while that may be an interesting short term question to affected enterprises, it feels moot in the long term as I can't imagine this company retaining many clients into the next decade. Most companies do not care for vendors which renege on previous terms, escalate pricing sharply with no apparent justification, threaten to sue, etc etc etc even if their product or service is otherwise superior.

 

[NumberNine]

Don't worry Broadcom, many of your customers are preparing to do exactly that.

 

[VariableSpike]

Broadcom, experts in milking out every last penny from a company and then leaving its corpse to rot, so not a single surprise here that despite the prospect of antagonising yet more people to move away from vmware, their execs have decided that short boosts in profit are all worth it (well, golden parachute and all that for the a**holes in charge I guess)

 

[unoficialoficial]

Those companies are quite large, with hundreds of employees each one. Surely they could collaborate, form a consortium and hire around 100 programmers somewhere in Asia to develop and maintain an open-source alternative. Virtualization software isn’t as complex as it seems – it’s likely only 1-2 million lines of code and for sure less than 10 million lines of code. They can do it with a very small fraction of the cost they pay now.

 

[Theinsanegamer]

Those companies are quite large, with hundreds of employees each one. Surely they could collaborate, form a consortium and hire around 100 programmers somewhere in Asia to develop and maintain an open-source alternative. Virtualization software isn’t as complex as it seems – it’s likely only 1-2 million lines of code and for sure less than 10 million lines of code. They can do it with a very small fraction of the cost they pay now.

And then who takes responsibility if the code shats the bed and every client ends up with massive data breaches or data loss?

So what did the terms accompanying the purchase of the perpetual license say?

Anyway while that may be an interesting short term question to affected enterprises, it feels moot in the long term as I can't imagine this company retaining many clients into the next decade. Most companies do not care for vendors which renege on previous terms, escalate pricing sharply with no apparent justification, threaten to sue, etc etc etc even if their product or service is otherwise superior.

Agree, I dont see VMware being very relevant by 2030....

 

[unoficialoficial]

And then who takes responsibility if the code shats the bed and every client ends up with massive data breaches or data loss?

That's a good question. If they build it from the ground up, choosing Rust would be a significant advantage. This single decision would eliminate entire classes of bugs – specifically, memory safety vulnerabilities – that currently form a large part of the attack surface in C/C++ virtualization code. Even the small number of "unsafe" blocks needed for low-level hardware access would be easier to manage; they can easily focus their documentation and code review efforts on those critical areas, knowing that the vast majority of the code benefits from the compiler's fundamental memory safety checks.

 

[bviktor]

They’re doing everything in their power to absolutely demolish any and all remaining trust their clients still have in them, aren’t they?

It’s okay tho, everyone I know is planning to switch to other solutions ASAP. Way to go, above and beyond.