Re: Quick question on LICENSE/NOTICE when bundling controllers and processors
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 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
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 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 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
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 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 > 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 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
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 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 > 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 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
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 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 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 >> 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 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
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 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 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 > 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 > > >> 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 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 > >> exc
Re: Quick question on LICENSE/NOTICE when bundling controllers and processors
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 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 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 > 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 > > >> 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 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 > >> > > som
Re: Quick question on LICENSE/NOTICE when bundling controllers and processors
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 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 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 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 > > 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 < > murakam...@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