zipkin-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <>
Subject [GitHub] [incubator-zipkin] adriancole commented on issue #2548: Sort out DEPENDENCIES file for zipkin-lens
Date Sun, 02 Jun 2019 14:57:13 GMT
adriancole commented on issue #2548: Sort out DEPENDENCIES file for zipkin-lens
   PS I don't know the nuance of what deps we need besides production. You are
   right that our UI doesn't work without fontawesome. maybe there are some
   additional labeling we can use to get "production" + "what we use that
   isn't in production" :D
   On Sun, Jun 2, 2019 at 10:53 PM Adrian Cole <> wrote:
   > I think you are missing the --production flag. all the prod dependencies
   > are straightforward when I checked.. ex RAT doesn't check the test tree iiuc
   > On Sun, Jun 2, 2019 at 8:33 PM Zoltán Nagy <>
   > wrote:
   >> NOTE: the normal maven thing doesn't check indirect dependencies, though
   >> npm-checker does..
   >> So... I guess the lazy thing is to use --direct to behave the same way
   >> as Rat. OTOH as long as all our transitive dependencies are A-OK, we can
   >> afford to be more strict.
   >> I've worked through licenses of our dependencies and compared to
   >> Things that stand out:
   >>    - CC-BY-3.0 and CC-BY-4.0: ASF says "Works under the Creative Commons
   >>    Attribution (CC-BY) licenses (2.5, 3.0, and 4.0) contain terms related to
   >>    "Effective Technological Measures", which may come as a surprise to users.
   >>    Thus their inclusion shall be appropriately labelled and only in binary
   >>    form."
   >>       - Packages: @fortawesome/fontawesome-free, spdx-exceptions,
   >>       caniuse-lite
   >>       - My take: I'm not clear on what "appropriately labelled" means.
   >>       For fontawesome, we're good on "only in binary form". The other two
   >>       packages contain stuff that doesn't *have* a binary form (JSON
   >>       data and HTML/... components), so I guess we're alright?
   >>    - MPL-2.0: ASF says "Each license in this section requires some
   >>    degree of reciprocity. This may mean that additional action is warranted in
   >>    order to minimize the chance that a user of an Apache product will create a
   >>    derivative work of a differently-licensed portion of an Apache product
   >>    without being aware of the applicable requirements."
   >>       - Packages: mdn-data (
   >>       - My take: the ASF 3rd-party license policy is vague enough to be
   >>       useless for me here. No idea whether we're in the clear.
   >> Fun one I didn't know about; "Unlicense" is an actual license name , and
   >> it explicitly assigns software to the public domain. Nice.
   >> Assuming the above licenses / uses are cleared, this command does the
   >> checking for us:
   >> license-checker --onlyAllow 'MIT;ISC;BSD-3-Cluase;Apache-2.0;BSD-2-Cluase;MIT*;BSD*;BSD;CC-BY-4.0;CC-1.0;Apache*;CC-BY-3.0;WTFPL;MPL-2.0;CC0-1.0;Unlicense'
   >> We might need to tweak it if new dependencies come in with licenses the
   >> ASF likes, but are not in the least. It also outputs the full dump of
   >> dependencies (so we can also add --json | our-preprocessor if we want,
   >> etc).
   >> Let me double down on the mentor ping. How do we handle the above
   >> licenses / uses? @reta <> @michaelsembwever
   >> <> @WillemJiang
   >> <> @wu-sheng <>
   >> —
   >> You are receiving this because you authored the thread.
   >> Reply to this email directly, view it on GitHub
   >> <>,
   >> or mute the thread
   >> <>
   >> .

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:

With regards,
Apache Git Services

View raw message