Hello, The link Tim provided to the licesning guide NiFi uses is definitely a great place to start as it brings together a bunch of ASF policy and/or guidance and applies it to the context of Apache NiFi, what we release, and our bundling model.
Whether this is a strict policy or not is clear - yes. The basic gist is: - For any artifact you publish it must have appropriate L&N. The other basic gist: - If it seems easy you're probably doing it wrong. Officially Apache Software Foundation releases are 'source releases only'. This is the top level L&N that all projects have and as TIm mentioned that covers anything in your source tree (has nothing to do with dependencies pulled it during the build or runtime). Some projects only end up having this top level source L&N and it is because they also only provide source and they don't publish the artifacts. By not publishing any derived binary artifacts they are not having to worry about this though for such cases consider that community formation is dependent on people who can adequately take the source and produce a workable build. Some other projects who do produce convenience binaries (such as a zip, tar.gz, jars published to maven) also only end up top level source L&N. This either means they have no dependencies or they're 'doin it wrong'. I've found awareness and or consideration for L&N to be uneven though there seems to be increasing awareness here. People like Billie, Josh, Sean, myself and perhaps most notably Justin McLean are are definitely helping in this arena. Now, many projects do elect to provide convenience binaries and again you have to account for the L&N of each artifact you produce. We have L&N files all over the place in our codebase in NiFi. The Top level L&N accounts for source and all others account for the binary artifact that would be produced. There are *huge* differences between our NOTICE at the top level source and in the nifi-assembly for example. You can ensure that an overriden L&N ends up in your uber jar pretty easily by placing it into the correct META-INF location of your source tree. See here [1] for an example. Finally, I'll add that it is possible we're not doing it correctly in NiFi. We could be overdoing it, under doing it, etc. It is just not easy and everyone ultimately will say "IANAL". The community consensus of 'ok this looks about right is key here'. So lets just keep iterating on it. The uber jar must have an L&N that accounts for all the things that get bundled in it. [1] https://github.com/apache/nifi/blob/6de738fd04f773ba6b05b3768c5214847b55cf50/nifi-nar-bundles/nifi-update-attribute-bundle/nifi-update-attribute-nar/src/main/resources/META-INF/NOTICE On Wed, Aug 17, 2016 at 8:13 AM, Tim Ellison <[email protected]> wrote: > On 17/08/16 16:08, Ellison Anne Williams wrote: >> I'm seeing the same LICENSE and NOTICE files used throughout NiFi - even in >> the nifi-assembly directory which is referenced here >> https://nifi.apache.org/licensing-guide.html >> >> Joe - Am I missing something here? >> >> I would echo Suneel and ask if (1) it is really a strict requirement for >> our sources jar and/or (2) if we are interpreting it correctly. > > If we don't get a local answer, let's ask on general@incubator. The > Foundation policy seems clear enough to me, and I agree that it appears > that many projects are not following it -- so something is wrong. > > http://www.apache.org/dev/licensing-howto.html#bundled-vs-non-bundled > http://www.apache.org/dev/licensing-howto.html#binary > > Regards, > Tim > > >> On Wed, Aug 17, 2016 at 10:55 AM, Suneel Marthi <[email protected]> >> wrote: >> >>> On Wed, Aug 17, 2016 at 10:38 AM, Tim Ellison <[email protected]> >>> wrote: >>> >>>> On 17/08/16 11:40, ellisonanne wrote: >>>>> Github user ellisonanne commented on a diff in the pull request: >>>>> >>>>> https://github.com/apache/incubator-pirk/pull/65# >>>> discussion_r75099656 >>>>> >>>>> --- Diff: LICENSE --- >>>>> @@ -199,4 +199,64 @@ >>>>> distributed under the License is distributed on an "AS IS" >>> BASIS, >>>>> WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or >>>> implied. >>>>> See the License for the specific language governing permissions >>>> and >>>>> - limitations under the License. >>>>> \ No newline at end of file >>>>> + limitations under the License. >>>>> + >>>>> + >>>>> +=========================================================== >>>> ============ >>>>> +Apache Pirk (incubating) Subcomponents: >>>>> + >>>>> +The Apache Pirk project contains subcomponents with separate >>>> copyright >>>>> +notices and license terms. Your use of the source code for the >>> these >>>>> +subcomponents is subject to the terms and conditions of the >>>> following >>>>> +licenses. >>>>> + >>>>> --- End diff -- >>>>> >>>>> I'm confused - how do we create different LICENSE and NOTICE files >>>>> for the different jars when they are built via the release plugin? >>>> >>>> I'm guessing it requires some pom foo beyond my feeble capabilities :-( >>>> >>> >>> I am not sure how u can package/not package license files in different >>> artifacts. >>> If this is a strict requirement, a good chunk of TLPs today are in >>> violation of this. >>> >>> Should we have Justin McLean or John D. Ament from IPMC review our >>> artifacts now? >>> >>>> >>>> Besides stating the obvious that : >>>> >>>> (1) we'd store the source LICENSE and NOTICE file in the project >>>> repository root, and place in there only the required information for >>>> code we are hosting in our repo and including in the source.jar. For >>>> Pirk as it is today, that will be a plain ALv2 text and simple notice. >>>> >>>> (2) we'd then have alternative LICENSE and NOTICE files for the >>>> convenience "exe" JAR in a subdirectory that are used to replace the >>>> top-level files when building the binaries. This would refer to the >>>> license/ directory containing the full text of the 3rd-party licenses. >>>> >>>> Maybe our friends from Apache NiFi can explain what they do, as they >>>> have the correct information in their release guide [1], and they are >>>> Maven-based too. >>>> >>>> A number of other projects I peeked into don't seem to be doing the >>>> right thing IMHO. >>>> >>>> [1] https://nifi.apache.org/licensing-guide.html >>>> >>>> Regards, >>>> Tim >>>> >>> >>
