Apache NiFi Licensing
This document provides guidance to contributors of Apache NiFi to help properly account for licensing, notice, and legal requirements.
Disclaimer:
This document is not written by lawyers. The guidance in this document is meant to compliment 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
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: https://www.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. https://www.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 https://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
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’ (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 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.
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 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 bundle 3rd party works (as would be 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 (for example: you copied in javascript, css, java source files from a website) then you must ensure it is from Category-A licenses.
If the dependency is a binary dependency (for example: maven pulled in a jar file) then you must ensure it is either from Category-A or Category-B.
The key guides for how to apply the LICENSE/NOTICE is found in the following:
Specific guidance for handling LICENSE/NOTICE application for typical MIT/BSD licenses is described here. 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.
Specific guidance for handling Apache Licensed dependencies is describe here. “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 is found here. “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 is here. 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 https://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 is here