flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Hogan <c...@greghogan.com>
Subject Re: Web dashboard binaries and licensing
Date Fri, 01 Jul 2016 16:06:21 GMT
These external libraries will still be shipped in the binaries, which
complicates the issue since source and binary licenses must be tracked
separately.
  http://www.apache.org/dev/licensing-howto.html#binary

I do agree that this would be a nice improvement to the build system.

On Fri, Jul 1, 2016 at 11:16 AM, Maximilian Michels <mxm@apache.org> wrote:

> Ah, now I see that a compile-time dependency resolution would make
> sense. Then we don't have to check license compatibility for web
> dependencies which are downloaded during compile time and are not part
> of the source distribution.
>
> +1 Would be worth the effort to integrate this in our build system,
> e.g. via the proposed plugin.
>
> On Thu, Jun 30, 2016 at 2:48 PM, Till Rohrmann <trohrmann@apache.org>
> wrote:
> > Yes, that is also how I understood the Apache License requirements.
> Having
> > a mere dependency on some external library which is not shipped as part
> of
> > the source release does not require to include it in the LICENSE/NOTICE
> > file. I think that you only have to include a reference in the
> > LICENSE/NOTICE file, if your source release contains actual code which
> has
> > a copyright. With the vendor.js file, the latter case applies.
> >
> > I'm not a bower expert, so I cannot tell for sure which javascript files
> > end up in the vendor.js file. I would assume that they are the bower
> > dependencies defined in bower.json and their transitive dependencies. But
> > parsing the vendor.js file will not be feasible, since it contains 80000+
> > LOC.
> >
> > Thus my main concern, why I initiated this discussion, is the legal
> aspect
> > of including a monolithic file of javascript code in our code base. The
> > Flink community might release code which violates other people's
> copyright.
> >
> > Additionally, it might be worth the effort to harden our build system
> > anyway if you say that it's fragile. Then we could also properly
> integrate
> > the web-dashboard generation into the build process.
> >
> > On Thu, Jun 30, 2016 at 2:30 PM, Aljoscha Krettek <aljoscha@apache.org>
> > wrote:
> >
> >> AFAIK the Apache License requires that we have an entry in the
> >> LICENSE/NOTICE file for all external code that we ship with our source.
> If
> >> we have vendor.js in our source we have to include everything that is in
> >> there. If we don't have any actual external code in our source but only
> >> specified dependencies we should not be required to include them in the
> >> LICENSE/NOTICE file.
> >>
> >> On Thu, 30 Jun 2016 at 14:07 Maximilian Michels <mxm@apache.org> wrote:
> >>
> >> > I'm afraid I don't think integration in the Maven build process makes
> >> > a difference in terms of licensing. It is already clearly specified
> >> > what dependencies the web frontend uses (see README, bower.json,
> >> > package.json). It won't get any easier with something integrated in
> >> > the build process. We still have to leverage the Javascript build
> >> > systems which resolve transitive dependencies in the same way Maven
> >> > does. In the end, we just have to properly check out licenses which
> >> > takes time.
> >> >
> >> > In what sense do you think it would make licensing easier?
> >> >
> >> > On Thu, Jun 30, 2016 at 1:47 PM, Aljoscha Krettek <
> aljoscha@apache.org>
> >> > wrote:
> >> > > I think it's not a question of easy-of-use but one of licensing. I
> >> don't
> >> > > think anyone really knows what code ends up in vendor.js, so it is
> very
> >> > > hard to figure out what we have to put into our LICENSE file.
> >> > >
> >> > > On Thu, 30 Jun 2016 at 12:14 Maximilian Michels <mxm@apache.org>
> >> wrote:
> >> > >
> >> > >> Hi Till,
> >> > >>
> >> > >> Thanks for checking the licenses for our web frontend.
> >> > >>
> >> > >> I think the reason why we added a big binary Javascript blob into
> our
> >> > >> repository was that it was easiest for most developers to deal
> with.
> >> > >> We don't have much Javascript expertise in the Flink community.
> >> > >> Incorporating the web frontend in the build process would require
> some
> >> > >> additional work and make it even more complicated. It this sense
> the
> >> > >> solution we have currently is quite nice because it doesn't require
> >> > >> developers to fiddle around with Javascript as long as they are
not
> >> > >> working on the webfrontend. If they do, they can simply use NPM
and
> >> > >> Bower which install the listed dependencies. The disadvantage
is a
> >> > >> slight increase of our repository because we commit a new
> "vendor.js"
> >> > >> for every recompile, but that is negligible in my opinion.
> >> > >>
> >> > >> It would be cleaner to build the Javascript parts in the Maven
> build
> >> > >> process but it will complicate the build process further. Frankly,
> I
> >> > >> don't see it'll add much value. Considering the fragility of our
> build
> >> > >> system I might be a bit conservative here :)
> >> > >>
> >> > >> Cheers,
> >> > >> Max
> >> > >>
> >> > >> On Wed, Jun 29, 2016 at 5:17 PM, Till Rohrmann <
> trohrmann@apache.org>
> >> > >> wrote:
> >> > >> > Hi Flink community,
> >> > >> >
> >> > >> > while reviewing the LICENSE and NOTICE file of Apache Flink,
I
> >> noticed
> >> > >> that
> >> > >> > according to the LICENSE file Flink contains many java script
> files.
> >> > >> > However, tracking the corresponding files back was not so
easy,
> >> > because
> >> > >> > they are actually all merged into
> >> > >> > flink-runtime-web/web-dashboard/web/js/vendor.js. Vendor.js
is a
> >> large
> >> > >> java
> >> > >> > script file which is part of the result of the bower build
> process.
> >> > >> >
> >> > >> > I was wondering why we added a "binary" file which is
> auto-generated
> >> > to
> >> > >> our
> >> > >> > code base. Was/Is there any specific reason for it?
> >> > >> >
> >> > >> > The problem is that the java script files contained in the
> vendor.js
> >> > are
> >> > >> > not exactly the set of declared bower dependencies in
> >> > >> > flink-runtime-web/web-dashboard/bower.json. I suspect that
also
> >> > >> transitive
> >> > >> > dependencies will be included. At least that is my only
> explanation
> >> > why
> >> > >> > we're referencing lodash.js, for example, in our LICENSE
file
> (you
> >> can
> >> > >> find
> >> > >> > it deeply hidden in the vendor.js file).
> >> > >> >
> >> > >> > Wouldn't it be easier to auto-generate the web-dashboard
related
> >> files
> >> > >> > while building Flink? This would not only clean up our repository
> >> but
> >> > >> also
> >> > >> > make the traceability of contained 3rd party code in our
code
> base
> >> > much
> >> > >> > easier. Maybe this maven plugin [1] could help us.
> >> > >> >
> >> > >> > [1] https://github.com/eirslett/frontend-maven-plugin
> >> > >> >
> >> > >> > Cheers,
> >> > >> > Till
> >> > >>
> >> >
> >>
>

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