Oracle's revised Java licensing terms 2-5x more expensive for most orgs Most organizations adapting to Oracle's new licensing terms for Java expect the per-employee subscription model to be two to five times more expensive than the legacy model, according to Gartner estimates. Speaking to clients since the new model was introduced in January, the global technology analyst said the steep increase …
It begins to make the likes of Altium's per-user licensing look cheap. Licensing on every employee of a company, whether they use the product or not, is unconscionable.
But I suspect I'd be starting a crash course of converting to one of the FOSS versions (or possibly mix and matching versions around wherever possible to give the auditors a headache!).
Or just decontaminating completely as we have done.
Amen.
It baffles me why anyone uses Java in new projects and why existing ones aren't switching to Python, Ruby or JavaScript/ECMAscript or, well, practically anything else.
I've got nothing against the language syntax itself - in fact it's quite nice. But the compute requirements for things like Jenkins or JBoss or whatever are bananas.
Python, Ruby, and JS have extremely poor performance for some kinds of tasks. Java is a middle ground where you can code it like a high level language for simplicity or code it like a low level language for performance, plus anything in between. Its frameworks have always attempted to make optimization easy. There are some rough spots but Java is my favorite language for large apps.
The simple solution is to not use the Oracle Java. I haven't touched Oracle Java since version 8, which is obsolete by several major language improvements.
Why then do Java-based back-ends for continuous integration, bug tracking, collaboration etc. always seem to require five times the resources than ones using PHP, Perl, Python or Ruby for the same type of service?
Maybe Java programmers just aren't very good?
Because Java's virtual machine is geared towards delivering high throughput, using more memory and adding a warm up time lag to collect metrics on hot code paths to optimise the machine code. The other languages you mentioned can't match Java's performance for a complex high traffic application. Either way, Java can be tuned to use less memory on CI servers and the guidance on this is widely available.
"Spring Boot"
A utility from long ago that grew like the Blob into a Java operating system. With just a few magical annotations, you can generate hidden runtime delegation classes to provide dynamic configuration and feature injection. It extends app launch times from 300ms to 40000ms, obliterates JVM optimizations, adds GB of memory consumption, and is impossible to maintain but some swear by it.
Help me out here. The applications I develop are, at a personal project level CAD software, operating systems and compilers. On a professional level, I code storage systems, physics simulations for things like bio computing and weather prediction.
I do actually have a storage system in production which provides object storage to CERN projects which is based on Java. Its system requirements are idiotic and if we could rewrite it in any language actually suitable for such tasks, it would save us tens of millions of dollars.
For business and accounting type systems, I code everything in C# because the language is insanely well maintained at this time.
What is a suitable application for Java? It always struck me as the square peg in the round hole. I used to develop a Java Virtual Machine and a clean room implementation of the Java libraries, and I suppose it was a fun project, and I needed to do it because I needed a platform independent JVM for embedding in a web browser on all kinds of platforms. But when DOM and HTML canvas became a thing, I didn’t really see the point anymore.
So what kind of software would you develop using Java and is that because of habit (shamefully, I still use C and C++ for some things because they’re comfortable even if they’re terrible), or does Java offer something which makes it well suited for some task?
Java (and the JVM) remain popular because of the huge ecosystem around it. I like C# as a language (it's benefited from avoiding most of Java's mistakes), but there is nothing in the dotnet ecosystem that compares with Spring Boot and the Spring framework for productivity. And the JVM offers good performance - not as good as languages like C, C++ or Go, but far better than Python, Javascript or Ruby.
But I would obviously echo the advice to stay as far away from Oracle as possible and stick with a 3rd party or OpenJDK distribution.
Yes, because they do garbage collection.
Feeble gag aside, reading this horror story, I couldn't help repeating to myself "I'm so glad I went back to C++ and tried the modern version" over and over in my head. For me, it was the continuous changes that cased this, but the signs that the extortion racket was about to kick off big time were also there a long time ago now.
You could probably justify it in that those cleaners could be using some kind of HR system (holiday planner, timesheets, shift scheduling etc) which uses Java, but overall, the inclusion of all staff & contractors feels like gouging. Because it is.
Many companies will have a few Java apps used by a small portion of their workforce and licensing all employees doesn't make any sense. The licensing forces you to go all in or try to find a way out of it. I assume Oracle are hoping people will go "all in" at which point they may well decide to deploy Java in more places because they're already paying for it. That makes it harder to get out of using it longer term providing some convenient (for Oracle) lock in. The right thing to do is to run, not walk, away from Oracle Java as quickly as possible.
Gartner might know licensing but it doesn't look like they know much about Java.
> If they moved applications to Java 17, they could avoid the change, but it would involve significant work and, for many, would not be viable.
Which Java 17? Oracle Java 17? That won't avoid the licensing requirements.
> Similarly, the option to upgrade all Java applications to the latest release of OpenJDK is most likely off limits, owing to the work involved.
Er, what?
> In the viable-but-hard-work category come the options of switching to third-party Java products
How is "moving to a third-party Java product" easy but "moving to the latest release of OpenJDK" hard? This is nonsense
Switching to Azul or any of the other listed "third part Java product" is, if anything, more complicated than switching to OpenJDK, which involves no licensing checks. And switching to OpenJDK doesn't mean also upgrading to Java 17 - OpenJDK 8 and OpenJDK 11 are available for download. I'm actually starting to view Oracle's change as a good thing - if it can wean some of our, er, more conservative customers off Java 5 through 7 and onto OpenJDK 8.
I've been doing this for my clients - Java is standards based, different vendors releases are based on the same standards, and in most cases based on OpenJDK so also based on the same codebase. Specifically for your comment on azul - Azul offer two JDKs, Prime uses proprietary technology but is still fairly easy to migrate to. Platform core is based on OpenJDK so is the same codebase. If your on java 8 then moving to the azul or amazon release of Java 8 is generally painless, but moving to a newer version is much more painful.
It's trendy to throw shade at Gartner but in this case their research seems more sod than yours.
Agree. There seems to be some confusion in the Article and/or Gartner advice.
To keep it simple: If you actively develop, check if you really need the extra goodies Oracle JDK provides. If not, move to a newer OpenJDK 11 or 17, whichever reflects more closely to your current OracleJDK release. Required changes are probably minimal or non-existent, as Java enforces strict compatibility between runtimes.
If you are not actively developing and are still on an old JDK release from before 2019, stay there as long as you can as they stay "free" as in beer.
For much internal or even active Internet code, this will not pose a real security problem. An old, unmaintained application is usually a bigger security risk than the old JDK running it, anyway.
Third party Java runtimes typically make sense only if you need their special capabilities.
I remember back in 2003 ...I seem to remember there was one we used because it was faster than the official one
Oracle won the copyright case in court, and MS withdrew both the Java product and Windows 2K (because Win2K had the MS Java product embedded).
The competition did have the salutary effect of causing Oracle to put more effort into Java development to keep up, and Oracle Java also became a lot faster.
I'm going to follow myself up with a point I should have made yesterday, just for posterity.
It's tempting to think that continuing to run an old JVM means things will just continue to work, but that's not the case for any app that talks to the outside world. We've had customers asking for help because their Java 5 installation, untouched for years, has suddenly stopped working: it was connecting to a URL, the SSL certificate had been upgraded and now used a cipher that didn't exist when Java 5 was around.
Unless you're running your application a vacuum, there is a cost to sitting still on an old JVM for many applications, just as there will be a cost to migrating to a new JVM, just as there will be a cost for performing Oracle's audit.
"> In the viable-but-hard-work category come the options of switching to third-party Java products
How is "moving to a third-party Java product" easy but "moving to the latest release of OpenJDK" hard? This is nonsense"
Viable-but-hard-to-work does not mean easy....
Any of the options are difficult, expensive, or both. Migrating to a different (and newer) release (open, 3rd party, or Oracle) is not going to be super easy (I guess).
Only code that uses APIs that have been dropped is complicated to move. Complicated in a corporate sense, I urge to add: release and change management, specifically. I've updated a few code bases over the years, changes required have been minimal. Changes prompted by IDEs and static code analysis tools, plentiful - but those are suggestions. Often good ones, yes, but not necessary. Avoiding a 3 million bill, on the other hand...
I see you are shooting yourself in the foot big time over this.
Like you DB licensing it is a mess that not even you own people can't understand. How can you expect customers to do likewise? You can't so say goodbye to an awful lot of revenue. It is your own stupid fault.
Die Oracle Die. (from a former Oracle DBA)
Soon after the Raspberry Pi launched Oracle were making a big thing of Java being 'free for use on a Pi' so, having decided to consider it as a possibility, I tried to find out exactly what that meant, what the licensing terms were, what was actually free and what wasn't, how much choosing Oracle Java would cost me.
That was a Fucking Nightmare (TM) and even the guy pushing Java for use on the Pi was never clearer than mud.
It left me feeling like I was being talked into being scammed or set-up in some way so I quickly concluded I would never use Oracle Java nor have anything to do with Oracle, ever. Fuck 'em.
Nothing Oracle has done since has convinced me I was wrong in that decision.
Having read the new Ts&Cs at the link referenced above, I suggest one small update to completely clarify the whole thing, and more accurately describe the likely (As opposed to the published) behaviour:-
Q:Where do I send feedback and/or questions for the Java SE Universal Subscription?
A:If you are a customer, use My Oracle Support. If you are not a customer and have technical feedback related to Java SE, please visit https://java.com/report. For all other inquiries related to sales, support, product and/or licensing, please contact us at https://www.oracle.com/corporate/contact/global.html https://www.oracle.com/dev/null or https://www.oracle.com/endless-que/ainuo *
|
|
|
Q:What if I’m an ISV, or embed Java in hardware for redistribution, and want to include Java SE in my products?
A:Please consult your local funny-farm, who will assist you with the lobotomy you so obviously require.
FTFY.
* Should be FIFO, but more likely Anything In, Nothing Useful Out.
Exactly this. Years ago, Oracle tried stitching my company up with a £3.5M bill for using a small Oracle database, claiming that everyone who saw, or who could poentially have seen, a printed report from the database was in fact a user, and hence had to be licensed.
After a protacted set of increasingty fractioius arguements we did a corporate transition to DB2. Oracle were told to leave the building.
Sucks to be you, eh Oracle?
Even on old platforms, you can find OpenJDK builds:
https://github.com/alexkasko/openjdk-unofficial-builds#openjdk-unofficial-installers-for-windows-linux-and-mac-os-x
https://github.com/ojdkbuild/ojdkbuild
https://adoptopenjdk.net/releases.html
https://developer.ibm.com/languages/java/semeru-runtimes/downloads/
https://adoptium.net/temurin/releases/
Cut out the Oracle stuff out before the infection takes over.
OpenJDK can be had for £0, so it's well worth an experiment. Anything it costs to alter existing software to run on it (and it probably won't even need any alteration, because Java) will be a one-time payment, as opposed to an ongoing cost of paying for an unnecessary licence.
Meanwhile, at least some developers are going to be pivoting hard towards OpenJDK, because they won't want to pay avoidable licence fees either.
Charging money for software is a business model whose time has been and gone.
Will third-party Java runtimes get around this issue? I thought the Oracle license claimed full ownership of Java in all forms and you owed the license even if it wasn't their runtime being used. This ended up in court with Google's Android API but I don't think that settled the issue if the company signed the small print contract with Oracle.
I have been working with a little more than a dozen customers on conducting Java license reviews - customers from 10k employees to 200k employees
Some interesting feedback from these reviews:
1. Oracle is still not clear - or does not want to give clarity - about what is 'free' and what is 'not free'.
2. Usage of Java in desktops is much less than presumed by both customer & Oracle.
3. On Servers - Java usage can be controlled.
4. Oracle has been pushing for deals since 12 -24 months, but most customers have not yet succumbed to making a purchase.
5. The value of the revenue desired by Oracle has shot up with the introduction of the new license metric - the ask has gone up by 2 - 5 times (of the initial ask on older Proc/NUP metrics).
6. There are ways to remediate and rebalance. Customers need to be ready to spend some effort to do this, but the return on the efforts will be very high.
7. Most software vendors / ISVs have begun the process of certifying their applications on non-Oracle Java (either OpenJDK or on builds by third-parties like Azul, Bellsoft, IBM etc)
8. This is short term money for Oracle - but it could be very large amounts of revenue in the next 3-4 years.
(disclosure: I am an independent license consultant)
> 7. Most software vendors / ISVs have begun the process of certifying their applications on non-Oracle Java (either OpenJDK or on builds by third-parties like Azul, Bellsoft, IBM etc)
Funny how IBM can do this to Oracle but they can't see it being done to themselves.
Nobody picks RedHat (or Oracle) for their technical merits.
Three years ago, we found the amazing phrase: "[...] on March 2, 2015, the AArch64 port was part of the main OpenJDK project. Oracle was great and helped and encouraged us through the tricky integration process." (https://developers.redhat.com/blog/2021/02/01/how-red-hat-ported-openjdk-to-64-bit-arm-a-community-history)
What's Oracle's endgame here? It's clearly having the effect of moving people onto Open Source or newer supported versions of Java. So people faced with a bill are using stuff which Oracle dont really want you to use and hence charge support? It's a bit like paying for Windows 7 extended support.
Clearly they can't compete and make money with the free Open Source builds, so are they just trying to clear out the Java legacy mess and raking in $$$ in the meantime?? Or is there some other more Oracle like scheme afoot.
The calculation is worse, than the factor 2x-5x indicates.
The previous Named User Plus metric counts desktop users, that have Java installed on their desktops and costs about $2.50 per NUP per month
Additonally $25 per 2 Intel cores per month were billed.
The new model counts employees regardless, if the use Oracle Java or not. $15 per month per employee are billed. This alone is at 6x more expensive than before.
Think about a situation, where a customer wants to implement a new application based on Java for just a smaller department with 20 user.
If there was no Java Subscription around previously, you'll have to pay for all employees regardless if they do the cleaning, white collar, or even the IT guys that do not use Java are counted.
A hospital with 1.000 employees but 20 Java users had to pay $50 p. month according to the deprecated NUPs model.
Now they have to pay $15.000 which is an increase by 300x.
Oracle would give more discounts with the new model, but 99.7% discount will certainly not be offered.
Unfortunately, some will have no choice. Legacy systems built on older versions of Java, where short term redevelopment costs (even if feasible) significantly outstrip the licence. No one starting something new uses Oracle Java. Unless thinking impaired. Oracle knows this and knows who must pay the fees.
We migrated away from Sybase to Postgres for the same reason. Plenty of money in that, still, in banking, so Sybase can charge accordingly. Same with Oracle Java. Glad we evolved towards Openjdk over time.
From the "Definitions" section of Oracle's price list...
"Employee for Java SE Universal Subscription: is defined as (i) all of Your full-time, part-time, temporary employees, and (ii) all of the full-time employees, part-time employees and temporary employees ofYour agents, contractors, outsourcers, and consultants that support Your internal business operations. The quantity of the licenses required is determined by the number of Employees and not just the actualnumber of employees that use the Programs."
erm...
Charging license fees for people in an organisation who will never even touch a computer sounds a little bit illegal to me, but IANAL.
Wow, that can escalate quickly. If that means what I read it to mean, by adding outsourcers...
So if I outsource my telephone call handling to a third party call centre, I have to pay a fee for every single employee of that call centre, not just the ones handling my phone calls?
It's highly ambiguous. The last bit of the sentence reads "that support your internal business operations" - how do you define that. Dropping the list of employment types, the line reads all of the full-time employees, part-time employees and temporary employees that support Your internal business operations.
So is that all staff of the companies that support your internal operations, or just those third party employees directly involved in supporting your internal business operations?
$3000 000 for a 45 000 employee-company is $66 per employee. How much is the average labour cost of an employee per year ? Surely 100x to 5000x more, wherever it matters. North Korea and Nigeria does not count.
Also, compared to a tool machine worker, $66 is a pittance. He stands in front of a $500 000 CNC tool machine, which is depreciated over 10 years.
We computer folks should really get a grip on economics.
The SUN freetard model has destroyed this company. It also destroyed BORLAND, who had a Pascal/Delphi business before the freetard Java model came along. Great job, SUN, you destroyed Borland and yourself by your stupid idealism.
Oracle provides tens of thousands of nicely paid, health insured jobs for software engineers. Where do we expect the money for that to come from ???
What are you talking about ?
Its amazing how you name call suns honorable aspirations and then you think Oracles greed and arsehole tactics are something to be proud of because they provide healthcare. Well guess what basically every free country in the western world has free healthcare for everyone without being a total areshole.
Cincom is the main developer-provider of serious Smalltalk IDEs and VMs. They demand $500 per dev per year and 6% of your product revenue.
Other pricing models of their products are in the $5000 to $10000 range one-time per developer.
https://comp.lang.smalltalk.narkive.com/jgCbTiWI/is-cincom-smalltalk-prohibitively-expensive-for-a-single-developer
So, Java is not expensive at all, compared to Smalltalk and DELPHI from Embarcadero. Depending on the situation, of course. A few ST devs in a large corporation *might* come cheaper than Java.
CINCOM does not clearly say how much they want for internally developed apps. The want to "discuss" this with you. And apparently they also use number of users or number of employees to calculate license fees for company-internal applications.
I would not be surprised to learn that they are more expensive than Oracle is.
(No, I am not financially related to Oracle !)
For starters every one of those languages you picked is basically single threaded.
Secondly those languages are alsoa horror if one wants to refactor the code, because code without types is significantly harder to modify with confidence and impossible to refactor, and yes theres zero tools that support real refactoring of any of those languages, search and replae doesnt count.
Now you know why the big boys like Amazon, Ebay, Google dont use them except for the most basica tasks.
When price is not determined mainly by supply and demand, providers of a product have much greater leeway for setting their charges. Digitally expressed products, not just computer software, are not capable of full compliance with conventional market-economic discipline.
Incompatibility arises from lack of physical scarcity and consequential inability for 'price discovery'.
Copyright and patent 'protected' digital products (physical too, but a differing argument applies) cannot be shoehorned into market-economics other than by sleight of hand legislation conferring monopoly. The 'fit' is a pretence of digital sequences sharing properties of physical goods; a pretence by mutual consent of nations; one that is as vulnerable as a 'naked emperor'. When global 'multipolarity' sets in (e.g. a powerful BRICS) there will be incentive to question why so much of the disposable incomes of nations, enterprises, and individuals must be channelled into rent paid primarily to major Western economies.
The only long term viable future for producers of digital products is to sell support services and 'added value' in various forms. This in open competition because digital sequences themselves have no more intrinsic scarcity than table salt. With respect to creating sequences possessing utility, it shall be the skills of production that can seek the highest bidder on an open market, but not standalone finished digital products.
"Python, Ruby, and JS have extremely poor performance for some kinds of tasks."
Anyone care to comment on which tasks, and relative frequency in real life? I'd think that by percentage the "really big" applications, with thousands of transactions per second, accessing millions of records would be a small part of Java app. development??
I'm retired now, but I'm really biased against using Java if at all possible. So much bloat, and with all the library dependencies complicating everything. "Just use Jenkins.." I was told, but that just made everything more complicated to set up, and more opaque when things went wrong. Not to mention bloody IBM Websphere loading its libraries first, introducing subtle, and sometimes not so subtle bugs. Gaaaah!
Of course there are so many different use cases out there it's impossible to generalise, but for the simple stuff I developed later on in my career I much preferred Python. But then I started off developing software for SCADA systems in assembler when core memory was VERY expensive. When we moved to RAM and C it was "luxury" (cf Monty Python).
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
