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 <aldrinp...@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 <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 5:12 PM, Andre <andre-li...@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 > > > > >
