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 >>> >>> >> >
