On 25 March 2014 23:48, James Taylor <jamestay...@apache.org> wrote: > Ah, I see. Thanks, Sebb. So we should modify our LICENSE file as indicated > in http://www.apache.org/dev/licensing-howto.html#permissive-deps instead > of listing these in our LICENSE file. Since all licenses are either Apache > or BSD, this should be fine. > > I'm still a bit confused about one thing, though. The above link says "add > a pointer to the dependency's location within the source tree". For > sqlline, we bundle it, but have no source dependencies on it. It's used as > a command line terminal interface. Is this pointer optional then? We could > point to the python script that invokes it - would that be correct?
AFAIK the pointer is to the _license_, as shown in the example beneath. [I'll see about clarifying that] Since the BSD license is so short, you may prefer to include in the LICENSE file itself rather than creating a separate file and pointing to that. If several products have the identical license, just list them together. Please include the 3rd party version details (as per the example); it's not unknown for licenses to change between versions. > For our HBase dependencies, we have many places in the source that call > HBase APIs. Do we just list one of them? HBase is ASF code surely? So why does it need mentioning? - unless its NOTICE file has some attributions that relate to what you are bundling > > On Tue, Mar 25, 2014 at 4:25 PM, sebb <seb...@gmail.com> wrote: > >> On 25 March 2014 23:06, James Taylor <jamestay...@apache.org> 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 <seb...@gmail.com> wrote: >> > >> >> On 25 March 2014 22:27, James Taylor <jamestay...@apache.org> 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 <apurt...@apache.org> >> >> 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 <seb...@gmail.com> wrote: >> >> >> >> >> >> > On 25 March 2014 22:01, Andrew Purtell <apurt...@apache.org> >> 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 <seb...@gmail.com> wrote: >> >> >> > > >> >> >> > >> On 25 March 2014 21:56, Andrew Purtell <apurt...@apache.org> >> >> wrote: >> >> >> > >> > On Tue, Mar 25, 2014 at 11:54 AM, sebb <seb...@gmail.com> >> wrote: >> >> >> > >> > >> >> >> > >> >> On 25 March 2014 16:39, James Taylor <jamestay...@apache.org >> > >> >> >> 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: general-unsubscr...@incubator.apache.org >> >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
