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/07 19:24:15 UTC
svn commit: r1658091 -
/incubator/nifi/site/trunk/content/development/licensing-guide.md
Author: joewitt
Date: Sat Feb 7 18:24:15 2015
New Revision: 1658091
URL: http://svn.apache.org/r1658091
Log:
formatting/wording fixes
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=1658091&r1=1658090&r2=1658091&view=diff
==============================================================================
--- incubator/nifi/site/trunk/content/development/licensing-guide.md (original)
+++ incubator/nifi/site/trunk/content/development/licensing-guide.md Sat Feb 7 18:24:15 2015
@@ -53,25 +53,25 @@ Answer: Taken directly from http://incub
### 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.
+For every addition or removal of a 3rd party work as a dependency or as pulled into our source directly we must ensure full
+accounting of the correct LICENSE and NOTICE information.
+
+Our source release must only account for the LICENSE/NOTICE of items that are actually in the source release itself.
+Binary dependencies which are pulled in during the generation of a binary convenience package should not have their
+LICENSE/NOTICE data in the source release. But, they must be accounted for in the binary package.
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'.
+convenience package of 'nifi' (tar.gz, ZIP, etc..)
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.
+LICENSE/NOTICE to gather all source dependency clauses as needed and place them into the overall LICENSE/NOTICE for the
+source release. If generating a binary convenience package 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 promote
+their specific NOTICE/LICENSE text to the binary package LICENSE/NOTICE associated with the assembly. The binary package
+LICENSE/NOTICE then should be a combination of source license data and binary license data.
A binary artifact is any artifact which is created as the result of "compiling" or processing a source artifact.
@@ -79,73 +79,52 @@ For every subcomponent of nifi some bina
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.
+dependencies then you should create or edit the LICENSE and/or NOTICE local to that subcomponent AND modify the
+NOTICE and/or LICENSE of the top level nifi source.
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.
+typical in a NAR, WAR, tar.gz, zip bundle) then you must ensure that the subcomponent binary artifact itself includes
+a full and complete LICENSE and/or NOTICE as needed to cover those 3rd party works. For every modification to the
+subcomponent LICENSE/NOTICE for a given 3rd party work the overall Apache NiFi source and binary LICENSE/NOTICE pairs
+need to be updated and/or verified as well.
+
+To provide a subcomponent local LICENSE/NOTICE 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 the binary artifact. This way for every binary artifact produced from Apache NiFi there will be a
+local and accurate LICENSE/NOTICE for that artifact.
### 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):
+ must ensure it is from [Category-A](http://www.apache.org/legal/resolved.html#category-a) licenses.
- 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.
+[Category-A](http://www.apache.org/legal/resolved.html#category-a) or
+[Category-B](http://www.apache.org/legal/resolved.html#category-b).
-Specific guidance for handling Apache Licensed dependencies is describe here:
-
- http://www.apache.org/dev/licensing-howto.html#alv2-dep
+The key guides for how to apply the LICENSE/NOTICE is found in the following:
-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."
+ - [Source Headers](http://apache.org/legal/src-headers.html#3party)
+ - [Third Party Notices](http://apache.org/legal/resolved.html#required-third-party-notices.)
+ - [How to modify the NOTICE](http://www.apache.org/dev/licensing-howto.html#mod-notice)
-Specific guidance for handling other ASF projects:
+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). 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." 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.
- http://www.apache.org/dev/licensing-howto.html#bundle-asf-product
+Specific guidance for handling Apache Licensed dependencies is describe [here](http://www.apache.org/dev/licensing-howto.html#alv2-dep).
+"If the dependency supplies a NOTICE file, its contents must be analyzed and the relevant portions bubbled up into the top-level NOTICE file."
-In short: "It is not necessary to duplicate the line "This product includes software developed at the Apache Software
+Specific guidance for handling other ASF projects is found [here](http://www.apache.org/dev/licensing-howto.html#bundle-asf-product).
+"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
+Specific guidance for handling LICENSE/NOTICE information for category-B licensed works is [her](http://apache.org/legal/resolved.html#category-b).
+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
@@ -155,6 +134,5 @@ stated "Copyleft provisions apply only t
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:
+Specific guidance for handling works in the public domain is [here](http://apache.org/legal/resolved.html#can-works-placed-in-the-public-domain-be-included-in-apache-products)
- http://apache.org/legal/resolved.html#can-works-placed-in-the-public-domain-be-included-in-apache-products