Hi,
ASF legal replied. The whole thing looks like I expected: We may link to the conscrypt library (as it’s ASF2 licensed), but we may not ship (like Jetty does) our “convenience” binaries with it. Here is the text: Roman Shaposhnik commented on LEGAL-425: ---------------------------------------- First of all, Apache Software Foundation is ONLY in business of distributing source code to public. From that perspective you're fine. If you would like to keep distributing convenience binaries I suggest you cut that dependency out. Will that work? So I think the best idea is to only support Java 9+, if you want HTTP2 and TLS. Uwe ----- Uwe Schindler Achterdiek 19, D-28357 Bremen http://www.thetaphi.de <http://www.thetaphi.de/> eMail: [email protected] From: Uwe Schindler <[email protected]> Sent: Wednesday, November 28, 2018 11:56 AM To: [email protected] Subject: RE: Poll: Merge jira/http2 to master branch Hi, About the bundling of conscrypt.jar in the binary distribution of Apache Solr, I opened LEGAL-425: https://issues.apache.org/jira/browse/LEGAL-425 Uwe ----- Uwe Schindler Achterdiek 19, D-28357 Bremen http://www.thetaphi.de <http://www.thetaphi.de/> eMail: [email protected] <mailto:[email protected]> From: Uwe Schindler <[email protected] <mailto:[email protected]> > Sent: Wednesday, November 28, 2018 11:38 AM To: [email protected] <mailto:[email protected]> Subject: RE: Poll: Merge jira/http2 to master branch Hi Dat, hi Shawn, Thanks for the confirmation! This is what I had in mind (missing ALPN support). IMHO, we should not yet switch away from Java 8 as minimum requirement. With multi-release JARs we are at the moment perfectly able to handle users with newer Java versions, but we should still support Java 8 (as its still widely deployed), although EOL is close. As Redhat, AdoptOpenJDK, and several Linux distributions still provide support for Java 8 at least for 2 or 3 more years, I think it’s to early to switch. With recent changes, the support by Oracle is no longer the way to go, as there are many alternatives. My proposal would be to wait until master is branched to “branch_8x” (stays on Java 8 + MR-JAR support), then change “master” to have Java 11 as minimum requirement. About HTTP2: I have no problem with bundling conscrypt (is it needed for both Jetty Server and Jetty Client)?, but disable it by default and only register it in the Java TLS SPI, if Java 8 is used. On Java 9 and later use the shipped HTTP2 support. My proposal would be to do it with a Multirelease JAR (this is currently enabled in Lucene already). If there are license problems, we can do the following: Disable HTTP2 on Java 8 completely but provide documentation in the Solr Ref Guide how to enable it (something like: download conscrypt-uber.jar from maven and save in solr/lib directory). We can enable it automatically, if class.forName() does not throw CNFE). Maybe add a sysprop, but that’s not needed. I think enabling conscrypt is easy with reflection only, or do we need to compile hard against it. From what I figured out, it’s only used at a few places. SolrJ should by default ship without conscyrpt (make it “optional” maven dependency). If it’s in classpath, enable it. Uwe ----- Uwe Schindler Achterdiek 19, D-28357 Bremen http://www.thetaphi.de <http://www.thetaphi.de/> eMail: [email protected] <mailto:[email protected]> From: Đạt Cao Mạnh <[email protected] <mailto:[email protected]> > Sent: Wednesday, November 28, 2018 11:01 AM To: Solr/Lucene Dev <[email protected] <mailto:[email protected]> > Subject: Re: Poll: Merge jira/http2 to master branch Hi, I will try to summary all the options here 1. No support for HTTP/2 + SSL at all, if users want to run SSL they must stick with HTTP/1.1 2. Set Java requirement to 9 and use ALPN implementation of JDK 9 3. If users want to use HTTP/2, we will notice about license problem then download and use Conscrypt library. Of course that we still test the Conscrypt implementation in tests. On Wed, Nov 28, 2018 at 1:06 AM Shawn Heisey <[email protected] <mailto:[email protected]> > wrote: On 11/27/2018 3:32 AM, Uwe Schindler wrote: > I'd like to bring one thing into attention: This library conscrypt is > ASF2-licensed, but the JAR files contain binary versions of an OpenSSL fork > named BoringSSL. I'd recommend to check the licensing, because OpenSSL > licenses are a bit strange (some BSD fork, also ASF2, but some code is still > outdated - I am not sure what the fork actually uses). I have the feeling we > should include ASF legal department. > > Nevertheless, I am not 100% sure if conscrypt should really be inclued by > default in SolrJ. As SolrJ is a client library for Solr and can be used by > external projects, there is the problem of incompatibilities with the native > C code included. E.g., if one uses SolrJ with IBM J9 or other Java versions > different from openjdk. So I'd be careful. My question is: Do we really need > that library. To me it looks like it improves speed only, or is there > something that requires its use? As you might know ... full and proper http/2 support with Java 8 requires the conscrypt library. With Java 9 or higher, the functionality is provided natively by Java. If I remember right, what conscrypt provides that Java 8 lacks is ALPN. If there are license issues with conscrypt, perhaps it might make sense to require a newer major version of Java instead ... but I think that upgrading the project's Java requirement to 9, 10, or 11 probably requires a wider discussion. Lucene probably has no burning need for it right now. I have no idea whether there are language features in Java 9+ that we as a group are wanting to use. Another point for consideration is that the effective EOL for Java 8 is fast approaching, and EOL dates have already come and gone for 9 and 10. Thanks, Shawn --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] <mailto:[email protected]> For additional commands, e-mail: [email protected] <mailto:[email protected]> -- Best regards, Cao Mạnh Đạt D.O.B : 31-07-1991 Cell: (+84) 946.328.329 E-mail: <mailto:[email protected]> [email protected]
