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
`d...@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
`gene...@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 `gene...@incubator.apache.org, d...@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
+ - d...@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
