OSDir


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LICENSE file questions - MIT, binary, process



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 <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 [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