You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@nifi.apache.org by jo...@apache.org on 2015/02/05 07:18:34 UTC
svn commit: r1657482 -
/incubator/nifi/site/trunk/content/development/licensing-guide.md
Author: joewitt
Date: Thu Feb 5 06:18:33 2015
New Revision: 1657482
URL: http://svn.apache.org/r1657482
Log:
added guidance - still needs formatting
Modified:
incubator/nifi/site/trunk/content/development/licensing-guide.md
Modified: incubator/nifi/site/trunk/content/development/licensing-guide.md
URL: http://svn.apache.org/viewvc/incubator/nifi/site/trunk/content/development/licensing-guide.md?rev=1657482&r1=1657481&r2=1657482&view=diff
==============================================================================
--- incubator/nifi/site/trunk/content/development/licensing-guide.md (original)
+++ incubator/nifi/site/trunk/content/development/licensing-guide.md Thu Feb 5 06:18:33 2015
@@ -18,306 +18,77 @@ Notice: Licensed to the Apache Softwa
# <img alt="NiFi logo" style="float: right" src="/images/niFi-logo-horizontal.png" /> Apache NiFi Release Guide
-The purpose of this document is to capture and describe the steps involved in producing
-an official release of Apache NiFi. It is written specifically to someone acting in the
-capacity of a [Release Manager][release-manager] (RM).
-
-## Background Material
-
- - These documents are necessary for all committers to be familiar with
- - [Apache License V2.0][apache-license]
- - [Apache Legal License/Resolved][apache-legal-resolve]
- - [Apache How-to Apply License][apache-license-apply]
- - [Apache Incubator Branding Guidelines][incubator-branding-guidelines]
-
- - These documents are necessary for someone acting as the RM
- - [Apache Encryption Software / ECCN Info][apache-encryption]
- - [Apache Release Policy][apache-release-policy]
- - [Apache Release Guide][apache-release-guide]
- - [Apache Incubator Release Guide][apache-incubator-release-guide]
- - [another Apache Incubator Release Guide][another-apache-incubator-release-guide]
- - [Apache Incubator Policy][apache-incubator-policy]
-
- - These documents are helpful for general environmental setup to perform releases
- - [Apache PGP Info][apache-pgp]
- - [Apache Release Signing][apache-release-signing]
- - [Apache Guide to publish Maven Artifacts][apache-guide-publish-maven]
-
-## The objective
-
-Our aim is to produce and official Apache release.
-The following is a list of the sorts of things that will be validated and are the basics to check
-when evaluating a release for a vote.
-
-## What to validate and how to Validate a release
-
-There are two lists here: one of specific incubator requirements, and another of general Apache requirements.
-
-### Incubator:
-
- - Do the resulting artifacts have 'incubating' in the name?
- - Is there a DISCLAIMER file in the source root that meets the requirements of the Incubator branding guidelines?
-
-### General Apache Release Requirements:
-
- - Are LICENSE and NOTICE file present in the source root and complete?
- - Specifically look in the *-sources.zip artifact and ensure these items are present at the root of the archive.
- - Evaluate the sources and dependencies. Does the overall LICENSE and NOTICE appear correct? Do all licenses fit within the ASF approved licenses?
- - Here is an example path to a sources artifact:
- - `https://repository.apache.org/service/local/repositories/orgapachenifi-1011/content/org/apache/nifi/nifi/0.0.1-incubating/nifi-0.0.1-incubating-source-release.zip`
- - Is there a README available that explains how to build the application and to execute it?
- - Look in the *-sources.zip artifact root for the readme.
- - Are the signatures and hashes correct for the source release?
- - Validate the hashes of the sources artifact do in fact match:
- - `https://repository.apache.org/service/local/repositories/orgapachenifi-1011/content/org/apache/nifi/nifi/0.0.1-incubating/nifi-0.0.1-incubating-source-release.zip.md5`
- - `https://repository.apache.org/service/local/repositories/orgapachenifi-1011/content/org/apache/nifi/nifi/0.0.1-incubating/nifi-0.0.1-incubating-source-release.zip.sha1`
- - Validate the signatures of the sources artifact and of each of the hashes. Here are example paths:
- - `https://repository.apache.org/service/local/repositories/orgapachenifi-1011/content/org/apache/nifi/nifi/0.0.1-incubating/nifi-0.0.1-incubating-source-release.zip.asc`
- - `https://repository.apache.org/service/local/repositories/orgapachenifi-1011/content/org/apache/nifi/nifi/0.0.1-incubating/nifi-0.0.1-incubating-source-release.zip.asc.md5`
- - `https://repository.apache.org/service/local/repositories/orgapachenifi-1011/content/org/apache/nifi/nifi/0.0.1-incubating/nifi-0.0.1-incubating-source-release.zip.asc.sha1`
- - Need a quick reminder on how to [verify a signature](http://www.apache.org/dev/release-signing.html#verifying-signature)?
- - Do all sources have necessary headers?
- - Unzip the sources file into a directory and execute `mvn install -Pcheck-licenses`
- - Are there no unexpected binary files in the release?
- - The only thing we'd expect would be potentially test resources files.
- - Does the app (if appropriate) execute and function as expected?
-
-## The flow of a release (an outline)
- - The community is contributing to a series of JIRA tickets assigned to the next release
- - The number of tickets open/remaining for that next release approaches zero
- - A member of the community suggests a release and initiates a discussion
- - Someone volunteers to be an RM for the release (can be a committer but apache guides indicate preference is a PPMC member)
- - A release candidate is put together and a vote sent to the team.
- - If the team rejects the vote the issues noted are resolved and another RC is generated
- - Once a vote is accepted within the NiFi PPMC for a release candidate then the vote is sent to the IPMC
- - If the IPMC rejects the vote then the issues are resolved and a new RC prepared and voted upon within the PPMC
- - If the IPMC accepts the vote then the release is 'releasable' and can be placed into the appropriate 'dist' location, maven artifacts released from staging.
-
-## The mechanics of the release
-
-### Prepare your environment
-
-Follow the steps outlined in the [Quickstart Guide][quickstart-guide]
-
- At this point you're on the latest 'develop' branch and are able to build the entire application
-
-Create a JIRA ticket for the release tasks and use that ticket number for the commit messages. For example we'll consider NIFI-270 as our ticket. Also
-have in mind the release version you are planning for. For example we'll consider '0.0.1-incubating'.
-
-Create the next version in JIRA if necessary so develop work can continue towards that release.
-
-Create new branch off develop named after the JIRA ticket or just use the develop branch itself. Here we'll use a branch off of develop with
-`git checkout -b NIFI-270-RC1`
-
-Change directory into that of the project you wish to release. For example either `cd nifi`
-
-Verify that Maven has sufficient heap space to perform the build tasks. Some plugins and parts of the build
-consumes a surprisingly large amount of space. These settings have been shown to
-work `MAVEN_OPTS="-Xms1024m -Xmx3076m -XX:MaxPermSize=256m"`
-
-Ensure your settings.xml has been updated as shown below. There are other ways to ensure your PGP key is available for signing as well
-
-> ...
-> <profile>
-> <id>signed_release</id>
-> <properties>
-> <mavenExecutorId>forked-path</mavenExecutorId>
-> <gpg.keyname>YOUR GPG KEY ID HERE</gpg.keyname>
-> <gpg.passphrase>YOUR GPG PASSPHRASE HERE</gpg.passphrase>
-> </properties>
-> </profile>
-> ...
-> <servers>
-> <server>
-> <id>repository.apache.org</id>
-> <username>YOUR USER NAME HERE</username>
-> <password>YOUR MAVEN ENCRYPTED PASSWORD HERE</password>
-> </server>
-> </servers>
-> ...
-
-Ensure the the full application build and tests all work by executing
-`mvn -T 2.5C clean install` for a parallel build. Once that completes you can
-startup and test the application by `cd nifi-assembly/target` then run `bin/nifi.sh start` in the nifi build.
-The application should be up and running in a few seconds at `http://localhost:8080/nifi`
-
-Evaluate and ensure the appropriate license headers are present on all source files. Ensure LICENSE and NOTICE files are complete and accurate.
-Developers should always be keeping these up to date as they go along adding source and modifying dependencies to keep this burden manageable.
-This command `mvn install -Pcheck-licenses` should be run as well to help validate. If that doesn't complete cleanly it must be addressed.
-
-Now its time to have maven prepare the release so execute `mvn release:prepare -Psigned_release -DscmCommentPrefix="NIFI-270-RC1 " -Darguments="-DskipTests"`.
-Maven will ask:
-
-`What is the release version for "Apache NiFi"? (org.apache.nifi:nifi) 0.0.1-incubating: :`
-
-Just hit enter to accept the default.
-
-Maven will then ask:
-
-`What is SCM release tag or label for "Apache NiFi"? (org.apache.nifi:nifi) nifi-0.0.1-incubating: : `
-
-Enter `nifi-0.0.1-incubating-RC1` or whatever the appropriate release candidate (RC) number is.
-Maven will then ask:
-
-`What is the new development version for "Apache NiFi"? (org.apache.nifi:nifi) 0.0.2-incubating-SNAPSHOT: :`
-
-Just hit enter to accept the default.
-
-Now that preparation went perfectly it is time to perform the release and deploy artifacts to staging. To do that execute
-
-`mvn release:perform -Psigned_release -DscmCommentPrefix="NIFI-270-RC1 " -Darguments="-DskipTests"`
-
-That will complete successfully and this means the artifacts have been released to the Apache Nexus staging repository. You will see something like
-
-` [INFO] * Closing staging repository with ID "orgapachenifi-1011".`
-
-So if you browse to `https://repository.apache.org/#stagingRepositories` login with your Apache committer credentials and you should see `orgapachenifi-1011`. If you click on that you can inspect the various staged artifacts.
-
-Validate that all the various aspects of the staged artifacts appear correct
-
- - Download the sources. Do they compile cleanly? If the result is a build does it execute?
- - Validate the hashes match.
- - Validate that the sources contain no unexpected binaries.
- - Validate the signature for the build and hashes.
- - Validate the LICENSE/NOTICE/DISCLAIMER/Headers.
- - Validate that the README is present and provides sufficient information to build and if necessary execute.
+This document provides guidance to contributors of Apache NiFi (incubating) to help properly account for licensing, notice, and legal requirements.
+
+The guidance in this document is meant to compliment Apache Incubator and Apache Software Foundation guides and policies. If anything in this document is inconsistent with those then it is a defect in this document.
-If all looks good then push the branch to origin `git push origin NIFI-270`
+## Background Material
-If anything isn't correct about the staged artifacts you can drop the staged repo from repository.apache.org and delete the
-local tag in git. If you also delete the local branch and clear your local maven repository under org/apache/nifi then it is
-as if the release never happened. Before doing that though try to figure out what went wrong. So as described here you see
-that you can pretty easily test the release process until you get it right. The `mvn versions:set ` and `mvn versions:commit `
-commands can come in handy to help do this so you can set versions to something clearly release test related.
-
-Now it's time to initiate a vote within the PPMC. Send the vote request to `dev@nifi.incubator.apache.org`
-with a subject of `[VOTE] Release Apache NiFi 0.0.1-incubating`. The following template can be used:
-
-> Hello
-> I am pleased to be calling this vote for the source release of Apache NiFi
-> nifi-0.0.1-incubating.
->
-> The source zip, including signatures, digests, etc. can be found at:
-> https://repository.apache.org/content/repositories/orgapachenifi-1011
->
-> The Git tag is nifi-0.0.1-incubating-RC1
-> The Git commit ID is 72abf18c2e045e9ef404050e2bffc9cef67d2558
-> https://git-wip-us.apache.org/repos/asf?p=incubator-nifi.git;a=commit;h=72abf18c2e045e9ef404050e2bffc9cef67d2558
->
-> Checksums of nifi-0.0.1-incubating-source-release.zip:
-> MD5: 5a580756a17b0573efa3070c70585698
-> SHA1: a79ff8fd0d2f81523b675e4c69a7656160ff1214
->
-> Release artifacts are signed with the following key:
-> https://people.apache.org/keys/committer/joewitt.asc
->
-> KEYS file available here:
-> https://dist.apache.org/repos/dist/release/incubator/nifi/KEYS
->
-> 8 issues were closed/resolved for this release:
-> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020&version=12329307
->
-> The vote will be open for 72 hours.
-> Please download the release candidate and evaluate the necessary items including checking hashes, signatures, build from source, and test. The please vote:
->
-> [ ] +1 Release this package as nifi-0.0.1-incubating
-> [ ] +0 no opinion
-> [ ] -1 Do not release this package because because...
-
-A release vote is majority rule. So wait 72 hours and see if there are at least 3 binding (in the PPMC sense of binding) +1 votes and no more negative votes than positive.
-If so forward the vote to the IPMC. Send the vote request to `general@incubator.apache.org` with a subject of
-`[VOTE] Release Apache NiFi 0.0.1-incubating`. The following template can be used:
-
-> Hello
->
-> The Apache NiFi PPMC has voted to release Apache NiFi 0.0.1-incubating.
-> The vote was based on the release candidate and thread described below.
-> We now request the IPMC to vote on this release.
->
-> Here is the PPMC voting result:
-> X +1 (binding)
-> Y -1 (binding)
->
-> Here is the PPMC vote thread: [URL TO PPMC Vote Thread]
->
-> The source zip, including signatures, digests, etc. can be found at:
-> https://repository.apache.org/content/repositories/orgapachenifi-1011
->
-> The Git tag is nifi-0.0.1-incubating-RC1
-> The Git commit ID is 72abf18c2e045e9ef404050e2bffc9cef67d2558
-> https://git-wip-us.apache.org/repos/asf?p=incubator-nifi.git;a=commit;h=72abf18c2e045e9ef404050e2bffc9cef67d2558
->
-> Checksums of nifi-0.0.1-incubating-source-release.zip:
-> MD5: 5a580756a17b0573efa3070c70585698
-> SHA1: a79ff8fd0d2f81523b675e4c69a7656160ff1214
->
-> Release artifacts are signed with the following key:
-> https://people.apache.org/keys/committer/joewitt.asc
->
-> KEYS file available here:
-> https://dist.apache.org/repos/dist/release/incubator/nifi/KEYS
->
-> 8 issues were closed/resolved for this release:
-> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020&version=12329307
->
-> The vote will be open for 72 hours.
-> Please download the release candidate and evaluate the necessary items including checking hashes, signatures, build from source, and test. The please vote:
->
-> [ ] +1 Release this package as nifi-0.0.1-incubating
-> [ ] +0 no opinion
-> [ ] -1 Do not release this package because because...
-
-Wait 72 hours. If the vote passes then send a vote result email. Send the email to `general@incubator.apache.org, dev@nifi.incubator.apache.org`
-with a subject of `[RESULT][VOTE] Release Apache NiFi 0.0.1-incubating`. Use a template such as:
-
-> Hello
->
-> The release passes with
->
-> X +1 (binding) votes
-> Y -1 (binding) votes
->
-> Thanks to all who helped make this release possible.
->
-> Here is the IPMC vote thread: [INSERT URL OF IPMC Vote Thread]
-
-Now all the voting is done and the release is good to go.
-
-Here are the steps of the release once the release is approved:
-
-1. Upload source-release artifacts to dist. If the release version is 0.0.1-incubating then upload them (zip, asc, md5, sha1) to
-`https://dist.apache.org/repos/dist/release/incubator/nifi/0.0.1-incubating`
-
-2. To produce binary convenience release build the application from the raw source in staging. For each binary convenience artifact:
- - Generate ascii armored detached signature by running `gpg -a -b nifi-0.0.1-incubating-bin.tar.gz`
- - Generate md5 hash summary by running `md5sum nifi-0.0.1-incubating-bin.tar.gz | awk '{ printf substr($0,0,32)}' > nifi-0.0.1-incubating-bin.tar.gz.md5`
- - Generate sha1 hash summary by running `sha1sum nifi-0.0.1-incubating-bin.tar.gz | awk '{ printf substr($0,0,40)}' > nifi-0.0.1-incubating-bin.tar.gz.sha1`
- - Upload the bin, asc, sha1, md5 for each binary convenience build to the same location as the source release
-
-3. In repository.apache.org go to the staging repository and select `release` and follow instructions on the site.
-
-4. Merge the release branch into master
-
-5. Merge the release branch into develop
-
-6. Update the NiFi website to point to the new download(s)
-
-7. Update the NiFi incubator status page to indicate NEWS of the release
-
-8. In Jira mark the release version as 'Released' and 'Archived' through 'version' management in the 'administration' console.
-
-[quickstart-guide]: http://nifi.incubator.apache.org/development/quickstart.html
-[release-manager]: http://www.apache.org/dev/release-publishing.html#release_manager
-[apache-license]: http://apache.org/licenses/LICENSE-2.0
-[apache-license-apply]: http://www.apache.org/dev/apply-license.html
-[apache-legal-resolve]: http://www.apache.org/legal/resolved.html
-[apache-encryption]: http://www.apache.org/licenses/exports/
-[apache-release-policy]: http://www.apache.org/dev/release.html
-[apache-release-guide]: http://www.apache.org/dev/release-publishing
-[apache-incubator-release-guide]: http://incubator.apache.org/guides/releasemanagement.html
-[another-apache-incubator-release-guide]: http://incubator.apache.org/guides/release.html
-[apache-incubator-policy]: http://incubator.apache.org/incubation/Incubation_Policy.html
-[incubator-branding-guidelines]: http://incubator.apache.org/guides/branding.html
-[apache-pgp]: http://www.apache.org/dev/openpgp.html
-[apache-release-signing]: http://www.apache.org/dev/release-signing.html
-[apache-guide-publish-maven]: http://www.apache.org/dev/publishing-maven-artifacts.html
\ No newline at end of file
+- [ASLv2](http://apache.org/licenses/LICENSE-2.0)
+- [ASF License Apply](http://www.apache.org/dev/apply-license.html)
+- [ASF Licensing How-To](http://www.apache.org/dev/licensing-howto.html)
+- [ASF Legal Resolved](http://www.apache.org/legal/resolved.html)
+- [ASF Release Policy](http://www.apache.org/dev/release.html)
+- [ASF Incubator License and Notice Guidance](http://incubator.apache.org/guides/releasemanagement.html#note-license-and-notice)
+- Mailing-Lists
+ - dev@nifi.iao
+ - general@iao
+ - legal-discuss@ao
+
+## How to consistently apply licensing/legal notice information for Apache NiFi
+
+### Apply the source header to each source file
+ Every source file for works submitted directly to the ASF must follow: http://apache.org/legal/src-headers.html#headers
+
+ Question: Every source file? What about test files and so on?
+ Answer: There are a few exceptions. Test files can be argued to have no degree of creativity. We also need our test materials at times to be exactly as they will be found in the wild. We should ensure test files have the license when possible but not to the point that it requires altering the test itself.
+ http://apache.org/legal/src-headers.html#faq-exceptions
+
+ Question: Do items which are generated from source during the build process require the header?
+ Answer: Taken directly from http://incubator.apache.org/guides/releasemanagement.html#notes-license-headers it reads:
+ "Copyright may not subsist in a document which is generated by an transformation from an original. In which case, the license header may be unnecessary. License headers should always be present in the original. Where it is reasonable to do so, the templates should also add the license header to the generated documents."
+
+### Apply the proper NOTICE / LICENSE Information
+
+ Every source file or dependency pulled into or removed from a release bundle (source or binary) for 3rd party works must be accounted for as necessary in the LICENSE/NOTICE. This guidance should kick in anytime you wish to commit new source materials or you wish to modify the dependencies of a given artifact. The only official release product of Apache NiFi is the source-release. And its LICENSE and NOTICE must be full and complete for all items included in the actual source release (ie it should not include license/notice information for binary dependencies). We do, however, want to provide convenience binary packages as well (tar.gz, zip). In so doing those packages must also have a LICENSE/NOTICE file that is complete and correct and in that case it must include all necessary additional items for bundled binary dependencies.
+
+ The LICENSE and NOTICE files found at the root of the Apache NiFi (nifi) component is considered 'The' LICENSE/NOTICE covering the source release of 'nifi' and all subcomponents.
+
+ The LICENSE and NOTICE files found within the 'nifi-assembly' is considered 'The' LICENSE/NOTICE pair covering the binary convenience package of 'nifi'.
+
+ The Release Manager (RM) of a given release is responsible for checking all subcomponents for the presence of specific LICENSE/NOTICE to gather all source dependency clauses as needed and place them into the over LICENSE/NOTICE for a source release. In addition, the RM will gather up a listing of all binary dependencies as called out on subcomponents (including the assembly itself), which can contain binary dependencies, and promoting their specific NOTICE/LICENSE text to the binary package LICENSE/NOTICE associated with the assembly.
+
+ A binary artifact is any artifact which is created as the result of "compiling" or processing a source artifact.
+
+ For every subcomponent of nifi some binary artifact is produced because we make these things available as Maven artifacts. You must consider whether that artifact stands on its own as built from source or whether that artifact is comprised of materials built from source combined with other binary artifacts pulled in as dependencies.
+
+ In the case of subcomponents which produce binary artifacts which stand on their own (as would be typical in most Jar files) then you must only account for any 3rd party works source dependencies. If you have any 3rd party works source dependencies then you should create or edit the LICENSE and/or NOTICE local to that subcomponent. When you modify the NOTICE and/or LICENSE remember to carry that up to the nifi source and assembly LICENSE/NOTICE files.
+
+ In the case of subcomponents which produce binary artifacts which themselves can bunde 3rd party works (as would be typical in a NAR, WAR, tar.gz, zip bundle) then you must ensure that the subcomponent artifact itself includes a full and complete LICENSE and/or NOTICE as needed to cover those 3rd party works. For every modification to the subcomponents LICENSE/NOTICE for a given 3rd party work the overall Apache NiFi source and binary LICENSE/NOTICE pairs need to be updated as well. To provide a subcomponent local LICENSE/NOTICE pair to cover any binary artifacts it might produce ensure there is a 'src/main/resources/META-INF/NOTICE' and 'src/main/resources/META-INF/LICENSE' as needed. During the build process Maven will place them in the customary locations for binary builds. This way for every binary artifact produced from Apache NiFi there will be a local and accurate LICENSE/NOTICE but the overall LICENSE/NOTICE pairs for source and binary packages will be accurate as well.
+
+### How to go about working with the LICENSE/NOTICE modifications
+
+ If the dependency is a source dependency (ie you copied in javascript, css, java source files from a website) then you must ensure it is from category-A licenses as listed here (otherwise you cannot use it in this manner):
+ http://www.apache.org/legal/resolved.html#category-a
+ If the dependency is a binary dependency (ie maven pulled in a jar file) then you must ensure it is either from category-a or category-b as listed here:
+ http://www.apache.org/legal/resolved.html#category-a
+ http://www.apache.org/legal/resolved.html#category-b
+ The key guides for how to apply the LICENSE/NOTICE is found in the following:
+ http://apache.org/legal/src-headers.html#3party
+ http://apache.org/legal/resolved.html#required-third-party-notices.
+ http://www.apache.org/dev/licensing-howto.html#mod-notice
+ Specific guidance for handling LICENSE/NOTICE application for typical MIT/BSD licenses is described here:
+ http://www.apache.org/dev/licensing-howto.html#permissive-deps
+ In short: "Under normal circumstances, there is no need to modify NOTICE. NOTE: It's also possible to include the text of the 3rd party license within the LICENSE file. This is best reserved for short licenses."
+ And: "Copyright notifications which have been relocated from source files (rather than removed) must be preserved in NOTICE. However, elements such as the copyright notifications embedded within BSD and MIT licenses need not be duplicated in NOTICE -- it suffices to leave those notices in their original locations.". For understanding what to put in the LICENSE file look at the license of the 3rd party work. BSD licenses for instance have this statement "Redistributions in binary form must reproduce the above copyright notice,this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution." This is a pretty clear statement about what must be included in the LICENSE. In the event you cannot find the actual Copyright statement for a dependency then place a link to the license text they claim and indicate no copyright marks found and provide a link to the project website. If that still doesn't seem satisfactory then
that dependency might not be good to use.
+ Specific guidance for handling Apache Licensed dependencies is describe here:
+ http://www.apache.org/dev/licensing-howto.html#alv2-dep
+ In short: "If the dependency supplies a NOTICE file, its contents must be analyzed and the relevant portions bubbled up into the top-level NOTICE file."
+ Specific guidance for handling other ASF projects:
+ http://www.apache.org/dev/licensing-howto.html#bundle-asf-product
+ In short: "It is not necessary to duplicate the line "This product includes software developed at the Apache Software Foundation...", though the ASF copyright line and any other portions of NOTICE must be considered for propagation."
+ Specific guidance for handling LICENSE/NOTICE information for category-B licensed works:
+ http://apache.org/legal/resolved.html#category-b
+ In short: Place an entry in the notice indicating the work is included in binary distribution. Provide a link to the homepage of the work. Indicate it's license. Group like licensed items together. "By attaching a prominent label to the distribution and requiring an explicit action by the user to get the reciprocally-licensed source, users are less likely to be unaware of restrictions significantly different from those of the Apache License. Please include the URL to the product's homepage in the prominent label." You should not modify the LICENSE file to include the LICENSE information of the 3rd party work in this case. That is explained nicely in http://opensource.org/faq#copyleft as stated "Copyleft provisions apply only to actual derivatives, that is, cases where an existing copylefted work was modified. Merely distributing a copyleft work alongside a non-copyleft work does not cause the latter to fall under the copyleft terms."
+ Specific guidance for handling works in the public domain:
+ http://apache.org/legal/resolved.html#can-works-placed-in-the-public-domain-be-included-in-apache-products