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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > > 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 < > [email protected] > > > > > >> 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 <[email protected]> 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 > > >> > > > >> > > > >> > > >
