Red Hat is going long on enterprise Linux. The IBM business unit says it created a new support offering for its flagship Enterprise Linux, “RHEL forever,” with “no pre-determined end date.” The offer is formally named “The Long-Life Add-On,” and it is designed to “keep older minor or major versions of RHEL secure and stable” by providing critical patches, urgent bug fixes, and 24x7 tech support for as long as customers keep paying for it.

That wording matters, because it reframes a very normal IT timeline problem into something closer to contract and governance. Red Hat’s argument is that platform migrations often get forced when OS support expires, sometimes long before an application becomes truly obsolete. In other words, you end up upgrading software on a schedule dictated by the operating system lifecycle, not by the state of your business. Red Hat says longer support gives IT leaders “the freedom to synchronize software lifecycles with long-term hardware investments or complex regulatory timelines rather than forced upgrade schedules.”

If you are a CIO, CTO, or CFO, you can already see the two sides of the same coin. On the one hand, security and stability are not optional, and “older minor or major versions” can be deeply embedded in real systems. Some environments are change-averse by nature. Red Hat’s own positioning echoes a real, extreme example from 2013 that The Register reported: GE’s Canadian outpost seeking staff to keep PDP-11 code working until 2050 because it helps to run a nuclear power plant. In situations like that, the cost of disruption and the compliance burden of change can dwarf the cost of keeping code running.

On the other hand, support that is “for as long as customers keep paying” is also a lock-in machine, even if everyone involved insists they will behave responsibly for decades. The Register points out that anyone signing up for long-duration services will find it “almost impossible to avoid lock-in and therefore expose themselves to increasing costs.” That is not a theoretical concern. In the late 1990s, the correspondent did marketing work for Wang as it spluttered toward irrelevance, and after the channel evaporated, Wang became the sole source of professional services for customers’ machines and code that had not been replaced. The Register reports that Wang quickly hiked support prices, including a “four-figure call-out fee” just to show up and investigate a customer problem. It also says this was referred to as a “golden screwdriver,” because only Wang staff could touch one of the company’s boxes without invalidating warranties.

Red Hat, naturally, will argue that it will not behave that badly when customers extend a contract into a third or fourth decade of RHEL support. The source is careful here: it says whether future sales reps and account managers live that promise is unknowable. The strategic tension is still real. When your operations depend on a specific OS version plus vendor-backed patching and support, your switching costs do not just grow because migration is hard. They grow because you need to keep systems secure while doing the migration work, and because regulatory approvals often do not move on your preferred schedule.

It is also worth anchoring this “forever” offer against what Red Hat already sells. The company already offers a support package called “Extended Life Cycle, Premium” that delivers updates to major RHEL releases for 14 years, or six years of extended maintenance for specific minor releases. So this new “Long-Life Add-On” is not a completely new concept. It is an extension of the same product philosophy, but with a key change in posture: instead of a fixed number of years, Red Hat is leaning on indefinite support “as long as customers keep paying for it,” and it explicitly says there is “no pre-determined end date.”

For boards and executives, the second-order implication is budgeting and risk, not just security. A fixed horizon gives you planning anchors: you can forecast end-of-support-driven migration and align procurement cycles. An indefinite horizon pushes you into ongoing cost governance. Even if the patch cadence is steady and the support is excellent, you still need a framework for vendor concentration. You need to know what happens if your organization outgrows the original RHEL version, if internal teams cannot migrate as fast as expected, or if regulatory timelines shift.

This is why “RHEL forever” is interesting beyond the Linux nerdosphere. It is a signal that enterprise customers are willing to pay to decouple business change from OS end-of-life pressure. But it also raises a classic question: when does “security and stability” become “permanent dependency,” and how do you ensure the dependency stays priced and governed like a service, not like a toll road?

Executives in similar roles should treat the announcement as both an opportunity and a checklist item. Red Hat is explicitly offering longer runway to synchronize software lifecycles with hardware and regulatory realities. The strategic stake is whether your organization can capture that flexibility without surrendering control over costs, timelines, and leverage when the contract stretches beyond the normal planning cycle.