OSDir


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DISCUSS] java 9 and the future of cassandra on the jdk


See the legal-discuss@ thread:
https://mail-archives.apache.org/mod_mbox/www-legal-discuss/201803.mbox/browser
.

TL;DR jlink-based distributions are not gonna fly due to OpenJDK's license,
so let's focus on other paths forward.


On Thu, Mar 22, 2018 at 2:04 PM, Carl Mueller <carl.mueller@xxxxxxxxxxxxxxx>
wrote:

> Is OpenJDK really not addressing this at all? Is that because OpenJDK is
> beholden to Oracle somehow? This is a major disservice to Apache and the
> java ecosystem as a whole.
>
> When java was fully open sourced, it was supposed to free the ecosystem to
> a large degree from Oracle. Why is OpenJDK being so uncooperative? Are they
> that resource strapped? Can no one, from consulting empires, Google, IBM,
> Amazon, and a host of other major companies take care of this?
>
> This is basically OpenSSL all over again.
>
> Deciding on a way to get a stable language runtime isn't our job. It's the
> job of either the runtime authors (OpenJDK) or another group that should
> form around it.
>
> There is no looming deadline on this, is there? Can we just let the dust
> settle on this in the overall ecosystem to see what happens? And again,
> what is the Apache Software Foundation's approach to this that affects so
> many of their projects?
>
> On Wed, Mar 21, 2018 at 12:55 PM, Jason Brown <jasedbrown@xxxxxxxxx>
> wrote:
>
> > Well, that was quick. TL;DR Redistributing any part of the OpenJDK is
> > basically a no-go.
> >
> > Thus, that option is off the table.
> >
> > On Wed, Mar 21, 2018 at 10:46 AM, Jason Brown <jasedbrown@xxxxxxxxx>
> > wrote:
> >
> > > ftr, I've sent a message to legal-discuss to inquire about the
> licensing
> > > aspect of the OpenJDK as we've been discussing. I believe anyone can
> > follow
> > > the thread by subscribing to the legal-discuss@ ML, or you can wait
> for
> > > updates on this thread as I get them.
> > >
> > > On Wed, Mar 21, 2018 at 9:49 AM, Jason Brown <jasedbrown@xxxxxxxxx>
> > wrote:
> > >
> > >> If we went down this path, I can't imagine we would build OpenJDK
> > >> ourselves, but probably build a release with jlink or javapackager. I
> > >> haven't done homework on that yet, but i *think* it uses a blessed
> > OpenJDK
> > >> release for the packaging (or perhaps whatever JDK you happen to be
> > >> compiling/building with). Thus as long as we build/release when an
> > openJDK
> > >> rev is released, we would hypothetically be ok from a secutiry POV.
> > >>
> > >> That being said, Micke's points about multiple architectures and other
> > >> OSes (Windows for sure, macOS not so sure) are a legit concern as
> those
> > >> would need to be separate packages, with separate CI/testing and so on
> > :(
> > >>
> > >> I'm not sure betting the farm on linux disto support is the path to
> > >> happiness, either. Not everyone uses one of the distros mentioned (RH,
> > >> ubuntu), nor does everyone use linux (sure, the vast majority is
> > Linux/x86,
> > >> but we do support Windows deployment and macOS development).
> > >>
> > >> -Jason
> > >>
> > >>
> > >>
> > >> On Wed, Mar 21, 2018 at 9:26 AM, Michael Burman <miburman@xxxxxxxxxx>
> > >> wrote:
> > >>
> > >>> On 03/21/2018 04:52 PM, Josh McKenzie wrote:
> > >>>
> > >>> This would certainly mitigate a lot of the core problems with the new
> > >>>> release model. Has there been any public statements of plans/intent
> > >>>> with regards to distros doing this?
> > >>>>
> > >>> Since the latest official LTS version is Java 8, that's the only one
> > >>> with publicly available information For RHEL, OpenJDK8 will receive
> > updates
> > >>> until October 2020.  "A major version of OpenJDK is supported for a
> > period
> > >>> of six years from the time that it is first introduced in any version
> > of
> > >>> RHEL, or until the retirement date of the underlying RHEL platform ,
> > >>> whichever is earlier." [1]
> > >>>
> > >>> [1] https://access.redhat.com/articles/1299013
> > >>>
> > >>> In terms of the burden of bugfixes and security fixes if we bundled a
> > >>>> JRE w/C*, cutting a patch release of C* with a new JRE distribution
> > >>>> would be a really low friction process (add to build, check CI,
> green,
> > >>>> done), so I don't think that would be a blocker for the concept.
> > >>>>
> > >>>> And do we have someone actively monitoring CVEs for this? Would we
> > ship
> > >>> a version of OpenJDK which ensures that it works with all the major
> > >>> distributions? Would we run tests against all the major distributions
> > for
> > >>> each of the OpenJDK version we would ship after each CVE with each
> > >>> Cassandra version? Who compiles the OpenJDK distribution we would
> > create
> > >>> (which wouldn't be the official one if we need to maintain support
> for
> > each
> > >>> distribution we support) ? What if one build doesn't work for one
> > distro?
> > >>> Would we not update that CVE? OpenJDK builds that are in the distros
> > are
> > >>> not necessarily the pure ones from the upstream, they might include
> > patches
> > >>> that provide better support for the distribution - or even fix bugs
> > that
> > >>> are not yet in the upstream version.
> > >>>
> > >>> I guess we also need the Windows versions, maybe the PowerPC & ARM
> > >>> versions also at some point. I'm not sure if we plan to support J9 or
> > other
> > >>> JVMs at some point.
> > >>>
> > >>> We would also need to create CVE reports after each Java CVE for
> > >>> Cassandra as well I would assume since it would affect us separately
> > (and
> > >>> updating only the Java wouldn't help).
> > >>>
> > >>> To me this sounds like an understatement of the amount of work that
> > >>> would go to this. Not to mention the bad publicity if Java CVEs are
> not
> > >>> actually patched instantly in the Cassandra also (and then each user
> > would
> > >>> have to validate that the shipped version actually works with their
> > >>> installation in their hardware since they won't get support for it
> > from the
> > >>> vendors as it's unofficial package).
> > >>>
> > >>>   - Micke
> > >>>
> > >>>
> > >>> ------------------------------------------------------------
> ---------
> > >>> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> > >>> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
> > >>>
> > >>>
> > >>
> > >
> >
>