Re: NiFi Assembly NOTICE/LICENSE Maintenance

[Michael Hogue <mi...@gmail.com>]

All,

   I've taken a first cut at synthesizing this discussion in the
contributor's guide [1]. I'd appreciate any and all scrutiny/edits.

Thanks,
Mike

[1]
https://cwiki.apache.org/confluence/display/NIFI/Contributor+Guide#ContributorGuide-UpdateLicensingDocumentation


On Wed, Jun 28, 2017 at 8:21 PM Joe Witt <jo...@gmail.com> wrote:

> Yes my wording for #2 was confusing.
>
> Yes for all things bundled in a given nar its license and notice
> should cover all things in that nar and further the assembly L&N
> should cover it too.  That is for binary dependencies.  If we have
> source dependencies/inclusions which we take as-is or modify then we
> need to document those in the top level nifi L&N.
>
> For netty as you showed in the two links we have it in there twice.
> The content in the NOTICE under the first link should be removed.
> Regarding the entries in the second link which cover the source and
> binary dependencies it is 'fine' as-is and probably isn't worth the
> extra effort of removing/editing their NOTICE text to only indicate
> items that we do in fact bundle.
>
> As far as general guidance for how to handle inclusion/reference to
> proper L&N for different versions of a given dependency with
> significantly different L&N information I agree that it would have two
> entries and each would just clearly indicate the version being
> described.
>
> Thanks
> Joe
>
> On Wed, Jun 28, 2017 at 8:06 PM, Tony Kurc <tr...@gmail.com> wrote:
> > Joe et al.,
> > I was helping Mike out of band on this and think we got a bit confused,
> > mainly I think because of the current nifi-assembly NOTICE and seemingly
> > including things that I think you said shouldn't be (per your 2nd point).
> >
> > Also, some of the phrasing you used was a little bit confusing and Mike
> and
> > I interpreted it differently. If a nar bundles something, and because the
> > assembly bundles the nar, I have been under the assumption that anything
> in
> > the nar NOTICE and LICENSE would need to be included in the assembly
> NOTICE
> > and LICENSE. I think you were saying this (and it is the case for this
> PR).
> >
> > What was confusing is that Netty is in the current assembly NOTICE in two
> > areas [1][2]. The latter appears to include things that are modified
> > versions [3] as well as things that are optionally depended on [4]. I
> think
> > that based on what you're saying is that the "optionally depends on",
> like
> > [4] on should maybe be removed and new ones shouldn't be included as Mike
> > brings in the new "contains a modified version" portions that come along
> > with the new NOTICE.
> >
> > Also, for what it is worth, Mike brought what I consider easy cases
> (google
> > protocol buffers being the same LICENSE text. the new Netty being a
> > superset of the old Netty), I was hoping what came out of the discussion
> is
> > what to do if two different versions of the same named dependency have
> > vastly different NOTICES. I'm pretty sure the right answer is to throw a
> > version on the dependency in the NOTICE (e.g. this line:
> >
> > (ASLv2) Apache Commons Net
> >
> > becomes:
> >
> > (ASLv2) Apache Commons Net (x.y.z)
> >
> > 1. https://github.com/apache/nifi/blame/master/nifi-assembly/NOTICE#L939
> > 2.
> https://github.com/apache/nifi/blame/master/nifi-assembly/NOTICE#L1117
> > 3.
> https://github.com/apache/nifi/blame/master/nifi-assembly/NOTICE#L1163
> > 4.
> https://github.com/apache/nifi/blame/master/nifi-assembly/NOTICE#L1179
> >
> >
> > On Wed, Jun 28, 2017 at 6:25 PM, Michael Hogue <
> michael.p.hogue89@gmail.com>
> > wrote:
> >
> >> Joe,
> >>
> >>    Thanks much for the detailed response. That's really helpful in
> >> determining what i should and shouldn't do w.r.t LICENSEs and NOTICEs.
> I'll
> >> capture this in the contributor guide as well.
> >>
> >> Thanks again,
> >> Mike
> >>
> >> On Wed, Jun 28, 2017 at 1:44 PM Mike Hogue <ho...@gmail.com> wrote:
> >>
> >> > Not a problem, assuming i'm able to edit the contributor's guide.
> >> >
> >> > On Wed, Jun 28, 2017 at 1:43 PM Tony Kurc <tr...@gmail.com> wrote:
> >> >
> >> > > Mike,
> >> > > while it is fresh in your head, any chance you have cycles to
> >> synthesize
> >> > > this and put this up on the contributor's guide?
> >> > >
> >> > > Tony
> >> > >
> >> > > On Wed, Jun 28, 2017 at 11:33 AM, Joe Witt <jo...@gmail.com>
> wrote:
> >> > >
> >> > > > 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/4b845b39f36ae38470017ea61b104d
> >> > > > 01310b8f16/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 <tr...@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 <tr...@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.hogue89@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
> >> > > > >>>
> >> > > > >>
> >> > > > >>
> >> > > >
> >> > >
> >> >
> >>
>