Being Wary Does Not Hurt Java
Being Wary Does Not Hurt Java
Being careful is not the same as being hurtful to the larger community. With Oracle's licensing audits still fresh in mind, it's important to stay alert.
Join the DZone community and get the full member experience.Join For Free
How do you break a Monolith into Microservices at Scale? This ebook shows strategies and techniques for building scalable and resilient microservices.
So. Oracle wants to make money from Java. And The Register published a very polarizing piece with a super catchy title about it. According to their sources, "Oracle is massively ramping up audits of Java customers it claims are in breach of its licenses." While the Twitter-verse went ballistic with people criticizing Oracle's behavior, I want to take a minute to recap why I am against this method and clarify, that the normal developer and user have nothing to fear!
People Complaining About Oracle Are Hurting the Community
I've been in and around the Oracle-sphere for many years. And at the moment, tweeting is probably the most important part of how you can get the lastest news about me. I rarely post on this blog because there is so much to do and I do a bunch of posts for my employer already.
The tweet I sent was basically the title of The Register article. The replies and reactions I got implied that just by spreading a FUD article, I am hurting the community. Let's look into the details.
Are Java Developers Affected?
Note: First of all, I am not a lawyer. This isn't meant to be a legal advice! If you are in doubt over your compliance to the BCL, contact a licensing lawyer, your local Oracle User Group, or Oracle.
No. We are covered. The Binary Code License (BCL) explicitly mentions:
"Oracle grants you a non-exclusive, non-transferable, limited license without fees to reproduce internally and use internally the Software complete and unmodified for the purpose of designing, developing, and testing your Programs."
There are some cases you should be aware of.
"You may not use the Commercial Features for running Programs, Java applets or applications in your internal business operations or for any commercial or production purpose, or for any purpose other than as set forth in Sections B, C, D and E of these Supplemental Terms."
If you use a commercial feature in your local environment and stage it to test, you might not be covered.
If you are accessing any of the JMX MBeans under oracle.jrockit.management and bea.jrockit.management to enable observation of a running JVM, independently of the monitoring solutions, you are not covered.
Flight Recorder, Mission Control, and everything mentioned in the below linked PDF are commercial, and you can only use them on your local machine.
A complete list of commercial features is listed in Table 1-1 on page 5 of the Java SE product edition description (PDF). As a general rule of thumb, make sure to NOT use the -XX:+UnlockCommercialFeatures option.
This mostly affects companies who are already Oracle customers and have access to the commercial features (e.g. MSI Enterprise installer). Funny enough, WebLogic, for example includes a Java SE license (random product link).
I'm Still Afraid, What Are the Alternatives?
You can go with various alternatives. First of all, there is the OpenJDK itself. Windows builds are a little tricky, as they are not available directly from the project. Only the latest development releases are available for Windows. But you can also get binaries from Azul (Zulu) and Red Hat. If you are a Red Hat customer of any JBoss Middleware product, you also get support from them.
Why Do I Dislike What OracleDoes?
I do like that Oracle is sponsoring the Java development and I acknowledge that they invest significant manpower into the project. But that doesn't give them a carte blanche to get away with everything.
My main point of criticism is that Oracle makes it easy to accidentally use commercial features. And yes, as people on Twitter pointed out, you should have just read the license and known about it. But as a matter of fact, I believe that separation of concerns is a good design decision. Instead of directing potential customers and users from the OpenJDK site to java.oracle.com with the comment "which are based largely on the same code" and not even distantly mentioning that these do contain commercial features that you aren't allowed to use, it would be easier to have separate commercial and open source builds.
If you click around on the Oracle Java website, you have a couple of hints at licenses. But they don't get you the full picture.
|Java SE Licenses overview page (source)|
And there are plenty of more examples. The number one search result from (my personalized) Google for "Java License Business" leads to this page, for example. Speaking of misleading information, I think, this is a good example. If license conditions aren't well-known, it's also easier to change them. Which probably hasn't been the case, since the BCL PDF linked was last updated 02 April 2013.
My personal opinion is that it can't be healthy for the community to stop improving. And improvements don't come from silence. Unfortunately, Oracle doesn't have a great history in listening to their communities, which also might lead to some catchy and inappropriate headlines from time to time. Nevertheless, let's stay wary and keep communicating things that could improve. It'll help the community more than it hurts in the long run: Open communication is a sign of a healthy community and the way it deals with feedback and criticism is the gauge for their values.
Published at DZone with permission of Markus Eisele , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.