Oracle’s Java 11 trap
blog.joda.org
blog.joda.org
> With JDK 11 Oracle has updated the license terms on which we offer the Oracle JDK. The new Oracle Technology Network License Agreement for Oracle Java SE is substantially different from the licenses under which previous versions of the JDK were offered. Please review the new terms carefully before downloading and using this product.
> Oracle also offers this software under the GPL License on jdk.java.net/11
https://www.oracle.com/technetwork/java/javase/downloads/jdk...
This information is either deliberately or accidentally missing in the post. If we assume the author did his research before writing this piece, I can only believe this was done with purpose.
They haven't been doing that with JDK licenses, so far -- as long as Java had licenses which didn't allow for this kind of gamesmanship. But now that the license has changed, it's a completely legitimate thing to get worried about.
If code was treated more like ideas or recipes we'd all still have jobs.
If you believe that strongly enough, civil disobedience through ignoring licenses is one approach. No one should risk more than they're willing to lose on the position because you will lose if it's costing someone else enough.
The Oracle license police live for situations like this.
p.s., If it's just personal use you are within the terms of the license.
The new license (https://www.oracle.com/technetwork/java/javase/terms/license...) is very clear. It states in plain English: "Further, You may not: use the Programs for any data processing or any commercial, production, or internal business purposes other than developing, testing, prototyping, and demonstrating your Application;".
How is that not clear?
This entire article is just pure FUD. Oracle has stated over and over and over how the new licensing model works. It's clear to anybody who spends a couple of minutes reading the documentation.
You'd think it's clear, and yet I've joined projects where software with such terms was included in production builds because "it was downloaded with npm so it's open source."
npm install package
Not saying anyone should stake any bets on that argument winning, just that it wouldn't likely be summarily dismissed in court and would at the very least factor into the damages calculation.
Will be interesting to see if any cases like this ever get adjudicated and precedent set.
Edit: Plus even if they aren't you still have the general mindset of "next next install close" where people are so normalized to getting something like that, to test or deploy it would be very easy to miss - given the license of the previous versions it would be an expectation that you would also be able to use the next version for commercial use also.
Although Oracle are perfectly within their rights to change the license, that doesn't mean it's not a dick move and a scummy thing to do.
There are certainly no default repositories that include this code. The whole point (and it's been this way for years) is that you can't download the Oracle jdk without clicking through a license.
In this process the person who downloads the new RPM (aka me) has to be 100% sure that the new JDK is ok to be used. Which I completely missed (my bad) I was wondering about the GPL stuff a bit but I was thinking that Oracle came to their senses and started to distribute the JRE/JDK under a license that is better than the previous one. Again, my bad that I paid attention more to the performance improvements, modules, ZGC etc. than to the license changes. This is why I was surprised when I saw the article from Joda (his real name is Stephen?) and also upvoted, sent around to all my Java peers to be aware that this is absolutely, 100%, pure fuckery that Orcle just dumped on us.
The download page [1] has a large bold warning that the license terms have changed. What else would you like them to do?
[1] - https://www.oracle.com/technetwork/java/javase/downloads/jdk...
I'm not sure you can blame Oracle for this. They could I guess give you a tl;dr summary in the box. But, how long would it take you to study the new situation? A few minutes?
It's debatable whether there are any true software engineers (we're certainly not licensed like traditional engineers), but all software professionals should be concerned about licenses. It's part of the job, as are all ethical considerations of your work.
For example, if agreeing to TOS was neccessary, Let's Encrypt could no longer be "totally automated". Therefore certbot has an "--agree-tos" option, present in oh so many ansible repositories.
If you haven't written a bot, but you habitually download the JRE/JDK from Oracle's website, accepting the license manually each time, is there really a difference? How many people are rereading the license each time they do this? I would guess the number of people that do this is roughly a rounding error above 0.
It's also social media.
Online surveys.
Everybody and your servers needs to keep mum about it or otherwise you'll get a call.
You think I'm making this up? I've worked at two places where we were in contact with Oracle police because they thought we used (more of) their software.
You ignore it, they move on to the next sucker. The people responding are the ones they'll work with.
In my book this is not a warning at all. This is clearly an attempt to mislead without breaking any laws.
What I've always done is install OpenJDK from the system's package manager :P
Just in case someone is interested in references Wikipedia has them near the text:
> OpenJDK is the official reference implementation of Java SE since version 7.
Even today on the Atlasian docs, they provide a Docker image of Confluence to evaluate, but if you buy a production license, you are required to build an OracleJRE Docker container (they provide instructions) for production.
It's been years and they still can't support OpenJDK ... it makes me wonder what weird proprietary crazy reflection shit they're doing in there.
It is a reason why we moved to .net core entirely. I have nothing running Java anymore. Shame as I liked Clojure somewhat.
[0] https://github.com/HotswapProjects/HotswapAgent/issues/218#i...
Why wouldn't it be integrated directly in the upstream OpenJDK source, though? It sounds like it would be a separate patched build that I'd have to download, and wouldn't be available if I just "apt-get install openjdk-11-jdk" in Debian?
So that means that even if you're running Java, you have three options: (1) Continue using it illegally, it will probably be a low risk. This is not advisable especially for larger corporates. (2) Purchase JDK license (3) Switch to OpenJDK
Java 8 has commercial features that are locked by default. You can unlock them by passing a command line flag that looks like -XX:+UnlockCommercialFeatures, so pretty hard to miss.
If you use those in production, you're meant to pay. But virtually nobody does use them. In fact Oracle open sourced them all for Java 11, perhaps because of that fact.
Now in Java 11 there are two JDKs, that are virtually identical. OpenJDK and Oracle JDK. The latter is the same as the former but commercially supported. If you use it in production at all, you're meant to pay. But the only reason to do that is you want commercial support, from what I understand. There are no longer any special features. If you can support yourself (like most can) you just switch to OpenJDK as part of your Java 11 upgrade.
They have not changed the license for Java 8 users "on the fly", I'm not even sure that's legally possible.
So no, OpenJDK by itself is not suitable for production use. To put a Java app in production securely you now need to either pay Oracle or find someone to provide security fixes to OpenJDK beyond what Oracle provides for free.
Just upgrade to OpenJDK_v(N+1) whenever it's out. Get rid of Karaf, Liferay or whatever is holding you back. Don't become a legacy app developer.
THE LICENSE SET FORTH IN THIS SECTION 2 DOES NOT EXTEND TO THE COMMERCIAL FEATURES. YOUR RIGHTS AND OBLIGATIONS RELATED TO THE COMMERCIAL FEATURES ARE AS SET FORTH IN THE SUPPLEMENTAL TERMS ALONG WITH ADDITIONAL LICENSES FOR DEVELOPERS AND PUBLISHERS.
This means that to upgrade from Oracle JDK10 -> Open JDK11, you'll have to write a script yourself to modify the symlinks e.g. to redirect the existing "/etc/alternatives/java -> /usr/java/jdk-10.0.x/bin/java" to the new installation. There are 46 of these symlinks that need changing (for javac, jstack, etc etc).
I hope that's the only change that is required and that I'm not missing something. Anyone know if there is anything else necessary?
Edit: here is the script I just wrote to print out the commands required to change the symlinks:
#!/bin/bash
existingJdkBinPath=$(dirname `readlink /etc/alternatives/java`)
newJdkPath="/opt/jdk-11"
find /etc/alternatives -type l | while read link; do
target=$(readlink "$link")
targetPath=$(dirname $target)
targetFile=$(basename $target)
if [[ $targetPath = $existingJdkBinPath ]]; then
newTarget="$newJdkPath/bin/$targetFile"
echo ln -snf "$newTarget" "$link"
fi
doneMost distros use the IceTea builds for OpenJDK. Hmm . IceTea3 is Java8. There's no Java9 IceTea4 build yet. I can't find any roadmap info on their site ...
Remember, this is the same company that for years grossly knowingly overcharged the US government for licenses, resulting in hundreds of millions later paid in fines.
Their focus is pure bottom line. If that means cheating, so be it. If it means the equivalent of a bait and switch, sure why not.
It's really a shame that circumstances are what they are now. Sun may have had warts, but in comparison it was highly admirable.
I could guess, because I've been at companies doing the same. Active development and support on the product, but no time for tech debt.
Java 9 and up I understand people getting frustrated with a more frequent LTS release and these weird microreleases every year.
What did they do with security updates when they were available for the version they were on?
Questions.
Don't get me wrong, they're not the only ones ice skating uphill on this.
Java 9 is the one that breaks nearly everything. We attempted Java 9 at our last shop and almost every dependency we used had some exception from a removed deprecated function down there in the stack.
From what I understood, I as a student could still use java 11 from Oracle, as I wouldn't be using it for "production". Is that correct? Or are there other implications that I am missing here?
My professional advice to a newcomer to the industry: stay away from Oracle. It is a blight on the software industry. Oracle is a monopolistic anti-consumer patent troll that treats its employees like shit and whose only business ethic is "make money by any means available".
Vendor lock in is a real bitch.
I'd go for OpenJDK simply to form good habits.
They're actively hostile to the whole tech community and their entire business model is based on trapping people into paying for things by not making their licenses clear or changing their licenses.
I don't know why anyone would use any software made by Oracle these days, the alternatives and open implementations of their own systems tend to be faster - and their "unbreakable Linux kernel" is a joke and a legal disaster waiting to happen.
How is that? The license is pretty clear, as stated in the article:
> You may not: use the Programs for any data processing or any commercial, production, or internal business purposes other than developing, testing, prototyping, and demonstrating your Application;
If you cannot understand that language you should not download or use the JDK.
> or changing their licenses.
It was never clear they were going to change their license after years of making it $free to something not $free.
Moreover the changes are good for the community. OpenJDK is now the reference implementation and equivalent to the old Oracle JDK in every way. The only reason to use the Oracle JDK now is to get commercial support from Oracle.
Calling this a "trap" is dumb. Not only did Oracle change the licenses to be better for end users, they are highlighting the changes in a big yellow box and the license is written clearly. OpenJDK is regular GPL + an exception so you don't have to GPL your own apps.
To repeat, Java is getting more free not less.
(Actually, I'm sticking with JDK 8 for now.)
The problem is, to win in court (not just go to court), you need actual grounds. What would be the grounds for suing Oracle in court?
For hiding the terms of the license? They didn't; the new terms have been as plain as any terms are in software licenses.
For changing the terms of the license? But Oracle was never obligated to supply new software on the old terms (unless the old license or some other contract obligated them to, but I don't think that's the case).
For changing the license terms on Java 8? But they had no obligation to continue to supply Java 8 under the old terms. (If you have an old copy of Java 8, the old license continues to apply, unless the old license specifies that Oracle gets to change it. Even if the old license does say that, it's not grounds for a lawsuit.)
So, specifically, on what grounds could you realistically sue Oracle?
Note well: I'm not an apologist for Oracle's behavior. I just don't think there's actual grounds for a lawsuit here.
The problem is that very few companies have the desire or resources to do this. The community certainly doesn't have the resources. We'd need tens of millions of dollars of legal resources to fight their terrible behaviour.
Or any other major player in the Java space like IBM.
Customers' wallets will decide their faith
>"Program(s)" refers to Oracle software provided by Oracle pursuant to this Agreement and any updates, error corrections, and/or Program Documentation provided by Oracle.
Not programs you create using the JDK
- use the Programs for any data processing or any commercial, production, or internal business purposes other than developing, testing, prototyping, and demonstrating your Application;"
To me this reads as, "you can use javac.exe and java.exe in development, but you can't use java.exe in production."
This is a huge change that I probably would not have noticed.
Has Oracle been restructured recently, or are you expecting me to ignore the entire company's history?
import org.apache.hadoop.*;
import org.rapidoid.net.Server;
In case you are wondering people not only using languages for language features but also for the quality/quantity of libraries available in those languages. This is why is very hard to bootstrap a new language. Java has a ton of great libraries that are essential to big data and high performance backend services that you do not have in Go. I could mention tooling as well but we can skip it for now, the aforementioned library situation is enough to not to consider go already. Btw. the new OpenJDK releases are just fine for running Java and many companies use it extensively already (like AWS EMR for example) to run production code.
import (
"net/http"
"github.com/labstack/echo"
)
Java in 2018 is Perl in 2008, roughly.
If you want to compare nifty scripting languages than you can compare Perl with Ruby or Python. In 2008 I was happily using Ruby for most of things we used to do in Perl, a bit slower yes, but who cared and it was much more readable.
Perhaps even compare with Perl 6 :-)
Java also has a multi decade history of remaining backwards compatible across major version upgrades. Barring known exceptions for things explicitly being removed, I don’t see that changing.
And Google has a history of starting and scrapping products without much attention to the remaining userbase. I'm not saying Go is one of these.
But regardless, we're gonna have to give it a few years to get a Swift ecosystem even trying to get on the mic in the same venues as Java/JDK.
Then there is still the regular one, release that get support for a very long time. That LTS releases and Java 11 is the first LTS release since Java 8. Java 8 will still be supported for a while even though Java 11 is out, giving you years to update.
So basically if you like how it worked before, in the days of Java 1.4, 5, 6, ... you just need to only look at LTS releases.
Especially if you use Java for desktop applications rather than server-side. And Generics was not part of Go's plan for a long time.
I enjoy both but would not say Go offers all that Java has or vice versa
Really ? What is the Go equivalent of J2EE ? Do Go appservers exist that offer all the features that something like Payara (Glassfish), JBoss or WebSphere does ?
Kubernetes, Istio, Prometheus, All the Hashicorp stuff, hyperledger, traefik , kong you name it.
EDIT: I see from the docs http://docs.wildfly.org/14/High_Availability_Guide.html that you need to configure an Infinispan cluster, what looks like a non-trivial operation.
I consider not having a suffocating bureaucratic "framework" that can be replaced by simpler and more straightforward constructs most of the time a feature and not a bug
But those that grow up under a bureaucracy tend to miss it
Of course new languages are quickly getting more and more tools but sometimes I feel that they are just reinventing the wheel (sometimes squared). For example: it's easy to host a mirror Maven repository, the file structure is very simple, even with per-project setting. It's not that straightforward with npm or cargo, they push you into centralized model with paid private repositories (npm).
All those 'simpler and more straightforward' constructs cost a lot of extra time and effort, there's a lot of reinventing the wheel going on. Can you do something similar to just adding a field annotated with @PersistenceContext or @Resource and having a database connection injected ? Does it also allow for complete decoupling between the configuration of that datasource and the application itself ? Can it resize the database connection pools live, and then push that config change to an entire cluster, without writing a single line of extra code ?
無
In theory, the changes should really be minimal but to be sure we would need to have a very strong CI and stress testing platform to be sure about upgrading.
All good projects should have this in place anyways.
Back in college, I created a small desktop app that played a WAV file when any key was pressed, but could be closed silently with the mouse. (Its purpose, along with a recording of me screaming, was to train my cats not to sleep on my laptop.) It would have been written in Java 1.4 or maybe 1.3. The applet library was a pretty standard way to open and play an audio file, because it was simple.
Fast forward a few years, I came across the app again and decided to see if it still worked. It didn't work with the existing JRE on my box. So I rebuilt it with a more recent JDK (1.6, I think). It built, but it still didn't work.
See, Java 1.5 AKA "Java 2" had a new memory model, deprecated a lot of things (like applets), and started modernizing heavily. They attempted to maintain backward compatibility, giving us things like the awful erasure-based generics, but it really wasn't fully BC. They really should have just done what Python did with Python 3 and make Java 2.0 non-BC.
This isn't an isolated incident, either. A major project I worked on updated from Java 1.6 to 1.7 and it broke several things. They were fixed pretty quickly, but it still wasn't truly backwards compatible. It's just like the Java claim that you can write once and run anywhere, which is only half-jokingly referred to by devs as "write once, debug everywhere".
Anyway it's a misconception because it only applies to the Oracle JDK, OpenJDK still follows a different support structure I believe.
Er... Well, I'm with you for a different reason than updating... I'm thinking that Oracle is just shifting the licensing ground too much for my comfort.
Besides, dotnet core would not be a better replacement: it's got a large corporation behind too, so nothing prevents them to do the same in the future.
This is an LTS release. It will be available for more than a few months.
Poor little Oracle & IBM.
The 'default' JVM for Ubuntu is OpenJDK, right? You'd have to go out of your way to get your hands on Oracle JDK.
did google do that?
If anything, Oracle have demonstrated that if they feel you owe them something, they will take you to court.
I changed what primary programming language I use as a conscious decision that took years to make. First I had to find a language that was a good replacement and then I had to make the switch. Both require care.
It was easier than I had thought though. And I'm very happy I did.
Am I sure the my new primary language won't grow these problems? No. But I do know that I'd do it again if needed. There is no shortage of programming languages. There is a shortage of programming languages that have a sufficiently good ecosystem around them though.
(I mostly write server software, command line utilities and embedded software (embedded software in C/C++). If I wrote more embedded software on Cortex-M than server software om AMD64 I think I'd really like to use Rust.)
A business cant afford to let devs just install software willy-nilly like.
It remains to be seen whether they'll "go after" the whales who can actually afford compliance staff (but screwed up anyway), or after the small-fish companies that just stood up a web-app to get started, or businesses in between.
I aware they're often the same folks (DevOps), but your senior engineer and/or project manager should be watching what's going out.
> http://jdk.java.net/11
But it is easy to get mixed up since it doesn't ACTUALLY say "OpenJDK" on that page.
It's just weird.
Taking a guess here, they probably realized there's demand among their customer base for plain OpenJDK builds with cheaper and/or more reasonable support offerings compared to Oracle's. And once you need to deliver those builds, it doesn't cost too much to let just anyone use them.
I guess they later figured it could be more generally useful and they could sell support for it.
From the article: They wanted to offer Java on the Microsoft Azure Cloud, unencumbered by complex licensing or end-user restrictions.
What are Oracle doing that their shiny enterprise offerings just have too much baggage attached even for Microsoft?
Zulu is Azul's build of open-source OpenJDK, and no different than any other OpenJDK such as one from jdk.net or AdoptOpenJDK -- it doesn't have a special JIT or special GC, but you can buy a support contract for Zulu (or use it at no cost). It's basically just another OpenJDK build, as far as most people are concerned.
And I wonder if it's inevitable. I wonder whether any language that successfully plays in that space will necessarily suffer the same fate.
The dude owns an island:
https://en.wikipedia.org/wiki/Lanai
https://www.bloomberg.com/news/features/2016-04-13/four-seas...
Stick with free/open source. Vendor lock in is a nightmare. edited for clarity.