You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nifi.apache.org by Michael Hogue <mi...@gmail.com> on 2017/06/28 02:16:17 UTC
NiFi Assembly NOTICE/LICENSE Maintenance
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-c3a3e6d027b17e530efdb23269e95968R1132
Thanks,
Mike
[1] https://issues.apache.org/jira/browse/NIFI-4037
[2] https://issues.apache.org/jira/browse/NIFI-4038
Re: NiFi Assembly NOTICE/LICENSE Maintenance
Posted by 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
> >> > > > >>>
> >> > > > >>
> >> > > > >>
> >> > > >
> >> > >
> >> >
> >>
>
Re: NiFi Assembly NOTICE/LICENSE Maintenance
Posted by Joe Witt <jo...@gmail.com>.
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 <mi...@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
>> > > > >>>
>> > > > >>
>> > > > >>
>> > > >
>> > >
>> >
>>
Re: NiFi Assembly NOTICE/LICENSE Maintenance
Posted by Tony Kurc <tr...@gmail.com>.
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 <mi...@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
> > > > >>>
> > > > >>
> > > > >>
> > > >
> > >
> >
>
Re: NiFi Assembly NOTICE/LICENSE Maintenance
Posted by Michael Hogue <mi...@gmail.com>.
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
> > > >>>
> > > >>
> > > >>
> > >
> >
>
Re: NiFi Assembly NOTICE/LICENSE Maintenance
Posted by Mike Hogue <ho...@gmail.com>.
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
> > >>>
> > >>
> > >>
> >
>
Re: NiFi Assembly NOTICE/LICENSE Maintenance
Posted by Tony Kurc <tr...@gmail.com>.
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
> >>>
> >>
> >>
>
Re: NiFi Assembly NOTICE/LICENSE Maintenance
Posted by Joe Witt <jo...@gmail.com>.
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 <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
>>>
>>
>>
Re: NiFi Assembly NOTICE/LICENSE Maintenance
Posted by Tony Kurc <tr...@gmail.com>.
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
>>
>
>
Re: NiFi Assembly NOTICE/LICENSE Maintenance
Posted by Tony Kurc <tr...@gmail.com>.
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-
> c3a3e6d027b17e530efdb23269e95968R1132
>
> Thanks,
> Mike
>
> [1] https://issues.apache.org/jira/browse/NIFI-4037
> [2] https://issues.apache.org/jira/browse/NIFI-4038
>