nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Wing <jvw...@gmail.com>
Subject Re: Quick question on LICENSE/NOTICE when bundling controllers and processors
Date Mon, 27 Feb 2017 21:31:16 GMT
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 <aldrinpiri@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 <andre-lists@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
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message