calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Laurent Goujon <>
Subject Re: [VOTE] Release apache-calcite-1.23.0 (release candidate 1)
Date Fri, 22 May 2020 20:37:35 GMT
My intent was not to cause sadness, sorry about that.

I should have elaborated a bit more why I don't think Github is that much
of an issue:
- LICENSE file at the root of the project is the source of truth, not
Github mention. It is a nice to have the correct license for Github for
sure, but it seems more important to me to have LICENSE includes the 3rd
party dependencies present in our source tree than having the license
displayed at the top of the github UI.

- As for the embox project you mentioned, it's probably because the license
is short and BSD licenses have very similar texts. Here's what license says
about the project:

$ licensee detect
License:        NOASSERTION
Matched files:  COPYRIGHT
  Content hash:  77dc7c8c10d1ed9bc1546f2d6bba18a809e235c7
  License:       NOASSERTION
  Closest non-matching licenses:
    BSD-2-Clause similarity:  89.59%
    BSD-3-Clause similarity:  83.54%
    BSD-4-Clause similarity:  77.82%

$ licensee license-path

Here's now what licensee says the LICENSE file from the source distribution

$ licensee detect ./apache-calcite-1.23.0-src
License:        Apache-2.0
Matched files:  LICENSE
  Content hash:  ab3901051663cb8ee5dea9ebdff406ad136910e3
  Confidence:    100.00%
  Matcher:       Licensee::Matchers::Exact
  License:       Apache-2.0

$ licensee license-path ./apache-calcite-1.23.0-src

It seems that adding several mentions at the bottom, licensee has no
trouble identifying the apache license because the text is so large and so
distinctive. It is corroborated by my own personal experience of checking
license for many many dependencies and comparing between Maven pom.xml,
github mention, and actual LICENSE/source file headers than when people are
using ASL 2.0, even with copyright mention + extra stuff after the main
text, Github gets it right.

On Fri, May 22, 2020 at 12:32 PM Vladimir Sitnikov <> wrote:

> Laurent>As for Github, I think this is a non-issue
> I have provided an example:
> It is an example when GitHub fails to detect the license.
> It is really sad to hear that "you think it is a non-issue" even in case
> you have seen the failure case.
> Laurent>on the source distribution and it has no issue identifying the
> license.
> The license might vary over time, and it would be very bad to end up with
> improperly detected license in GitHub.
> Vladimir

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