Re: LICENSE file questions - MIT, binary, process
Alex went the extra mile and revamped how we generate the LICENSE and
NOTICE files for Brooklyn projects, thanks for this Alex!
I went through it and it looks good to me. However, I'm not very familiar
with this topic so I would appreciate if someone else could eyeball it,
especially the updated `README.md`.
On Tue, 26 Jun 2018 at 09:51 Richard Downer <richard@xxxxxxxxxx> wrote:
> Hi Alex,
> Catching up on this email thread. Sorry I'm late and if I cover things that
> have already been discussed.
> Just as a general note I wrote this page on the Brooklyn website to turn
> the generic Apache legal requirements into something tailored for our
> Java+Maven+JS project. If during this exercise we discover an error or
> omission on that page, let's update it.
> On Wed, 20 Jun 2018 at 13:47, Alex Heneveld <
> > 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?
> Yes I believe this is correct. Copyright generally follows "is X a
> derivative of Y", and if X is the compiler output from source Y then yes it
> is a derivative - unless the license makes a distinction it's safest to
> assume that the compiled output is subject to the same license as the
> source input.
> https://www.apache.org/dev/licensing-howto.html contains some relevant
> information here. In particular, it clarifies that the license of all
> bundled dependencies must be included in LICENSE, and also that "what
> applies to canonical source distributions also applies to all
> redistributions, including binary redistributions", and that "when
> assembling binary distributions, it is common to pull in and bundle
> additional dependencies which are not bundled with the source distribution.
> These additional dependencies must be accounted for in LICENSE and NOTICE."
> 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).
> Yes this is true. Generally the ready-to-run binaries bundle a lot more
> stuff then the source archives so have a much bigger LICENSE. Just to make
> life even more interesting, sometimes things in the source distribution
> disappear during compilation and don't appear in the binary! I believe that
> this is the case for Google Auto Value - it's annotations are compile-time
> only so don't appear in the JAR file, Auto Value does all its work during
> the build, and nothing of Auto Value itself appears in the compilation
> > 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:
> > Question 2: Does the above sound right?
> Good catch on these. Yes they sound like there's some attention needed
> 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 ?
> I don't know of any reason why not. We're all one big happy family here,
> seems inappropriate to give big shouts to external dependencies but not to
> our fellow ASF projects, without which we would not be here!
> Thanks for looking into this Alex. License compliance is an ugly task. The
> PMC owes you a beer :-)
Senior Software Engineer
*Cloudsoft <https://cloudsoft.io/> *| Bringing Business to the Cloud
Need a hand with AWS? Get a Free Consultation.