[
https://issues.apache.org/jira/browse/SPARK-5813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14321764#comment-14321764
]
Florian Verhein commented on SPARK-5813:
----------------------------------------
INAL but here are my thoughts:
The user ends up downloading it from Oracle and accepting the license terms in
that process, so as long as they are (or made) aware then I don't really see a
problem. It's just providing a mechanism for them to do this. i.e. It's not a
redistribution issue.
I think a reasonable solution to this would be to have OpenJDK as the default,
with OracleJDK as an option that the user must specifically request (and the
option's documentation indicating that this entails acceptance of a license...
etc)
At least, *the above is true in the case where the user builds their own AMI
(that's the approach I take since it best suits my requirements). With provided
AMIs I think this is more complex, because I would assume that is
redistribution*. I guess that applies to any software that is put on the AMI
actually... so this may be an issue that needs looking at more generally...
I don't know how to best approach that case other than adhering to any
redistribution terms & including these as part of an EULA for spark-ec2/AMIs or
something?
But with the work [~nchammas] has done, I suppose the easiest way would be to
provide the public AMIs with OpenJDK, and add an option to build ones with
OracleJDK if the user is inclined to do this themselves.
Hmmm... is this worthwhile?
> Spark-ec2: Switch to OracleJDK
> ------------------------------
>
> Key: SPARK-5813
> URL: https://issues.apache.org/jira/browse/SPARK-5813
> Project: Spark
> Issue Type: Improvement
> Components: EC2
> Reporter: Florian Verhein
> Priority: Minor
>
> Currently using OpenJDK, however it is generally recommended to use Oracle
> JDK, esp for Hadoop deployments, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
