Apache NiFi Release Guidelines

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