You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nifi.apache.org by Andre <an...@fucs.org> on 2017/02/26 01:12:22 UTC
Quick question on LICENSE/NOTICE when bundling controllers and processors
Hi there,
Quick question on proper licensing:
When bundling Processors, Services and APIs, where should the NOTICES and
LICENSES be added to?
The PR in question is https://github.com/apache/nifi/pull/1541
My current reading is that all NAR levels will have to include the proper
references (although I may reduce a bit of the dependencies by excluding
some of the deeper dependencies, specially at the
nifi-irc-client-service-api-nar ).
Would you agree?
Cheers
Re: Quick question on LICENSE/NOTICE when bundling controllers and processors
Posted by James Wing <jv...@gmail.com>.
It may already be in the Licensing Guide (
https://nifi.apache.org/licensing-guide.html). I'll have to read it again
to identify net-new material. I'll open a PR if there is.
Thanks,
James
On Mon, Feb 27, 2017 at 4:23 PM, Tony Kurc <tr...@gmail.com> wrote:
> Joe,
> This is awesome and useful - should this guidance go on the wiki somewhere?
>
> On Mon, Feb 27, 2017 at 4:59 PM, Joe Witt <jo...@gmail.com> wrote:
>
> > 1) All nars once built do need to contain a LICENSE and NOTICE file
> > to cover what ends up in them as an archive of binary dependencies and
> > also it should cover any specific source dependencies they might have
> > (like MIT javascript libs in nifi-web-ui).
> >
> > 2) We need a LICENSE/NOTICE in every nar. A LICENSE and/or NOTICE
> > will be auto generated if not already present anyway. What we need
> > them to cover is mentioned in #1.
> >
> > Also, for any source or binary dependency in a given nar we must also
> > ensure all source dependencies are captured appropriately in the top
> > level nifi.git/LICENSE & NOTICE and any source & binary dependencies
> > are captured in the nifi.git/nifi-assembly/LICENSE and NOTICE.
> >
> > As we progress toward separating the application from the nars by way
> > of some extension registry we'll be able to have a far smaller/simple
> > LICENSE and NOTICE at the top level but the above nar L&N
> > considerations will still apply per L&N.
> >
> > Does that help at all James?
> >
> > On Mon, Feb 27, 2017 at 4:31 PM, James Wing <jv...@gmail.com> wrote:
> > > Thank you both for bringing up this discussion. I have a few follow-up
> > > questions:
> > >
> > > 1.) Is it true all of the NAR bundles in the NiFi source should have
> > their
> > > own LICENSE and NOTICE files, without exception? In looking through
> the
> > > source, most nifi-*-nar projects have both files for binary
> dependencies.
> > > I understand these binary dependencies should roll up to nifi-assembly
> > > LICENSE/NOTICE.
> > >
> > > 2.) Is it true we do not need source LICENSE/NOTICE for nar bundle
> > projects
> > > unless they have distinctive source dependency terms that roll up to
> the
> > > root LICENSE/NOTICE? nifi-web-ui is the only example I've found so
> > far. I
> > > assume the ASLv2 file headers cover most of the source.
> > >
> > > 3.) Where dependencies also distinguish between their source
> > LICENSE/NOTICE
> > > and binary LICENSE/NOTICE, should we match to our dependency
> > relationship?
> > > For example, a binary dependency would result in the inclusion of the
> > > binary NOTICE terms?
> > >
> > >
> > > Thanks,
> > >
> > > James
> > >
> > > On Sat, Feb 25, 2017 at 7:33 PM, Aldrin Piri <al...@gmail.com>
> > wrote:
> > >
> > >> Hey Andre,
> > >>
> > >> I may be off, but to help you along, I will give you my take on things
> > to
> > >> the best of my understanding. If there are any wrong points, I hope
> > >> someone can further clarify.
> > >>
> > >> For your case, it looks like simply you are simply using binary
> > >> dependencies. For that case, you have to consider where these items
> are
> > >> showing up and how they are released. Your inclusion of a dependency
> > will
> > >> affect the generated NAR (nifi-irc-processors-nar) and, while it seems
> > to
> > >> be missing in the current PR, the zip and tgz nifi-assembly artifacts.
> > You
> > >> shouldn't need to include it in levels lower than this assuming you
> are
> > >> talking about JARs that compose the overall NAR. While you are
> linking
> > >> these against dependencies, you are not explicitly bringing them into
> > the
> > >> project through the JARs incorporated in the NAR.
> > >>
> > >> Source inclusions are handled similarly but do go a level deeper as
> they
> > >> are also bundled with the JARs and are present in the root LICENSE and
> > >> NOTICE where applicable. Again, both are for similar reasons with the
> > >> generated source package and JARs bundling this work including the
> > source.
> > >>
> > >> Do keep in mind the transitive dependencies. Looking quickly through
> > the
> > >> pom for kitteh, I see usage of some netty libraries as well as
> > mbassador.
> > >> These would presumably also be collected upon building the NAR.
> > >>
> > >> Of course, the docs we have on the site are quite nice if you need
> some
> > >> light reading material ;) https://nifi.apache.org/
> licensing-guide.html
> > >> Both the guide and the links from it are good information and a nice
> > >> reference to revisit when working through these things.
> > >>
> > >> Let us know if there are additional questions or if some additional
> > >> clarification is needed. Hopefully my anecdotal thoughts are both
> > somewhat
> > >> helpful and mostly correct!
> > >>
> > >> On Sat, Feb 25, 2017 at 9:39 PM, Afonso Murakami <
> murakami19@icloud.com
> > >
> > >> wrote:
> > >>
> > >> > I just start and I really don’t know much so let see what I can
> learn
> > >> when
> > >> > time pass by and hope I can learn as much as you, thank’s
> > >> > > On Feb 25, 2017, at 5:12 PM, Andre <an...@fucs.org> wrote:
> > >> > >
> > >> > > Hi there,
> > >> > >
> > >> > > Quick question on proper licensing:
> > >> > >
> > >> > > When bundling Processors, Services and APIs, where should the
> > NOTICES
> > >> and
> > >> > > LICENSES be added to?
> > >> > >
> > >> > > The PR in question is https://github.com/apache/nifi/pull/1541
> > >> > >
> > >> > > My current reading is that all NAR levels will have to include the
> > >> proper
> > >> > > references (although I may reduce a bit of the dependencies by
> > >> excluding
> > >> > > some of the deeper dependencies, specially at the
> > >> > > nifi-irc-client-service-api-nar ).
> > >> > >
> > >> > > Would you agree?
> > >> > >
> > >> > > Cheers
> > >> >
> > >> >
> > >>
> >
>
Re: Quick question on LICENSE/NOTICE when bundling controllers and processors
Posted by Tony Kurc <tr...@gmail.com>.
Joe,
This is awesome and useful - should this guidance go on the wiki somewhere?
On Mon, Feb 27, 2017 at 4:59 PM, Joe Witt <jo...@gmail.com> wrote:
> 1) All nars once built do need to contain a LICENSE and NOTICE file
> to cover what ends up in them as an archive of binary dependencies and
> also it should cover any specific source dependencies they might have
> (like MIT javascript libs in nifi-web-ui).
>
> 2) We need a LICENSE/NOTICE in every nar. A LICENSE and/or NOTICE
> will be auto generated if not already present anyway. What we need
> them to cover is mentioned in #1.
>
> Also, for any source or binary dependency in a given nar we must also
> ensure all source dependencies are captured appropriately in the top
> level nifi.git/LICENSE & NOTICE and any source & binary dependencies
> are captured in the nifi.git/nifi-assembly/LICENSE and NOTICE.
>
> As we progress toward separating the application from the nars by way
> of some extension registry we'll be able to have a far smaller/simple
> LICENSE and NOTICE at the top level but the above nar L&N
> considerations will still apply per L&N.
>
> Does that help at all James?
>
> On Mon, Feb 27, 2017 at 4:31 PM, James Wing <jv...@gmail.com> wrote:
> > Thank you both for bringing up this discussion. I have a few follow-up
> > questions:
> >
> > 1.) Is it true all of the NAR bundles in the NiFi source should have
> their
> > own LICENSE and NOTICE files, without exception? In looking through the
> > source, most nifi-*-nar projects have both files for binary dependencies.
> > I understand these binary dependencies should roll up to nifi-assembly
> > LICENSE/NOTICE.
> >
> > 2.) Is it true we do not need source LICENSE/NOTICE for nar bundle
> projects
> > unless they have distinctive source dependency terms that roll up to the
> > root LICENSE/NOTICE? nifi-web-ui is the only example I've found so
> far. I
> > assume the ASLv2 file headers cover most of the source.
> >
> > 3.) Where dependencies also distinguish between their source
> LICENSE/NOTICE
> > and binary LICENSE/NOTICE, should we match to our dependency
> relationship?
> > For example, a binary dependency would result in the inclusion of the
> > binary NOTICE terms?
> >
> >
> > Thanks,
> >
> > James
> >
> > On Sat, Feb 25, 2017 at 7:33 PM, Aldrin Piri <al...@gmail.com>
> wrote:
> >
> >> Hey Andre,
> >>
> >> I may be off, but to help you along, I will give you my take on things
> to
> >> the best of my understanding. If there are any wrong points, I hope
> >> someone can further clarify.
> >>
> >> For your case, it looks like simply you are simply using binary
> >> dependencies. For that case, you have to consider where these items are
> >> showing up and how they are released. Your inclusion of a dependency
> will
> >> affect the generated NAR (nifi-irc-processors-nar) and, while it seems
> to
> >> be missing in the current PR, the zip and tgz nifi-assembly artifacts.
> You
> >> shouldn't need to include it in levels lower than this assuming you are
> >> talking about JARs that compose the overall NAR. While you are linking
> >> these against dependencies, you are not explicitly bringing them into
> the
> >> project through the JARs incorporated in the NAR.
> >>
> >> Source inclusions are handled similarly but do go a level deeper as they
> >> are also bundled with the JARs and are present in the root LICENSE and
> >> NOTICE where applicable. Again, both are for similar reasons with the
> >> generated source package and JARs bundling this work including the
> source.
> >>
> >> Do keep in mind the transitive dependencies. Looking quickly through
> the
> >> pom for kitteh, I see usage of some netty libraries as well as
> mbassador.
> >> These would presumably also be collected upon building the NAR.
> >>
> >> Of course, the docs we have on the site are quite nice if you need some
> >> light reading material ;) https://nifi.apache.org/licensing-guide.html
> >> Both the guide and the links from it are good information and a nice
> >> reference to revisit when working through these things.
> >>
> >> Let us know if there are additional questions or if some additional
> >> clarification is needed. Hopefully my anecdotal thoughts are both
> somewhat
> >> helpful and mostly correct!
> >>
> >> On Sat, Feb 25, 2017 at 9:39 PM, Afonso Murakami <murakami19@icloud.com
> >
> >> wrote:
> >>
> >> > I just start and I really don’t know much so let see what I can learn
> >> when
> >> > time pass by and hope I can learn as much as you, thank’s
> >> > > On Feb 25, 2017, at 5:12 PM, Andre <an...@fucs.org> wrote:
> >> > >
> >> > > Hi there,
> >> > >
> >> > > Quick question on proper licensing:
> >> > >
> >> > > When bundling Processors, Services and APIs, where should the
> NOTICES
> >> and
> >> > > LICENSES be added to?
> >> > >
> >> > > The PR in question is https://github.com/apache/nifi/pull/1541
> >> > >
> >> > > My current reading is that all NAR levels will have to include the
> >> proper
> >> > > references (although I may reduce a bit of the dependencies by
> >> excluding
> >> > > some of the deeper dependencies, specially at the
> >> > > nifi-irc-client-service-api-nar ).
> >> > >
> >> > > Would you agree?
> >> > >
> >> > > Cheers
> >> >
> >> >
> >>
>
Re: Quick question on LICENSE/NOTICE when bundling controllers and processors
Posted by James Wing <jv...@gmail.com>.
Yes, thank you, that does help. I'm slowly sneaking up on an understanding
of how it works.
James
On Mon, Feb 27, 2017 at 1:59 PM, Joe Witt <jo...@gmail.com> wrote:
> 1) All nars once built do need to contain a LICENSE and NOTICE file
> to cover what ends up in them as an archive of binary dependencies and
> also it should cover any specific source dependencies they might have
> (like MIT javascript libs in nifi-web-ui).
>
> 2) We need a LICENSE/NOTICE in every nar. A LICENSE and/or NOTICE
> will be auto generated if not already present anyway. What we need
> them to cover is mentioned in #1.
>
> Also, for any source or binary dependency in a given nar we must also
> ensure all source dependencies are captured appropriately in the top
> level nifi.git/LICENSE & NOTICE and any source & binary dependencies
> are captured in the nifi.git/nifi-assembly/LICENSE and NOTICE.
>
> As we progress toward separating the application from the nars by way
> of some extension registry we'll be able to have a far smaller/simple
> LICENSE and NOTICE at the top level but the above nar L&N
> considerations will still apply per L&N.
>
> Does that help at all James?
>
> On Mon, Feb 27, 2017 at 4:31 PM, James Wing <jv...@gmail.com> wrote:
> > Thank you both for bringing up this discussion. I have a few follow-up
> > questions:
> >
> > 1.) Is it true all of the NAR bundles in the NiFi source should have
> their
> > own LICENSE and NOTICE files, without exception? In looking through the
> > source, most nifi-*-nar projects have both files for binary dependencies.
> > I understand these binary dependencies should roll up to nifi-assembly
> > LICENSE/NOTICE.
> >
> > 2.) Is it true we do not need source LICENSE/NOTICE for nar bundle
> projects
> > unless they have distinctive source dependency terms that roll up to the
> > root LICENSE/NOTICE? nifi-web-ui is the only example I've found so
> far. I
> > assume the ASLv2 file headers cover most of the source.
> >
> > 3.) Where dependencies also distinguish between their source
> LICENSE/NOTICE
> > and binary LICENSE/NOTICE, should we match to our dependency
> relationship?
> > For example, a binary dependency would result in the inclusion of the
> > binary NOTICE terms?
> >
> >
> > Thanks,
> >
> > James
> >
> > On Sat, Feb 25, 2017 at 7:33 PM, Aldrin Piri <al...@gmail.com>
> wrote:
> >
> >> Hey Andre,
> >>
> >> I may be off, but to help you along, I will give you my take on things
> to
> >> the best of my understanding. If there are any wrong points, I hope
> >> someone can further clarify.
> >>
> >> For your case, it looks like simply you are simply using binary
> >> dependencies. For that case, you have to consider where these items are
> >> showing up and how they are released. Your inclusion of a dependency
> will
> >> affect the generated NAR (nifi-irc-processors-nar) and, while it seems
> to
> >> be missing in the current PR, the zip and tgz nifi-assembly artifacts.
> You
> >> shouldn't need to include it in levels lower than this assuming you are
> >> talking about JARs that compose the overall NAR. While you are linking
> >> these against dependencies, you are not explicitly bringing them into
> the
> >> project through the JARs incorporated in the NAR.
> >>
> >> Source inclusions are handled similarly but do go a level deeper as they
> >> are also bundled with the JARs and are present in the root LICENSE and
> >> NOTICE where applicable. Again, both are for similar reasons with the
> >> generated source package and JARs bundling this work including the
> source.
> >>
> >> Do keep in mind the transitive dependencies. Looking quickly through
> the
> >> pom for kitteh, I see usage of some netty libraries as well as
> mbassador.
> >> These would presumably also be collected upon building the NAR.
> >>
> >> Of course, the docs we have on the site are quite nice if you need some
> >> light reading material ;) https://nifi.apache.org/licensing-guide.html
> >> Both the guide and the links from it are good information and a nice
> >> reference to revisit when working through these things.
> >>
> >> Let us know if there are additional questions or if some additional
> >> clarification is needed. Hopefully my anecdotal thoughts are both
> somewhat
> >> helpful and mostly correct!
> >>
> >> On Sat, Feb 25, 2017 at 9:39 PM, Afonso Murakami <murakami19@icloud.com
> >
> >> wrote:
> >>
> >> > I just start and I really don’t know much so let see what I can learn
> >> when
> >> > time pass by and hope I can learn as much as you, thank’s
> >> > > On Feb 25, 2017, at 5:12 PM, Andre <an...@fucs.org> wrote:
> >> > >
> >> > > Hi there,
> >> > >
> >> > > Quick question on proper licensing:
> >> > >
> >> > > When bundling Processors, Services and APIs, where should the
> NOTICES
> >> and
> >> > > LICENSES be added to?
> >> > >
> >> > > The PR in question is https://github.com/apache/nifi/pull/1541
> >> > >
> >> > > My current reading is that all NAR levels will have to include the
> >> proper
> >> > > references (although I may reduce a bit of the dependencies by
> >> excluding
> >> > > some of the deeper dependencies, specially at the
> >> > > nifi-irc-client-service-api-nar ).
> >> > >
> >> > > Would you agree?
> >> > >
> >> > > Cheers
> >> >
> >> >
> >>
>
Re: Quick question on LICENSE/NOTICE when bundling controllers and processors
Posted by Joe Witt <jo...@gmail.com>.
1) All nars once built do need to contain a LICENSE and NOTICE file
to cover what ends up in them as an archive of binary dependencies and
also it should cover any specific source dependencies they might have
(like MIT javascript libs in nifi-web-ui).
2) We need a LICENSE/NOTICE in every nar. A LICENSE and/or NOTICE
will be auto generated if not already present anyway. What we need
them to cover is mentioned in #1.
Also, for any source or binary dependency in a given nar we must also
ensure all source dependencies are captured appropriately in the top
level nifi.git/LICENSE & NOTICE and any source & binary dependencies
are captured in the nifi.git/nifi-assembly/LICENSE and NOTICE.
As we progress toward separating the application from the nars by way
of some extension registry we'll be able to have a far smaller/simple
LICENSE and NOTICE at the top level but the above nar L&N
considerations will still apply per L&N.
Does that help at all James?
On Mon, Feb 27, 2017 at 4:31 PM, James Wing <jv...@gmail.com> wrote:
> Thank you both for bringing up this discussion. I have a few follow-up
> questions:
>
> 1.) Is it true all of the NAR bundles in the NiFi source should have their
> own LICENSE and NOTICE files, without exception? In looking through the
> source, most nifi-*-nar projects have both files for binary dependencies.
> I understand these binary dependencies should roll up to nifi-assembly
> LICENSE/NOTICE.
>
> 2.) Is it true we do not need source LICENSE/NOTICE for nar bundle projects
> unless they have distinctive source dependency terms that roll up to the
> root LICENSE/NOTICE? nifi-web-ui is the only example I've found so far. I
> assume the ASLv2 file headers cover most of the source.
>
> 3.) Where dependencies also distinguish between their source LICENSE/NOTICE
> and binary LICENSE/NOTICE, should we match to our dependency relationship?
> For example, a binary dependency would result in the inclusion of the
> binary NOTICE terms?
>
>
> Thanks,
>
> James
>
> On Sat, Feb 25, 2017 at 7:33 PM, Aldrin Piri <al...@gmail.com> wrote:
>
>> Hey Andre,
>>
>> I may be off, but to help you along, I will give you my take on things to
>> the best of my understanding. If there are any wrong points, I hope
>> someone can further clarify.
>>
>> For your case, it looks like simply you are simply using binary
>> dependencies. For that case, you have to consider where these items are
>> showing up and how they are released. Your inclusion of a dependency will
>> affect the generated NAR (nifi-irc-processors-nar) and, while it seems to
>> be missing in the current PR, the zip and tgz nifi-assembly artifacts. You
>> shouldn't need to include it in levels lower than this assuming you are
>> talking about JARs that compose the overall NAR. While you are linking
>> these against dependencies, you are not explicitly bringing them into the
>> project through the JARs incorporated in the NAR.
>>
>> Source inclusions are handled similarly but do go a level deeper as they
>> are also bundled with the JARs and are present in the root LICENSE and
>> NOTICE where applicable. Again, both are for similar reasons with the
>> generated source package and JARs bundling this work including the source.
>>
>> Do keep in mind the transitive dependencies. Looking quickly through the
>> pom for kitteh, I see usage of some netty libraries as well as mbassador.
>> These would presumably also be collected upon building the NAR.
>>
>> Of course, the docs we have on the site are quite nice if you need some
>> light reading material ;) https://nifi.apache.org/licensing-guide.html
>> Both the guide and the links from it are good information and a nice
>> reference to revisit when working through these things.
>>
>> Let us know if there are additional questions or if some additional
>> clarification is needed. Hopefully my anecdotal thoughts are both somewhat
>> helpful and mostly correct!
>>
>> On Sat, Feb 25, 2017 at 9:39 PM, Afonso Murakami <mu...@icloud.com>
>> wrote:
>>
>> > I just start and I really don’t know much so let see what I can learn
>> when
>> > time pass by and hope I can learn as much as you, thank’s
>> > > On Feb 25, 2017, at 5:12 PM, Andre <an...@fucs.org> wrote:
>> > >
>> > > Hi there,
>> > >
>> > > Quick question on proper licensing:
>> > >
>> > > When bundling Processors, Services and APIs, where should the NOTICES
>> and
>> > > LICENSES be added to?
>> > >
>> > > The PR in question is https://github.com/apache/nifi/pull/1541
>> > >
>> > > My current reading is that all NAR levels will have to include the
>> proper
>> > > references (although I may reduce a bit of the dependencies by
>> excluding
>> > > some of the deeper dependencies, specially at the
>> > > nifi-irc-client-service-api-nar ).
>> > >
>> > > Would you agree?
>> > >
>> > > Cheers
>> >
>> >
>>
Re: Quick question on LICENSE/NOTICE when bundling controllers and processors
Posted by James Wing <jv...@gmail.com>.
Thank you both for bringing up this discussion. I have a few follow-up
questions:
1.) Is it true all of the NAR bundles in the NiFi source should have their
own LICENSE and NOTICE files, without exception? In looking through the
source, most nifi-*-nar projects have both files for binary dependencies.
I understand these binary dependencies should roll up to nifi-assembly
LICENSE/NOTICE.
2.) Is it true we do not need source LICENSE/NOTICE for nar bundle projects
unless they have distinctive source dependency terms that roll up to the
root LICENSE/NOTICE? nifi-web-ui is the only example I've found so far. I
assume the ASLv2 file headers cover most of the source.
3.) Where dependencies also distinguish between their source LICENSE/NOTICE
and binary LICENSE/NOTICE, should we match to our dependency relationship?
For example, a binary dependency would result in the inclusion of the
binary NOTICE terms?
Thanks,
James
On Sat, Feb 25, 2017 at 7:33 PM, Aldrin Piri <al...@gmail.com> wrote:
> Hey Andre,
>
> I may be off, but to help you along, I will give you my take on things to
> the best of my understanding. If there are any wrong points, I hope
> someone can further clarify.
>
> For your case, it looks like simply you are simply using binary
> dependencies. For that case, you have to consider where these items are
> showing up and how they are released. Your inclusion of a dependency will
> affect the generated NAR (nifi-irc-processors-nar) and, while it seems to
> be missing in the current PR, the zip and tgz nifi-assembly artifacts. You
> shouldn't need to include it in levels lower than this assuming you are
> talking about JARs that compose the overall NAR. While you are linking
> these against dependencies, you are not explicitly bringing them into the
> project through the JARs incorporated in the NAR.
>
> Source inclusions are handled similarly but do go a level deeper as they
> are also bundled with the JARs and are present in the root LICENSE and
> NOTICE where applicable. Again, both are for similar reasons with the
> generated source package and JARs bundling this work including the source.
>
> Do keep in mind the transitive dependencies. Looking quickly through the
> pom for kitteh, I see usage of some netty libraries as well as mbassador.
> These would presumably also be collected upon building the NAR.
>
> Of course, the docs we have on the site are quite nice if you need some
> light reading material ;) https://nifi.apache.org/licensing-guide.html
> Both the guide and the links from it are good information and a nice
> reference to revisit when working through these things.
>
> Let us know if there are additional questions or if some additional
> clarification is needed. Hopefully my anecdotal thoughts are both somewhat
> helpful and mostly correct!
>
> On Sat, Feb 25, 2017 at 9:39 PM, Afonso Murakami <mu...@icloud.com>
> wrote:
>
> > I just start and I really don’t know much so let see what I can learn
> when
> > time pass by and hope I can learn as much as you, thank’s
> > > On Feb 25, 2017, at 5:12 PM, Andre <an...@fucs.org> wrote:
> > >
> > > Hi there,
> > >
> > > Quick question on proper licensing:
> > >
> > > When bundling Processors, Services and APIs, where should the NOTICES
> and
> > > LICENSES be added to?
> > >
> > > The PR in question is https://github.com/apache/nifi/pull/1541
> > >
> > > My current reading is that all NAR levels will have to include the
> proper
> > > references (although I may reduce a bit of the dependencies by
> excluding
> > > some of the deeper dependencies, specially at the
> > > nifi-irc-client-service-api-nar ).
> > >
> > > Would you agree?
> > >
> > > Cheers
> >
> >
>
Re: Quick question on LICENSE/NOTICE when bundling controllers and
processors
Posted by Afonso Murakami <mu...@icloud.com>.
Thank you for reply so quick I just start and really do not know exactly what I’m doing and I need a lot’s material to read and reference so I can understand better what I’m doing it again thank’s for the email.
> On Feb 25, 2017, at 7:33 PM, Aldrin Piri <al...@gmail.com> wrote:
>
> Hey Andre,
>
> I may be off, but to help you along, I will give you my take on things to
> the best of my understanding. If there are any wrong points, I hope
> someone can further clarify.
>
> For your case, it looks like simply you are simply using binary
> dependencies. For that case, you have to consider where these items are
> showing up and how they are released. Your inclusion of a dependency will
> affect the generated NAR (nifi-irc-processors-nar) and, while it seems to
> be missing in the current PR, the zip and tgz nifi-assembly artifacts. You
> shouldn't need to include it in levels lower than this assuming you are
> talking about JARs that compose the overall NAR. While you are linking
> these against dependencies, you are not explicitly bringing them into the
> project through the JARs incorporated in the NAR.
>
> Source inclusions are handled similarly but do go a level deeper as they
> are also bundled with the JARs and are present in the root LICENSE and
> NOTICE where applicable. Again, both are for similar reasons with the
> generated source package and JARs bundling this work including the source.
>
> Do keep in mind the transitive dependencies. Looking quickly through the
> pom for kitteh, I see usage of some netty libraries as well as mbassador.
> These would presumably also be collected upon building the NAR.
>
> Of course, the docs we have on the site are quite nice if you need some
> light reading material ;) https://nifi.apache.org/licensing-guide.html
> Both the guide and the links from it are good information and a nice
> reference to revisit when working through these things.
>
> Let us know if there are additional questions or if some additional
> clarification is needed. Hopefully my anecdotal thoughts are both somewhat
> helpful and mostly correct!
>
> On Sat, Feb 25, 2017 at 9:39 PM, Afonso Murakami <mu...@icloud.com>
> wrote:
>
>> I just start and I really don’t know much so let see what I can learn when
>> time pass by and hope I can learn as much as you, thank’s
>>> On Feb 25, 2017, at 5:12 PM, Andre <an...@fucs.org> wrote:
>>>
>>> Hi there,
>>>
>>> Quick question on proper licensing:
>>>
>>> When bundling Processors, Services and APIs, where should the NOTICES and
>>> LICENSES be added to?
>>>
>>> The PR in question is https://github.com/apache/nifi/pull/1541
>>>
>>> My current reading is that all NAR levels will have to include the proper
>>> references (although I may reduce a bit of the dependencies by excluding
>>> some of the deeper dependencies, specially at the
>>> nifi-irc-client-service-api-nar ).
>>>
>>> Would you agree?
>>>
>>> Cheers
>>
>>
Re: Quick question on LICENSE/NOTICE when bundling controllers and processors
Posted by Aldrin Piri <al...@gmail.com>.
Hey Andre,
I may be off, but to help you along, I will give you my take on things to
the best of my understanding. If there are any wrong points, I hope
someone can further clarify.
For your case, it looks like simply you are simply using binary
dependencies. For that case, you have to consider where these items are
showing up and how they are released. Your inclusion of a dependency will
affect the generated NAR (nifi-irc-processors-nar) and, while it seems to
be missing in the current PR, the zip and tgz nifi-assembly artifacts. You
shouldn't need to include it in levels lower than this assuming you are
talking about JARs that compose the overall NAR. While you are linking
these against dependencies, you are not explicitly bringing them into the
project through the JARs incorporated in the NAR.
Source inclusions are handled similarly but do go a level deeper as they
are also bundled with the JARs and are present in the root LICENSE and
NOTICE where applicable. Again, both are for similar reasons with the
generated source package and JARs bundling this work including the source.
Do keep in mind the transitive dependencies. Looking quickly through the
pom for kitteh, I see usage of some netty libraries as well as mbassador.
These would presumably also be collected upon building the NAR.
Of course, the docs we have on the site are quite nice if you need some
light reading material ;) https://nifi.apache.org/licensing-guide.html
Both the guide and the links from it are good information and a nice
reference to revisit when working through these things.
Let us know if there are additional questions or if some additional
clarification is needed. Hopefully my anecdotal thoughts are both somewhat
helpful and mostly correct!
On Sat, Feb 25, 2017 at 9:39 PM, Afonso Murakami <mu...@icloud.com>
wrote:
> I just start and I really don’t know much so let see what I can learn when
> time pass by and hope I can learn as much as you, thank’s
> > On Feb 25, 2017, at 5:12 PM, Andre <an...@fucs.org> wrote:
> >
> > Hi there,
> >
> > Quick question on proper licensing:
> >
> > When bundling Processors, Services and APIs, where should the NOTICES and
> > LICENSES be added to?
> >
> > The PR in question is https://github.com/apache/nifi/pull/1541
> >
> > My current reading is that all NAR levels will have to include the proper
> > references (although I may reduce a bit of the dependencies by excluding
> > some of the deeper dependencies, specially at the
> > nifi-irc-client-service-api-nar ).
> >
> > Would you agree?
> >
> > Cheers
>
>
Re: Quick question on LICENSE/NOTICE when bundling controllers and
processors
Posted by Afonso Murakami <mu...@icloud.com>.
I just start and I really don’t know much so let see what I can learn when time pass by and hope I can learn as much as you, thank’s
> On Feb 25, 2017, at 5:12 PM, Andre <an...@fucs.org> wrote:
>
> Hi there,
>
> Quick question on proper licensing:
>
> When bundling Processors, Services and APIs, where should the NOTICES and
> LICENSES be added to?
>
> The PR in question is https://github.com/apache/nifi/pull/1541
>
> My current reading is that all NAR levels will have to include the proper
> references (although I may reduce a bit of the dependencies by excluding
> some of the deeper dependencies, specially at the
> nifi-irc-client-service-api-nar ).
>
> Would you agree?
>
> Cheers