osdir.com


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

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