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.muel...@smartthings.com> 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 <jasedbr...@gmail.com> > 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 <jasedbr...@gmail.com> > > 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 <jasedbr...@gmail.com> > > 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 <mibur...@redhat.com> > > >> 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-unsubscr...@cassandra.apache.org > > >>> For additional commands, e-mail: dev-h...@cassandra.apache.org > > >>> > > >>> > > >> > > > > > >
