[
https://issues.apache.org/jira/browse/HBASE-22516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16854696#comment-16854696
]
Sean Busbey commented on HBASE-22516:
-------------------------------------
{quote}
bq. review LICENSE / NOTICE files
Comparing current NOTICE file with the one from HBase main project, noticed
that we mention hbase depends on hadoop, guava and bootstrap. We are importing
and shading some third party dependencies here on hboss (including guava), as
well as completely depending on hadoop file system contracts. Should all these
be pointed on NOTICE file? For LICENSE file, hbase project mentions all
additional dependencies under different licenses (jquery, protobuf, adoctor).
Is this only needed for direct dependencies, say for instance hboss relies on
protobuf under the hood, should we include such section on LICENSE as well?
{quote}
Great questions!
There are a few LICENSE/NOTICE instances to be concerned with: the source
artifact we release and any binary convenience artifacts (in our case the jar
files in maven). In each case the LICENSE/NOTICE file should only cover those
things that are contained in _that_ specific artifact.
For the source artifact that means just the stuff in the repo, since we
generate it with a simple git command.
For the jars in the repo, the shaded artifact for HBOSS where we bundle in
third party stuff needs to properly cover all the things we include. So for
example, AFAICT we're not actually including any files or artifacts from
protobuf in what we generate so we wouldn't include anything from it. We _do_
bundle Netty in our HBOSS jar (for talking to zk) and thus we have to
accurately include license details from that project.
As a part of HBASE-22393 ([ref
PR|https://github.com/apache/hbase-filesystem/pull/2]) I tried to make sure the
LICENSE/NOTICE files in the generate hboss jar were correct. It would be good
to give it a spot check.
Essentially, we should make sure we have the full text of any relevant licenses
in the LICENSE file. We shouldn't have any licenses that aren't applicable in
there. Our NOTICE file should cover a notice for our software and reproduce the
applicable bits from any NOTICE file from an included dependency. (the PR has a
bit of discussion between Josh and I around a relevant edge case for NOTICE
files from other foundation projects)
This is a bit of a rabbit hole, so it's usually best to have a specific
question in mind before you start delving into the foundation documentation.
That said, the places I go to look for guidelines are:
* http://www.apache.org/legal/release-policy.html#licensing-documentation
* http://www.apache.org/dev/licensing-howto.html
* http://apache.org/legal/src-headers.html
* http://www.apache.org/legal/resolved
> release hbase-filesystem version 1.0.0-alpha1
> ---------------------------------------------
>
> Key: HBASE-22516
> URL: https://issues.apache.org/jira/browse/HBASE-22516
> Project: HBase
> Issue Type: Task
> Components: community, Filesystem Integration
> Affects Versions: hbase-filesystem-1.0.0-alpha1
> Reporter: Sean Busbey
> Assignee: Wellington Chevreuil
> Priority: Major
> Fix For: hbase-filesystem-1.0.0-alpha1
>
>
> for this first alpha release we haven't evaluated deployment options yet, so
> let's just rely on maven for convenience binaries.
> Rough outline of process:
> # review LICENSE / NOTICE files
> # Make sure rat says our files are fine wrt license headers ({{mvn
> apache-rat:check}})
> # Check git vs jira for a correct list of issues included in the release
> # use Apache Yetus Release Doc Maker to generate release notes / changes and
> check into repo
> # update versions to be non-SNAPSHOT
> # make sure we can still build jars
> # tag RC ({{git tag -s 1.0.0-alpha1-RC0 -m "HBASE-XXXX Tagging the
> 1.0.0-alpha1 first Releae Candidate" && git push origin 1.0.0-alpha1-RC0}})
> # use the git archive command to create a source artifact ({{git archive
> --format=tar.gz
> --output="/tmp/hbase-filesystem-1.0.0-alpha1-RC0/hbase-filesystem-1.0.0-alpha1-src.tar.gz"
> --prefix="hbase-filesystem-1.0.0-alpha1/" 1.0.0-alpha1-RC0}})
> # stage the RC artifacts somewhere accessible by https. Should include
> release notes, changes, and source artifact. each of those should have a gpg
> signature and a sha512 checksum file.
> # stage maven repository (tl;dr: {{mvn deploy -DskipTests -Papache-release}}
> and then https://repository.apache.org. See the longer explanation under the
> steps "Deploy to the Maven Repository" and "Make the Release Candidate
> available" in the [Making a Release
> Candidate|http://hbase.apache.org/book.html#maven.release] ref guide section
> for the main project)
> # call VOTE for release candidate. Include the staged artifacts, staged maven
> repository, any critical issues that need summary
> # iterate on RCs if needed due to VOTE feedback
> # When VOTE passes, tag {{rel/1.0.0-alpha1}}, release maven repository,
> publish artifacts on dist.apache.org, send ANNOUNCE email, and prepare repo
> for further development
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
