I do believe we are in good shape.  I too was curious about npm and such
when it started but was extremely happy to see all the updates to the
assembly license to account for the pulled in js and css.

Based on your note I reviewed it again today in detail and it was looking
good.

If you find something please do fire up a jira.  Getting the licensing
right is definitely important.

On Jul 16, 2016 5:12 PM, "Joe Skora" <[email protected]> wrote:

>

> Joe,
>
> Thank you for summarizing so clearly.  I read the NiFi guide a few months
> back, but obviously need to go through it again.
>
> If I understand correctly, it looks like there are no license concerns.
>
> Thanks,
> Joe
>
>
> On Sat, Jul 16, 2016 at 1:23 PM, Joe Witt <[email protected]> wrote:
>
> > Generally speaking:
> >
> > [source]
> > There are many source elements that go into our source release.  All
> > of those must be appropriately licensed and based on our compatible
> > with the ASLv2 License which generally is consider as those items
> > listed as [1].
> >
> > [build process]
> > There are package managers involved in the build process including
> > things like Maven, NPM, Bower, and perhaps others.  There are also
> > other things used to conduct the build.  Those things need to be
> > appropriately licensed for us to use.  I'm not aware of anything we're
> > using that is problematic.
> >
> > [binary artifacts]
> > There are numerous binary artifacts produced as a result of our build
> > process.  All of those artifacts need to be appropriately licensed and
> > compatible with ASLv2 which includes those category-a items listed
> > above and also binary artifacts which satisfy the category-b handling
> > mentioned here [2].
> >
> > So the net of this is that our source LICENSE/NOTICE [1,2] must
> > account for all things in our source release.  Our binary artifact
> > LICENSE/NOTICE [3,4] must account for things in our binary convenience
> > bundles/artifacts.
> >
> > Much more of this is described and articulated on various ASF pages.
> > For the NiFi project itself though we have this document to help root
> > that guidance in our processes that we have thus far [5].
> >
> > [1] http://www.apache.org/legal/resolved.html#category-a
> > [2] http://www.apache.org/legal/resolved.html#category-a
> > [3] https://github.com/apache/nifi/blob/master/LICENSE
> > [4] https://github.com/apache/nifi/blob/master/NOTICE
> > [5] https://github.com/apache/nifi/blob/master/nifi-assembly/LICENSE
> > [6] https://github.com/apache/nifi/blob/master/nifi-assembly/NOTICE
> > [7] https://nifi.apache.org/licensing-guide.html
> >
> > Thanks
> > Joe
> >
> > On Sat, Jul 16, 2016 at 12:58 PM, Joe Skora <[email protected]> wrote:
> > > I'm somewhat ignorant regarding of the front-end wiring, when a NiFi
> > > instance runs does it use NodeJS, NPM, Bower, etc. or are those only
used
> > > during the build?
> > >
> > > If they are only used during the build, how does that affect the
Apache
> > > licensing, do they need to have Apache compatible licenses like a Java
> > > library does?
> > >
> > > On Fri, Jul 15, 2016 at 7:52 PM, Joe Witt <[email protected]> wrote:
> > >
> > >> Wow i reread the first paragraph I wrote and well...yowza hopefully
> > >> you can tell what I meant to say.
> > >>
> > >> Also wanted to add that when I started seeing those things show up in
> > >> the build i too did a double take and started looking into the
> > >> licensing.  So it is very right to bring these up.  Taking this line
> > >> of thought further i've also been concerned about things like
> > >> stylesheets or fonts that are referenced against websites that get
> > >> looked up by the client browser at runtime.  Definitely tradeoffs to
> > >> consider.
> > >>
> > >> Anyway, I'll take another look too but if you find specific artifacts
> > >> that are problematic in the resulting build please do share.
> > >>
> > >> Thanks
> > >> Joe
> > >>
> > >> On Fri, Jul 15, 2016 at 5:39 PM, Joe Witt <[email protected]> wrote:
> > >> > Joe,
> > >> >
> > >> > Now is certainly the time to address any concerns like this so no
> > >> > worries if false.
> > >> >
> > >> > For item #1)
> > >> > The source release cannot have any binaries.  A convenience binary
> > >> > build generally is comprised on producing binary artifacts and
linking
> > >> > them with dependent artifacts much like happens as maven pulls in
> > >> > dependencies.  Officially apache projects only do source releases.
> > >> > The binary convenience artifacts some projects, like ours, provide
is
> > >> > truly just a convenience.  We must take care to ensure that the
> > >> > resulting items are properly licensed and such but the official
> > >> > 'release' is the source code only.
> > >> >
> > >> > For item #2)
> > >> > The tools used to conduct the build are not necessary to call out
nor
> > >> > are dependencies like test dependencies, for example.  The
resulting
> > >> > artifacts in our binary build do need to be accounted for though
and
> > >> > yes they do need to be ASLv2 compatible.  The LICENSE/NOTICE within
> > >> > nifi-assembly is where the appropriate LICENSE/NOTICE lives for
such
> > >> > things.  Are there any specific artifacts being pulled in that
you're
> > >> > finding problematic?  We should definitely get those identified and
> > >> > addressed.
> > >> >
> > >> > Thanks
> > >> > Joe
> > >> >
> > >> > On Fri, Jul 15, 2016 at 5:25 PM, Joe Skora <[email protected]>
wrote:
> > >> >> Dear devs,
> > >> >>
> > >> >> I've looking into the 1.0.0 build processes and I noticed a couple
> > >> things
> > >> >> that I don't understand.
> > >> >>
> > >> >> 1. During the build, nifi-web-ui (and another modules) use NodeJS.
> > This
> > >> >> entails the "frontend-maven-plugin" actually downloading and
> > executing
> > >> >> binary code.  That's not something I'd normally expect in a Maven
> > build,
> > >> >> especially when the downloads do not come from repositories
> > referenced
> > >> in
> > >> >> the NiFi build configuration.
> > >> >>
> > >> >>      Is installing a foreign binary and executing it during a
build a
> > >> >> problem under Apache?
> > >> >>
> > >> >> 2. The build uses NodeJS, NPM, and Bower (maybe more) but I cannot
> > find
> > >> any
> > >> >> references to those tools in the license files.  Node appears to
have
> > >> it's
> > >> >> own license, with a good bit of stuff rolled in as well.  If the
> > >> relevant
> > >> >> licenses are not Apache compatible this could be a problem.
> > >> >>
> > >> >>      Are there any license whisperers who can look at how these
need
> > to
> > >> be
> > >> >> reconciled?
> > >> >>
> > >> >> Sorry if I'm sounding false alarms, but this caught me off
guard.  I
> > >> >> apologize if missed a prior discussion of this on the dev list.
> > >> >>
> > >> >> Regards,
> > >> >> Joe
> > >>
> >

Reply via email to