On 15/08/16 14:48, Ellison Anne Williams wrote: > Tim - thanks for going down into the jars and checking the licenses and > notices - I assumed that they would be the same as what our source code > contained - clearly, I was wrong.
np - that's why we all check them. > I would like to go ahead and address the issue so that our next release is > smooth and all of the steps for a successful release are established and > documented. ok, but... as I wrote earlier, it may be useful to go ahead with the initial release containing all but the "exe jar". Fixing the other items is not a big deal, I don't know how much work is going to be involved with fixing that. The releases and the process will grow in time, getting this far is a great milestone and credit to the original code and folks here. > Looks like we have issues in apache-pirk-0.1.0-incubating-exe.jar and > apache-pirk-0.1.0-incubating-sources.jar > > 1.) apache-pirk-0.1.0-incubating-exe.jar > > No matter what I did on my machine, I was not able to extract by "extract" I assume you mean avoid including? > /META-INF/license/* > licenses for a variety of dependencies, including > LICENSE.jboss-logging.txt -> LGPLv2 > > from apache-pirk-0.1.0-incubating-exe.jar. Thus, I can't look at the > specific problem. > > I can't see where jboss-logging is being pulled into the codebase (can't > find the dependency). I am assuming that it must be pulling it in somewhere > in order to add the corresponding license file. Any thoughts on this one? I don't see it either, but then I'm not familiar with whatever is pulling in these LICENSE files. Running "mvn license:add-third-party" creates a full set of licenses for our pom, and leads to interesting reading. I see more dependencies that may appear in our exe JAR, and require review, such as: (CDDL 1.1) (GPL2 w/ CPE) jersey-client (com.sun.jersey:jersey-client:1.9 - https://jersey.java.net/jersey-client/) (CDDL 1.1) (GPL2 w/ CPE) jersey-core (com.sun.jersey:jersey-core:1.9 - https://jersey.java.net/jersey-core/) (CDDL 1.1) (GPL2 w/ CPE) jersey-json (com.sun.jersey:jersey-json:1.9 - https://jersey.java.net/jersey-json/) (CDDL 1.1) (GPL2 w/ CPE) jersey-server (com.sun.jersey:jersey-server:1.9 - https://jersey.java.net/jersey-server/) (CDDL 1.1) (GPL2 w/ CPE) jersey-guice (com.sun.jersey.contribs:jersey-guice:1.9 - https://jersey.java.net/jersey-contribs/jersey-guice/) (CDDL 1.1) (GPL2 w/ CPE) JAXB RI (com.sun.xml.bind:jaxb-impl:2.2.3-1 - http://jaxb.java.net/) (Common Development and Distribution License (CDDL) v1.0) JavaBeans Activation Framework (JAF) (javax.activation:activation:1.1 - http://java.sun.com/products/javabeans/jaf/index.jsp) (CDDL 1.1) (GPL2 w/ CPE) JAXB API bundle for GlassFish V3 (javax.xml.bind:jaxb-api:2.2.2 - https://jaxb.dev.java.net/) (COMMON DEVELOPMENT AND DISTRIBUTION LICENSE (CDDL) Version 1.0) (GNU General Public Library) Streaming API for XML (javax.xml.stream:stax-api:1.0-2 - no url defined) (Eclipse Public License 1.0) JUnit (junit:junit:4.12 - http://junit.org) (Eclipse Public License v1.0) Eclipse JDT Core (org.eclipse.jdt:core:3.1.1 - http://www.eclipse.org/jdt/) (GNU General Public License (GPL), version 2, with the Classpath exception) JMH Core (org.openjdk.jmh:jmh-core:1.11.3 - http://openjdk.java.net/projects/code-tools/jmh/jmh-core/) (GNU General Public License (GPL), version 2, with the Classpath exception) JMH Generators: Annotation Processors (org.openjdk.jmh:jmh-generator-annprocess:1.11.3 - http://openjdk.java.net/projects/code-tools/jmh/jmh-generator-annprocess/) CDDL 1.1 and EPL 1.0 are allowed in binary artefacts, provided we have a prominent label in the distribution to bring it to users' attention, e.g. in a README etc. We need to do that for the exe JAR README (only). We know about the JMH dependency, and I think they are being correctly excluded from the JAR. > 2.) apache-pirk-0.1.0-incubating-sources.jar > > Not sure why the org.openjdk.jmh.infra.generated.* files are appearing. > They are under the openjdk license, GPL v2, which is not allowed by Apache. Really? I've not seem anything that explains what license governs the generated files. You may well be right though [ citation required ;-) ] > The org.openjdk.jmh is marked as a 'provided' dependency in the pom (recall > that there was a thread on what to do with this and the conclusion was to > leave it in as provided as do other projects). Not sure why it would be > showing up here. Should we mark it as 'runtime' instead of 'provided'? > (asking before I take the time to try it out bc folks may already know how > best to handle it). > > 3.) LICENSE and NOTICE files - It seems that you are suggesting that we > manually append all of the dependency notices to our NOTICE file. Correct? > It also appears that we also need to do the same with the LICENSE file: > http://www.apache.org/dev/release.html#distributing-code-under-several-licenses I've done it manually before, yes. Having one place where users can understand the LICENSEs and NOTICEs under which they take the code is important. I believe it will be acceptable if we reference them (see above) from the main LICENSE/NOTICE file, or include the third-party licenses in a directory rather than append them to a single file. Other mentors can weigh in here with opinions. > So, not done yet... I will rollback once we figure out what's going on (so > that folks can still access the artifacts). Yep, and still work from the 0.1.0 branch so that the development can progress while the release is being tweaked. Regards, Tim > On Mon, Aug 15, 2016 at 8:28 AM, Suneel Marthi <[email protected]> wrote: > >> Thanks for the feedback. Tim. >> >> See my comments inline below. >> >> @Ellison lets rollback the release. >> >> >> >> On Mon, Aug 15, 2016 at 7:35 AM, Tim Ellison <[email protected]> >> wrote: >> >>> On 14/08/16 04:19, Ellison Anne Williams wrote: >>>> Hi, >>>> >>>> This is the vote for release 0.1.0 of Apache Pirk (incubating). >>>> >>>> The vote will be going for at least 72 hours and will be closed on >>> Wednesday >>>> , >>>> August 16, 2016. >>>> >>>> The artifacts can be downloaded here: https://repository.apache. >>>> org/content/repositories/orgapachepirk-1001/org/apache/ >>>> pirk/apache-pirk/0.1.0-incubating/ >>>> >>>> All JIRAs completed for this release are tagged with 'FixVersion = >>> 0.1.0'. >>>> You can view them here: https://issues.apache.org/jira >>> /browse/PIRK-47?jql= >>>> project%20%3D%20PIRK%20AND%20fixVersion%20%3D0.1.0 >>>> >>>> The artifacts have been signed with Key : 1FD8849B >>>> >>>> Please vote accordingly: >>>> >>>> [ ] +1, accept RC as the official 0.1.0 release >>>> [ ] +0, I don't care either way, >>>> [ ] -1, do not accept RC as the official 0.1.0 release because... >>>> >>>> Thanks! >>>> >>>> Ellison Anne >>>> >>> >>> Wow, you guys have had a busy weekend. >>> >>> Looking at the files in that directory... >>> >>> (1) Principal release artefact: >>> apache-pirk-0.1.0-incubating-source-release.zip >>> - sig & sums check ok. >>> - EAW's pub key is in LDAP, KEYS file, etc. >>> - build and test ok on Oracle Java 8b91, RHEL6. >>> - Notice, License files ok. >>> - RAT checks pass. >>> >>> (2) JavaDocs: >>> apache-pirk-0.1.0-incubating-javadoc.jar >>> - sig and sums check ok. >>> - Notice and Licence files ok (in META-INF/). >>> - JavaDocs render ok. >>> >>> (3) Maven pom file: >>> - sig and sums check ok. >>> - references to license and notices ok. >>> - not checked building with it, but oking >>> as minimal diff with project pom. >>> >>> (4) Dependency combined binary convenience: >>> apache-pirk-0.1.0-incubating-exe.jar >>> - sig and sums check ok. >>> - not tested >>> ** notices and license files confusion. >>> ** not passing on notices for included dependencies. >>> >>> jar contains >>> /LICENSE-junit.txt >>> JUnit license >>> /LICENSE.txt >>> BSD license (from Hamcrest) >>> /license/* >>> contains ALv2, and other license and NOTICE file for XML APIs. >>> /META-INF/LICENSE >>> ALv2 >>> /META-INF/LICENSE.txt >>> ALv2 (with reference to org.apache.commons.math3.ml.neuralnet) >>> /META-INF/license/* >>> licenses for a variety of dependencies, including >>> LICENSE.jboss-logging.txt -> LGPLv2 >>> /META-INF/NOTICE >>> Pirk (only) notice file. >>> /META-INF/NOTICE.txt >>> Commons Math notice file. >>> >>> (5) Pirk-only Source JAR >>> apache-pirk-0.1.0-incubating-sources.jar >>> - sig and sums check ok. >>> - Notice and Licence files ok (in META-INF/). >>> - Contains JMH generated source code >>> org.apache.pirk.benchmark.generated.* >>> org.openjdk.jmh.infra.generated.* >>> ** Are we clear on the license for these files? >>> ** Fails RAT checks due to unspecified licenses on these files. >>> - Not tried compiling / further testing. >>> >>> (6) Pirk-only Binary JAR >>> apache-pirk-0.1.0-incubating.jar >>> - sig and sums check ok. >>> - Notice and Licence files ok (in META-INF/). >>> - FYI contains an empty directory (/org/openjdk/). >>> - FYI contains a subset of test material. >>> - No further testing. >>> >>> >>> I have to vote -1 (binding) on these artefacts due to the issues >>> identified in (4) and possibly (5). >>> >>> Notably: >>> (i) we indicate there is LGPLv2.1 material in this release. If true >>> this is contrary to ASF's policy [1], if not then the license text >>> should be removed. >>> >>> (ii) we are not passing through the required NOTICES for Pirk's >>> dependencies as required by their terms. >>> >> >> Definitely needs to be fixed. >> >> >>> >>> Pirk's transitive JAR has deep dependencies, so if we are redistributing >>> them we must include their notice files too. Our JAR has a number of >>> NOTICE files, but they are not comprehensive. Better to have a single >>> complete NOTICE file, e.g. [2]. >>> >>> (iii) we should clarify the licence of generated JMH files, and exclude >>> them for the RAT check or remove them from the artefacts as required. >>> >> >> These are being excluded from generated binary jar, guess they need to be >> excluded from the sources jar too. >> >>> >>> [1] http://www.apache.org/legal/resolved.html#category-x >>> [2] https://github.com/apache/spark/blob/master/NOTICE >>> >>> >>> p.s. I appreciate that (4) is potentially a significant effort to >>> resolve, but the convenience JAR is not essential to a release, so we >>> may consider dropping that from the release artefacts this time round. >>> >> >> Agree, I guess the reason we are even creating that uber artifact could be >> for Hadoop jobs. >> Let's drop it from this release and definitely fix it for the next. >> >> Just a thought. >>> >>> Regards, >>> Tim >>> >> >
