On 25 March 2014 23:06, James Taylor <[email protected]> wrote: > Our binary distribution bundles sqlline which has a BSD Clause 3 license. > We've included this license with the Apache 2 license in our LICENSE file. > Do we need to include sqlline in the NOTICE file?
Depends on its license. > Yes, we bundle ANTLR in our binary distribution. Most of the other items > are pulled in based on the transitive dependencies of other jars we've > bundled in our binary distribution. I see now why I did not notice the 3rd party binaries. They seem to have been merged into jars which look like phoenix code - and indeed also contain phoenix code. That is a very non-standard way to do things, and I think could mislead end-users as to the provenance of the code. It's OK to bundle separate jars in a binary release (assuming licensing etc is OK), but I don't think it's OK to merge 3rd party code with ASF code in a single jar. Apart from anything, that will play havoc with Maven and possibly other dependency management systems. > That's why we included them in the NOTICE file. Is this correct? As I already wrote, not necessarily. You can only include certain license types; in all cases the licenses must be included in the bundle - either actually included in the LICENSE file or locally linked from it. Some licenses may require attribution in the NOTICE file. See for example http://www.apache.org/dev/licensing-howto.html#permissive-deps > Our LICENSE file includes the licenses of all bundled software - either > Apache 2 or BSD Clause 3. But there is no indication as to which 3rd party software uses what license. again, see http://www.apache.org/dev/licensing-howto.html#permissive-deps > Please advise, as we're trying to follow the guidelines listed here[1]. As am I ... > Thanks, > James > > [1] http://www.apache.org/dev/licensing-howto.html > > > > On Tue, Mar 25, 2014 at 3:48 PM, sebb <[email protected]> wrote: > >> On 25 March 2014 22:27, James Taylor <[email protected]> wrote: >> > Thanks for the detailed review, Sebb. We really appreciate you spending >> > your time going through this. Here's the list of TODOs for us: >> > 1) In the binary bundle: >> > a) Fix the copy/paste error for the URL to SQLLine in the NOTICE file >> > in the binary bundle as noted by Gabriel here[1]. >> >> It's not clear to me that the SQLLine attribution should even be in >> the NOTICE file. >> Though of course if it must be included, the URL should be correct. >> >> > b) Change "developed by" to "developed at" in the NOTICE file >> > c) In answer to your question, yes all those projects listed are >> bundled >> > with our binary distribution. >> >> Are you sure? >> Even JUnit and ANTLR? >> >> Even if they are included, that only means that a LICENSE file entry >> is needed, not necessarily a NOTICE entry. >> >> > 2) In the source bundle: >> > a) The target dir and rat.txt files should be removed from the src >> > bundle >> >> Yes. >> >> > b) There were the following changes made to the src bundle not >> > reflected in git: >> > - the docs/phoenix.csv file was removed (it's part of our website >> so >> > should not be included in our git repo) >> >> OK >> >> > - the build.txt file was modified slightly in the src bundle. >> >> Not OK. >> >> > - the CHANGES file is bundled with the src bundle, but not checked >> > into git. >> >> The source bundle must only contain files contained in the Git tag. >> >> The point is that the only practical way to ensure that the source >> bundle contains only files that have the appropriate license and are >> allowed to be included in a release is to compare the files with Git >> (or SVN). Otherwise it's impossible to establish provenance and >> difficult to determine if the file has a suitable license. >> >> > - the README.md file is not included in the src bundle, but instead >> a >> > README file is included instead. >> >> The ASF releases source, so source files to create documentation >> should be included. >> >> > For the source binary changes, we could commit and push those changes to >> > git and update our 3.0.0 tag. Would that be an acceptable solution? >> >> Not sure what you are proposing. >> >> The RC reviewers need to be able to check that the source bundle >> agrees with the tag. >> Also that the NOTICE and LICENSE files in the bundles agree with the >> contents of those bundles and that any bundled code can be released >> under the Apache License. >> >> > Are there more changes necessary to the NOTICE file in the binary bundle? >> > Would it be acceptable to fix the URL in the next release? If not, would >> we >> > need to go through a dev vote again for the NOTICE file change? >> >> See above. >> >> > FWIW, we'll automate the generation of our release bundles for our next >> > release (and make sure the source matches exactly as well). >> >> > Thanks, >> > James >> > >> > [1] >> > >> http://mail-archives.apache.org/mod_mbox/incubator-phoenix-dev/201403.mbox/%3CCAA5C_puNoy74jniWMTbx%3DZFyc1itf0w6E4kCHvCOTK_OTfBgmg%40mail.gmail.com%3E >> > >> > >> > On Tue, Mar 25, 2014 at 3:16 PM, Andrew Purtell <[email protected]> >> wrote: >> > >> >> James, Mujtaba, et. al., >> >> >> >> Can we add a "Releasing" page to http://phoenix.incubator.apache.org/that >> >> includes step by step instructions for packaging a Phoenix release. We >> can >> >> fine tune this process according to feedback received during RCs. This >> >> could/should include shell commands captured one time through your >> process >> >> for generating a source tarball from a Git checkout at an exact SHA, >> saving >> >> off a clean source tarball before running release checks, generating >> binary >> >> release tarballs, calculating checksums over the tarballs, signing the >> >> tarballs, etc. >> >> >> >> >> >> On Tue, Mar 25, 2014 at 3:09 PM, sebb <[email protected]> wrote: >> >> >> >> > On 25 March 2014 22:01, Andrew Purtell <[email protected]> wrote: >> >> > > Pardon, got -bin and -src crossed mentally, indeed they are there. >> >> > > >> >> > > Looks like src was packaged after running the RAT check. Does this >> >> > require >> >> > > a new RC? >> >> > >> >> > If I were the RM I would respin the RC for this sort of packaging >> error. >> >> > >> >> > But in this case there are other more serious errors, the binary >> NOTICE >> >> > file. >> >> > >> >> > And most important, please establish why the Git tag does not agree >> >> > with the source archive, otherwise the new RC may also be faulty in >> >> > that regard. >> >> > >> >> > It's vital that all files in the source bundle can be traced back to >> >> > the source code control system. >> >> > >> >> > > On Tue, Mar 25, 2014 at 2:59 PM, sebb <[email protected]> wrote: >> >> > > >> >> > >> On 25 March 2014 21:56, Andrew Purtell <[email protected]> >> wrote: >> >> > >> > On Tue, Mar 25, 2014 at 11:54 AM, sebb <[email protected]> wrote: >> >> > >> > >> >> > >> >> On 25 March 2014 16:39, James Taylor <[email protected]> >> >> wrote: >> >> > >> >> [...] >> >> > >> >> >> >> > >> >> > The source tarball, including signatures, digests, etc can be >> >> found >> >> > >> at: >> >> > >> >> > >> >> > >> >> >> >> > >> >> >> > >> >> >> https://dist.apache.org/repos/dist/dev/incubator/phoenix/phoenix-3.0.0-incubating-rc1/src/ >> >> > >> >> >> >> > >> >> The source bundle includes directories and files not in Git. >> >> > >> >> >> >> > >> >> There should be no "target" directories in the source bundle, >> and >> >> no >> >> > >> >> Rat.txt files. >> >> > >> > >> >> > >> > >> >> > >> > Where are those? >> >> > >> >> >> > >> In the source bundle. >> >> > >> >> >> > >> > $ wget >> >> > >> > >> >> > >> >> >> > >> >> >> https://dist.apache.org/repos/dist/dev/incubator/phoenix/phoenix-3.0.0-incubating-rc1/bin/phoenix-3.0.0-incubating.tar.gz >> >> > >> >> >> > >> That's the binary bundle. >> >> > >> >> >> >> -- >> >> Best regards, >> >> >> >> - Andy >> >> >> >> Problems worthy of attack prove their worth by hitting back. - Piet Hein >> >> (via Tom White) >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
