Michael, Thanks for being so diligent on the L&N considerations.
For the binary dependencies you're listing here I'd take the following approach: 1) For google rpc dependency that is a new version but appears to be the same LICENSE text I'd simply update this line [1] to say The binary distribution of this product bundles 'Google Protocol Buffers Java 2.5.0 and 3.3.1' -OR- The binary distribution of this product bundles 'Google Protocol Buffers Java' Also, be sure your nar's LICENSE includes the proper entry google rpc in its license. See other nars for examples of this. You might have already done this but I've not looked at the totality of the PR. 2) For Netty I think we're already covered sufficiently with our existing notice details as seen in our assembly NOTICE now [2]. But you should be sure to have a similar entry in your nar's NOTICE. The other information they have in their NOTICE (of which 4.1 appears to be a superset) could be carried forward but all the binary references are irrelevant for what I'll describe in #3 next. Their NOTICE entries which say "this includes a modified portion of" should probably be carried forward in the NOTICE in the nar and assembly level. Since the 4.1 NOTICE is a superset I'd just use that one only [3] 3) Whether some binary dependencies NOTICE calls out a transitive binary dependency it might or might not have is not relevant. What is relevant is which transitive dependencies, no matter how many levels deep it comes in, we pull into our nars or convenience binaries. They must all be accounted for properly if we're including them. See here for the general guidance on this [4]. I realize the L&N stuff can be a bit daunting, especially at first or in complex and highly dependency heavy contributions. Indeed it can feel like no good deed goes unpunished. But we can definitely help you work through it. Thanks! Joe [1] https://github.com/m-hogue/nifi/blob/4b845b39f36ae38470017ea61b104d01310b8f16/nifi-assembly/LICENSE#L1086 [2] https://github.com/apache/nifi/blob/master/nifi-assembly/NOTICE#L939 [3] https://github.com/netty/netty/blob/4.1/NOTICE.txt [4] https://nifi.apache.org/licensing-guide.html On Tue, Jun 27, 2017 at 10:26 PM, Tony Kurc <trk...@gmail.com> wrote: > For reference: > Netty 4.1 NOTICE > https://github.com/netty/netty/blob/4.1/NOTICE.txt > Netty 3.7 NOTICE > https://github.com/netty/netty/blob/3.7/NOTICE.txt > > > > > On Tue, Jun 27, 2017 at 10:21 PM, Tony Kurc <trk...@gmail.com> wrote: > >> Background, I asked Mike how he put together the LICENSE, and why he added >> a separate section in the LICENSE for Google Protocol Buffers 3.3.1, and >> his answer that made sense was "well, what existed there was there had a >> version (2.5.0)". >> >> Interesting note, the Google Protocol Buffers LICENSE looks to be the >> same. >> >> Sort of the opposite issue with Netty. NOTICE didn't have a version of >> Netty, and the NOTICES between versions were fairly different. >> >> >> >> On Tue, Jun 27, 2017 at 10:16 PM, Michael Hogue < >> michael.p.hogu...@gmail.com> wrote: >> >>> Hello all, >>> >>> I'm attempting to merge a LICENSE and NOTICE i've created for a new >>> grpc >>> processor bundle [1,2] into the NiFi assembly. I've run into a couple of >>> things i don't know how to resolve: >>> >>> 1. If I add a new (transitive) dependency with a newer version than exists >>> elsewhere in the code _and_ the licenses are the same except for the >>> version, do the license for each of the versions need spelled out in the >>> nifi assembly LICENSE file? >>> >>> 2. One of the grpc dependencies i've added pulls in a version of netty >>> fairly different than what exists in the code already. Should there be a >>> separate block in the assembly NOTICE if they differ? Is it sufficient to >>> add to the existing netty block? >>> >>> PR reference: >>> https://github.com/apache/nifi/pull/1947/files#diff-c3a3e6d0 >>> 27b17e530efdb23269e95968R1132 >>> >>> Thanks, >>> Mike >>> >>> [1] https://issues.apache.org/jira/browse/NIFI-4037 >>> [2] https://issues.apache.org/jira/browse/NIFI-4038 >>> >> >>
