Hi folks-
Thanks Geoff. As per discussion at
https://github.com/apache/brooklyn/pull/15 and reviewing the Apache docs
([1]-[4] below) I think the best thing is:
* For `LICENSE` to contain the Apache License, followed by dependency
licenses *and practically nothing else*;
* For the listing of dependencies and their notices and statement of
which licenses apply to be moved to the `NOTICE` file;
* For that listing to include all dependencies (not just source-bundled
ones)
This allows the popular `licensee` software to detect the license
correctly, while making it easy for human readers to
find the information we need. It ensures we don't omit notices that are
required that are in many cases currently omitted.
And ASF compliance-wise this actually seems slightly better -- LICENSE
is _just_ licenses, and NOTICE is all the legally-required text.
I've put together an example at
*https://github.com/ahgittin/license-sample* . Note the files are human
readable but if you look closely you'll see both NOTICE and LICENSE are
also valid YAML so machines can work with them.
*Please let me know if anyone objects to this model!*
See below for more detailed notes.
Best
Alex
[1] http://www.apache.org/dev/licensing-howto.html#permissive-deps
[2] http://www.apache.org/dev/licensing-howto.html#mod-notice
[3] http://www.apache.org/foundation/license-faq.html#Scope
[4] https://www.apache.org/legal/resolved.html
Relevant snippets:
(a) It is suggested at [1] that licenses for dependencies should be
included in the LICENSE file.
(b) It is also noted at [1] that "Under normal circumstances, there is
no need to modify NOTICE.".
(c) Elsewhere in the same doc at [2] it notes, "It is important to keep
NOTICE as brief and simple as possible, as each addition places a burden
on downstream consumers. Do not add anything to NOTICE which is not
legally required."
(d) The FAQ [3] is more forgiving, noting that "other third party works
may have been included and their license text may have been added to the
Apache projects' LICENSE or NOTICE files".
(e) The "Resolved" document [4] notes: "Apache releases should contain
a copy of each license, usually contained in the LICENSE document. For
many licenses this is a sufficient notice. For some licenses some
additional notice is required. In many cases, this will be included
within the dependent artifact. A required third-party notice is any
third party notice which isn't covered by the above cases."
Potential mistakes (many of which seem to be widespread):
(A) NOTICE and LICENSE must be included in all built JARs (we don't do this)
(B) Most the licenses we use require inclusion of specific text (eg MIT
and BSD for copyright/attribution, Apache for NOTICE files, etc); as
compilation is essentially a translation and copyright extends to
translations, it seems clear if surprising that this requirement applies
to binaries as well as source code
(C) Where relying on required specific text being included in the
third-party artifacts the build process must ensure these are preserved
in the resulting binary (this is a risk eg for JS code which is minified
or Go code which is compiled or JARs which don't include NOTICE)
(D) The suggestion (b) above is misleading in many cases given (B) and (C).
Finally:
The proposed approach of declaring _all_ dependencies and their notices
in NOTICE is arguably more than is necessary and contrary to the
observation (c), but given the risk of accidentally omitting something
that is required, particularly given the frequency of build processes
(ours or upstream) removing required notices elsewhere (e.g. C, A), I
think it's wise. It also seems good practice to give attribution where
we benefit from others' software and to require downstream users to do
the same. The increased burden of a few hundred extra lines in a NOTICE
file is negligible in my view, compared with 100+ MB for the artifacts!
On 21/06/2018 15:56, Geoff Macartney wrote:
Hi Alex,
I'm not an expert on licensing requirements but the above sounds convincing
to me. Your proposal sounds like a good plan. Re. question 3 I think it
is okay to include the Apache licensed dependencies in the binary LICENSE
too.
A minor note - have you seen https://github.com/apache/brooklyn/pull/15 "edit
Brooklyn license info so that GitHub recognizes it"? I intend to merge
this but added the comment to clarify whether we should do the same for all
our repos (I assume so). I intend to raise PRs to do this if so.
Geoff
On Wed, 20 Jun 2018 at 13:47 Alex Heneveld <[email protected]>
wrote:
Hi Brooklyn devs-
In prepping the new UI contribution I've been working on the LICENSE
file generation. It is rather extensive because by using Angular we
pull in hundreds of JS deps for the binary, most of them under MIT
license which as I understand it means copyright information must be
reproduced in the LICENSE for the binary dist. This is based on the MIT
clause "The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software" in
accordance with the principle that copyright extends to translations.
While it would be tempting to treat the compiled/minified version as not
a copy and so not requiring the copyright -- and that may well be the
intention of many MIT license users (contrasted with BSD which
explicitly calls out binaries as requiring the copyright) -- I don't
believe we can hide behind that. (So JS devs please take note, please
use the Apache License! :) )
Question 1: Is this correct, our binaries LICENSE files need to list
all MIT, BSD, ISC licensed dependencies whose minified/compiled output
is included in our binary dist?
In the process I've noticed we in Brooklyn don't currently distinguish
consistently between the source LICENSE and binary LICENSE. As I
understand it from [1], the LICENSE file included with source projects
-- including I believe the one at the root of the git repo -- should
refer to resources included in the source only. Dependencies that are
downloaded as part of the build and included in the binary should not be
listed in those LICENSE files, but they must be included in any binary
build (eg the RPM, TGZ).
It's not yet a big issue as it doesn't matter for Apache licensed
dependencies as they do not require copyright inclusion or attribution
and these are the bulk of what we do. Where we do need to look more
closely I think are:
(A) The Go CLI -- we use a few libraries (mainly MIT licensed)
downloaded at build time. The LICENSE file [2] includes these
libraries. This is included in the binary build, which is correct, but
it is also present at the root of that sub-project where it is
incorrect, and our source build also references these libraries which is
incorrect.
(B) JS in "brooklyn-server" -- we have a few JS libraries included in
the source tree of brooklyn-server (not downloaded during the build),
for some of the CLI commands; these are indicated in that project's
LICENSE [3], correctly, and in the binary build's LICENSE, also
correctly. But the project source LICENSE [3] seems to include all the
JS used in the "brooklyn-ui" project which is not correct.
(C) JS in existing (old) "brooklyn-ui" -- this source project includes
all the JS deps checked in, and it is listed in the LICENSE [4],
correctly, and is included in the build binary, also correctly; no
action is needed here
(D) JS in new (proposed) "brooklyn-ui" -- this project updates to use
npm and package.json so downloads dependencies, with no dependencies in
the source tree, so the project source LICENSE shouldn't list any
dependencies. However the binary license should include the ~100
dependencies that npm downloads and uglifies. Fortunately npm
license-checker [5] automates much of this (although the copyright line
will sometimes have to be teased out manually).
Question 2: Does the above sound right?
I'm reasonably confident of this so if no objections I will adjust our
LICENSE generation process to distinguish between binary and source, and
tidy up (A) and (B) above, and set up the contribution as per (D).
Finally one more question -- it's easy to tweak the process to include
Apache-licensed dependencies used in the binary. While this isn't
legally required AFAIK it seems like a nice thing to do.
Question 3: Is everyone okay with giving a shout-out to Apache-licensed
deps in addition to MIT, BSD, etc, within our binary LICENSE ?
Best
Alex
[1] https://apache.org/dev/licensing-howto.html
[2] https://github.com/apache/brooklyn-client/blob/master/cli/LICENSE
[3] https://github.com/apache/brooklyn-server/blob/master/LICENSE
[4] https://github.com/apache/brooklyn-ui/blob/master/LICENSE
[5] https://www.npmjs.com/package/license-checker
