Re: LICENSE file questions - MIT, binary, process
>>> but if you look closely you'll see both NOTICE and LICENSE are also
valid YAML so machines can work with them.
wow :-) And this works with Licensee? I see it does - witness the fine
looking legal notice Github has automatically added to
I think that's a great structure - it's ideal having LICENSE contain only
the actual Apache 2 license, and while  does ask for NOTICE to be brief,
it's the logical other place to put our dependency licenses.
Above proposal sounds good to me!
On Fri, 22 Jun 2018 at 11:32 Alex Heneveld <alex.heneveld@xxxxxxxxxxxxxxxxx>
> Hi folks-
> Thanks Geoff. As per discussion at
> https://github.com/apache/brooklyn/pull/15 and reviewing the Apache docs
> (- 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
> 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.
>  http://www.apache.org/dev/licensing-howto.html#permissive-deps
>  http://www.apache.org/dev/licensing-howto.html#mod-notice
>  http://www.apache.org/foundation/license-faq.html#Scope
>  https://www.apache.org/legal/resolved.html
> Relevant snippets:
> (a) It is suggested at  that licenses for dependencies should be
> included in the LICENSE file.
> (b) It is also noted at  that "Under normal circumstances, there is
> no need to modify NOTICE.".
> (c) Elsewhere in the same doc at  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  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  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
> (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).
> 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
> > 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
> > 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
> > 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 <
> > 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 , 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  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 , correctly, and in the binary build's LICENSE, also
> >> correctly. But the project source LICENSE  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 ,
> >> 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  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
> >>  https://apache.org/dev/licensing-howto.html
> >>  https://github.com/apache/brooklyn-client/blob/master/cli/LICENSE
> >>  https://github.com/apache/brooklyn-server/blob/master/LICENSE
> >>  https://github.com/apache/brooklyn-ui/blob/master/LICENSE
> >>  https://www.npmjs.com/package/license-checker