Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Remove JDK due to legal problems with Oracle. #2621

Closed
wants to merge 1 commit into from
Closed

Remove JDK due to legal problems with Oracle. #2621

wants to merge 1 commit into from

Conversation

citibeth
Copy link
Member

@tgamblin

The Oracle JDK is surrounded by murky legal issues, and Oracle is now suing users for licensing fees. The current advice is that potential users should seek advice from their legal departments before downloading or installing Oracle JDK. Ignoring this advice could be costly for a typical HPC center, with thousands of nodes in its parallel cluster. Spack (LLNL) could be sued as well.

http://www.theregister.co.uk/2016/12/16/oracle_targets_java_users_non_compliance/

The safest action for Spack would be to remove JDK from its repository (this PR). I would recommend we do that immediately, pending an opinion from LLNL legal department. We should then consider merging #1298. Removing legal liability should take precedence over getting the perfect PR here (which can be done later).

@citibeth
Copy link
Member Author

@hartzell @alfredo-gimenez

@tgamblin
Copy link
Member

tgamblin commented Dec 18, 2016 •
edited

@citibeth I took a look at this. This PR rips out Java and doesn't even fix packages that depend on it. That breaks, among other things, the entire R ecosystem in Spack. I'm not merging that.

I also looked at other distros and what they do to package Java. Homebrew, which is far more popular and widely used than Spack, does this:

$ brew cask install java
==> Caveats
This Cask makes minor modifications to the JRE to prevent issues with
packaged applications, as discussed here:

  https://bugs.eclipse.org/bugs/show_bug.cgi?id=411361

If your Java application still asks for JRE installation, you might need
to reboot or logout/login.

Installing this Cask means you have AGREED to the Oracle Binary Code
License Agreement for Java SE at

  https://www.oracle.com/technetwork/java/javase/terms/license/index.html

==> Downloading http://download.oracle.com/otn-pub/java/jdk/8u102-b14/jdk-8u102-macosx-x64.dmg
######################################################################## 100.0%^

Then I looked at Gentoo. You can find their java page here. They bundle three versions of Java including the Oracle JDK.

If you look at Gentoo's ebuild for the Oracle JDK, they require users to download Java manually and put it in a tarball directory. This is like what we do for Intel Parallel Studio and some other tools that @adamjstewart has packaged.

I am inclined to do what Homebrew does for now, and print a similar message. Then we can package RedHat's IcedTea/OpenJDK or some other decent open implementation, and make java a virtual dependency so that user can pick which JDK they want. At that point we can do what Gentoo does with the Oracle JDK.

@citibeth
Copy link
Member Author

@tgamblin I think the above could be a grave mistake, for the following reasons:

  1. You don't know what Gentoo and Homebrew have negotiated with Oracle. Maybe they have a license that allows them to do whatever they're doing.

  2. You don't know that the Homebrew approach will please Oracle. Oracle has made it clear that their license is to be accepted by having a PERSON go to their website and accept the download. Any other way to accept their licensing agreement would need to be cleared with them.

  3. Even if Homebrew's approach is OK with Oracle for now, you don't know how or when Oracle might change licensing procedures in the future.

  4. You don't know what assets Homebrew and Gentoo have that could be put at risk in an Oracle lawsuit. We DO know that LLNL, and many Spack users have a lot to lose. A lawsuit related to Oracle JDK in Spack would be devastating to Spack. Even if Oracle sues Spack users, they might turn around and sue LLNL -- which would turn around and clamp down on Spack. It is worth breaking a couple of features (temporarily) to avoid that risk.

  5. You are not a lawyer, and neither am I. I think it is wise to run any solution to the issue through the LLNL legal department BEFORE deploying it. ESPECIALLY before the first release version.

I see that some things do depend on Java; claiming that it breaks the entire R ecosystem is, IMHO somewhat of an exaggeration. In any case, we have been aware of this problem now for 5 months, with nothing done about it. Maybe consider merging #1298 ... I think it's safe to assume that any auto-downloading of Oracle's JDK is problematic.

What got me really concerned is the article above in The Register: even organizations that DID download Oracle's JDK and thought it was "free" are later in for a nasty (and expensive) surprise. That's different from MATLAB, where you know it's proprietary, and by the time you have the tarball you already know what it will cost you and have paid for it. It feels like a booby trap, and I just don't think we should be doing auto-anything with a package that could cost organizations large amounts of money if they install it (possibly without even realizing they installed it).

Yes, we need to get serious about non-booby-trapped alternatives. But until we manage that, I really believe we are better safe than sorry. Even if we take the most extreme step of removing Java, I believe only a very few users will notice.

But really.. we should at least consider merging #1298

@adamjstewart
Copy link
Member

In the long run, I agree that we need to package OpenJDK, make java a virtual dep, and set OpenJDK as the default. We should also remove the auto-download/auto-accept feature for Oracle JDK, à la #1298. I think the only thing stopping us from doing this is that no one has packaged OpenJDK yet. Let me take a look at it tomorrow and see how much work it would be to do. It can't be that hard.

@adamjstewart
Copy link
Member

Nvm, just noticed #2622

@tgamblin
Copy link
Member

tgamblin commented Dec 19, 2016 •
edited

@adamjstewart: I started packaging IcedTea (bootstrapper for OpenJDK), so also check that out in #2624.

@tgamblin tgamblin added the java label Dec 19, 2016
@hartzell
Copy link
Contributor

I am not a lawyer. I've sent this upstream within my organization.

Amongst the reasons that I find Java tiresome is the marketing and branding confusion that they've created. Packaging the software with an implicit booby-trap is doubly irritating.

I'm reasonably confident that we're not using any of the licensed tech (but not so comfortable that I haven't raised the question).

I will be very sad if it is ripped out entirely. I can live with (sigh...) a package that requires me to download the tarball in person (satsifying @citibeth's point #2 above) and then automagic'ing the rest.

@tgamblin -- If "someone" just did (pardon my realtime python...)

def fetch(self):
    print "You must download the tarball to %s" % blah.foo.bar()
    # raise an error here....

Would that be enough to disable the automagic and force a person to accept the license?

I don't know if the OpenJDK would work for our users, but Murphy's law makes it unlikely.

@hartzell
Copy link
Contributor

Have we seen this anyplace other than The Register? Fake news, etc....

A bit of quick googling isn't turn up anything. I haven't seen a fuss on Hacker News and don't follow Slashdot or Reddit these days but if this were a conflagration I'd expect to have seen flames...

@adamjstewart
Copy link
Member

@hartzell See #1298 which does what you want. OpenJDK, from what I understand, is almost identical to Oracle JDK. I think they all share the same source code for the core features, although Oracle adds a few tweaks and features to its JDK. So don't give up hope!

@tgamblin
Copy link
Member

@hartzell: we've actually had pretty good luck with OpenJDK here. Atlassian even supports it for their rather complicated suite of applications, so I think it is pretty solid. I'm reasonably convinced it's the answer to the Java issue, and we'll make Java virtual so that if you must have Oracle's JDK you can drop it in.

The nasty thing about OpenJDK is getting it to build. But at least Spack is reasonably good at that part...

@hartzell
Copy link
Contributor

I'm not the java Decider, it'll be up to those who are to see what makes them happy.

I'm glad that spack enables so much!

#1298 seems to be red. Is someone polishing it up?

@hartzell
Copy link
Contributor

@citibeth -- Does #1298 [still] seem like a reasonable response to the issue?

@tgamblin
Copy link
Member

@hartzell: it is a reasonable response. Although I would rather just get OpenJDK dropped in so that there is SOME automatic solution. @adamjstewart said I should ping him about that today.

@citibeth
Copy link
Member Author

citibeth commented Dec 19, 2016 via email

@hartzell
Copy link
Contributor

@citibeth -- Great and Thanks!

@citibeth
Copy link
Member Author

#1298 is ready for review.

@tgamblin tgamblin mentioned this pull request Dec 31, 2016
Closed
@citibeth citibeth closed this Jan 5, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
java new-package
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
4 participants
@citibeth @tgamblin @adamjstewart @hartzell