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 18:35:11 UTC
svn commit: r1658084 -
/incubator/nifi/site/trunk/content/development/licensing-guide.md
Author: joewitt
Date: Sat Feb 7 17:35:10 2015
New Revision: 1658084
URL: http://svn.apache.org/r1658084
Log:
formatting 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=1658084&r1=1658083&r2=1658084&view=diff
==============================================================================
--- incubator/nifi/site/trunk/content/development/licensing-guide.md (original)
+++ incubator/nifi/site/trunk/content/development/licensing-guide.md Sat Feb 7 17:35:10 2015
@@ -19,8 +19,10 @@ Notice: Licensed to the Apache Softwa
# <img alt="NiFi logo" style="float: right" src="/images/niFi-logo-horizontal.png" /> Apache NiFi Licensing Guide
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.
+
+#### Disclaimer:
+
+This document is not written lawyers. 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.
## Background Material
@@ -38,57 +40,65 @@ The guidance in this document is meant t
## 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."
+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.
+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 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 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.
+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.
+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.
+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 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.
+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
+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 th
at 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