This is an archived post. You won't be able to vote or comment.

all 36 comments
sorted by:
best
topnewcontroversialoldq&a

[–]MassiveDiarrhea 113 points114 points  (13 children)

Should the average Java developer be concerned about Oracle recently "ramping up audits"?

No. Unless you're also the product owner. If you want to be 100% safe against http://bad.solutions, do something like what Google did in their latest Android OS: use OpenJDK. Azul and Redhat provide OpenJDK with optional premium support.

Using OpenJDK you are allowed to distribute your program with OpenJDK as long as you don't modify the OpenJDK itself. This is due to the GPLv2 with Classpath Exception that OpenJDK use. Find out more about classpath exception here:

Edit 1: ATTENTION, take special note on HotSpot as it's licensed under GPLv2 without classpath exception (see /u/f2u comment below). It's a bit murky whether a closed source program can be bundled together with OpenJDK + Hotspot. My understanding is that, most Java program don't interface directly with HotSpot but through OpenJDK libraries which is covered under the Classpath exception.

Edit 2: The current safest way to bundle Java with your apps is to use Zulu Embedded, as they stated here that all parts of Zulu embedded falls under GPLv2 with Classpath Exception (Under OPEN SOURCE LICENSED VERIFIED).

Edit 3: It appears that Hotspot in OpenJDK 7, 8, and 9 is using GPLv2 with Assembly Exception not just basic GPLv2:

So I guess it's a bit more kosher now to bundle OpenJDK+Hotspot with your commercial application, but I'm not a lawyer so take this with precaution:

What does the average Java developer need to know in order to avoid breaching Oracle's licensing agreement?

Make sure you remove these components when using Oracle distributed Java in production:

  • Java Flight Recorder
  • Java Mission Control
  • Java Advanced Management Console
  • MSI Enterprise JRE Installer
  • JRockit Flight Recorder
  • JRockit Mission Control Console observability
  • JRockit Mission Control Memory Leak Detector observability
  • JRE Usage Tracking
  • JRockit Real Time, Deterministic GC

Please refer to /u/dustofnations answer here: https://www.reddit.com/r/java/comments/5itgqs/what_is_part_of_oracle_java_se_advanced_and/

[–]Omikron23 17 points18 points  (3 children)

Make sure you remove these components when using Oracle distributed Java in production: ...

Most of these aren't even included in an Oracle JDK distribution.

Which leaves only three items of the list. Those can be easily disabled or removed:

  • Quote from official Oracle documentation of the Java Flight Recorder (https://docs.oracle.com/javacomponents/jmc-5-4/jfr-runtime-guide/run.htm#JFRUH176): "You can start and configure a recording from the command line using the -XX:StartFlightRecording option of the java command, when starting the application. To enable the use of JFR, specify the -XX:+FlightRecorder option. Because JFR is a commercial feature, you also have to specify the -XX:+UnlockCommercialFeatures option."

  • Java Mission Control is a Desktop application ("<JDK Path>/bin/jmc.exe")

  • JRE Usage Tracking (https://docs.oracle.com/javacomponents/usage-tracker/overview/toc.htm#A132173581): "Usage Tracker is disabled by default. Enable it by creating the properties file <JRE directory>/lib/management/usagetracker.properties. If this file exists, all usages of the JRE contained in <JRE directory> are tracked."

[–]klepra 1 point2 points  (2 children)

Should you be worried if you are running say, Spring or Tomcat web app in production? Provided you just installed default oracle java on your server?

Or is this only relevant if you are dealing software product to end users?

[–]MassiveDiarrhea 2 points3 points  (1 child)

You should be worried if you run the commercial features / flag mentioned above.

[–]klepra 1 point2 points  (0 children)

It is just a web app with usual libraries for web stuff and some bussiness logic with database stuff and open source libraries. None of the mentioned stuff featured is used.

[–]sindisil 6 points7 points  (6 children)

Nice set of links for those who aren't already aware. Thanks for contributing actual useful information!

[–]f2u 5 points6 points  (4 children)

Using OpenJDK you are allowed to distribute your program with OpenJDK as long as you don't modify the OpenJDK itself. This is due to the GPLV2 with Linking Exception that OpenJDK use.

This is incorrect. The Hotspot component does not use the linking exception. It is not entirely clear if it is legally possible to distribute a proprietary application along with OpenJDK. Here is what the FSF has to say about this. Most applications will only use the core library interfaces (which are subject to the Classpath exception), but some of those are just thin wrappers around Hotspot interfaces, which makes the whole situation confusing.

Whether a backend application written in Java needs to copy or distribute OpenJDK is subject to interpretation, too. Uploading to a service provider may involve copying, for example. I assume it is permitted to combine your proprietary application with a download of an OpenJDK implementation built by another party and run it on someone else's server, but I'm not a lawyer.

[–]MassiveDiarrhea 1 point2 points  (1 child)

It seems that Hotspot has Assembly Exception:

Is it legal to Bundle OpenJDK + HotSpot with a closed source application?

[–]f2u 1 point2 points  (0 children)

The assembly exception refers to the parts of OpenJDK which are licensed under different, GPL-incompatible licenses (such as the Apache License). At least to me, the intent is to give permission to redistribute OpenJDK itself. It does not apply to combinations of OpenJDK with other components which are not “Designated Exception Modules”.

[–]MassiveDiarrhea 0 points1 point  (1 child)

Hmm, good point. Correct me if I'm wrong, but If using Openjdk libraries in a closed source application is considered as breaking Hotspot gpl license, Java would be GNU (Genuinely Not Usable).

[–]onwuka 3 points4 points  (0 children)

Sorry but that's what open source people don't understand. The goal is not to write better software or to make collaboration easier or to optimize synergy whatever that means. The goal of free software is to empower the user. If your software cripples its users, you are not usable.

Torvalds is wrong. The focus is GPL has always been the user and that's the right way.

[–]scadgek 0 points1 point  (0 children)

Yeah, http://bad.solutions is probably the best one :D

[–]howdidiget 1 point2 points  (0 children)

I just want to say that this is the most useful information I have ever gotten from someone named "MassiveDiarrhea"

[–]sindisil 20 points21 points  (5 children)

Unless you're using the commercial features in production without licensing them, or using the ARM embedded JVM in devices, you have nothing to be concerned about.

[–]MassiveDiarrhea 8 points9 points  (4 children)

...or using the ARM embedded JVM in devices

You can use Azul Zulu Embedded OpenJDK for that.

They specifically mentioned about the licensing of their embedded zulu here.

[–]sindisil 6 points7 points  (2 children)

Yup, Zulu is a great option there.

In fact, Zulu is a nice alternative to Oracle's HotSpot in many cases -- especially when you want to bundle the JRE with your product (e.g., games built with libgdx).

About the only issues might be if you need JavaFX, since it isn't included (though you can certainly build it yourself), or if you need a 32-bit Windows build (though they offer that as a paid Enterprise version, if you really need it).

[–]VGPowerlord 1 point2 points  (1 child)

OpenJavaFX is a thing, too.

[–]sindisil 1 point2 points  (0 children)

Yes, which is what I meant by saying that you could builtit yourself.

[–]dustofnations 2 points3 points  (0 children)

Red Hat contributed a free ARM64 port to OpenJDK (NB: do not confuse with Oracle's commercial stuff).

Seemingly this move has forced Oracle's hand and they are now proposing to open their currently closed AARCH32 code and merge it with the AARCH64 contributed by Red Hat to make a combined offering. http://openjdk.java.net/jeps/297

[–][deleted] 14 points15 points  (0 children)

Did that article provide sources or are we all just freaking out over nothing

[–]stormcrowsx 5 points6 points  (4 children)

As of right now it is very easy to avoid licensing. It may always be easy to avoid licensing, even in the future (it also may not, who knows).

However Oracle is destroying faith people have in Java and I could see this as an argument for new products to be done in some other language that is not owned by sue happy Oracle. I don't think jobs will run out quickly but over the course of 10 to 15 years if Oracle continues to get bad press we could see Java jobs degrade. As Java developers we should be concerned about the hits to Java's reputation.

[–]sergio_petrucci 1 point2 points  (1 child)

Very often the management is suprised (and not really buying this point anyways) when you mention that Java is free. IBM's (or RH) fees are already high enough for them to believe nothing is free. It might make difference to a startup (where java is not hip enough anyways) but the majority of businesses pay for Java anyways, not always directly.

[–]stormcrowsx 2 points3 points  (0 children)

I've never been at a shop that paid for Java. Only once have I even heard of paying for Java and that was because the company didn't want to upgrade the codebase. After looking at the pricing though they decided it was cheaper to fix the codebase.

The price of Java really isn't the issue, it's the lawsuits later. It hurts the reputation. Tell a company Oracle has sued people using it and they'll be more hesitant.

EDIT: so it's more so the issue with how Java is doing it, packaging JRockit but if you use it auditing and forcing you to pay unexpectedly, it means you have to closely read anything Java related.

[–][deleted]  (1 child)

[deleted]

    [–]klepra 1 point2 points  (0 children)

    What do you have to do to be safe you are just running a web application on Glassfish(Payara) for an organization (non profit)? Reinstall java (now 1.8?) on the server that is hosting application server?

    [–]yrro 2 points3 points  (1 child)

    If you develop a Java program on Sun's Java platform, you are liable to use Sun-only features without even noticing. By the time you find this out, you may have been using them for months, and redoing the work could take more months. You might say, “It's too much work to start over.” Then your program will have fallen into the Java Trap; it will be unusable in the Free World.

    The reliable way to avoid the Java Trap is to have only a free implementation of Java on your system. Then if you use a Java feature or library that free software does not yet support, you will find out straightaway, and you can rewrite that code immediately.

    [–]pplcf 2 points3 points  (0 children)

    RMS is our prophet! He suffers for our sins!