A lot of it is Java 8 only. Companies (banks) that have codebases where they're in maintenance mode and they don't want to pay devs to upgrade to the latest Jav

A lot of it is Java 8 only. Companies (banks) that have codebases where they're in maintenance mode and they don't want to pay devs to upgrade to the latest Java due to all the backwards compatibility breaks that were in Java 9-11, so it's cheaper to just pay Oracle to continue maintaining Java 8. Otherwise it's the same as Red Hat. Why pay RH for RHEL when you could just install a free distro? Same considerations apply. If you've made it to Java 11 or 17 then yes there's no deep reason to pay Oracle unless you feel your business is sufficiently dependent on Java that you want the original developers to work on your specific bugs or problems, even long after that release is no longer supported by the upstream open source project. For example if you have a server that suddenly hits some weird performance bottleneck in Hotspot or the std libs then they will actually dig in and figure that out with you, and then spend time optimizing it to fix that. They've made reference to such efforts before. Obviously that is expensive, so they charge for it. Why this change - the focus in the article is price increase for a hypothetical example company but it doesn't take into account the cost of compliance under the old regime which is all about counting processors and/or end user machines. Basically trying to measure your usage. But that was super complex. Different types of processors counted differently, virtualized CPUs counted differently and so on. Audit and compliance was too hard. Number of employees is super easy to count and check so audit/compliance costs evaporate. That may on its own be enough to counterbalance the effect of increased prices in some cases.