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 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  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 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 <alex.heneveld@xxxxxxxxxxxxxxxxx> 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