>>> 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 https://github.com/ahgittin/license-sample/blob/master/LICENSE. Cool. I think that's a great structure - it's ideal having LICENSE contain only the actual Apache 2 license, and while [2] 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 <[email protected]> wrote: > > 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 > >> > >
