incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Mallette <>
Subject Re: Advice on binary NOTICE
Date Mon, 21 Mar 2016 11:55:46 GMT
As Justin has played a big role in shaping our LICENSE/NOTICE to this
point, I would most immediately lean on his advice here and just not add
the Jackson notice given that it's not well-formed.  The fact that I can
now recognize a faulty NOTICE and question whether it should go in shows
that with some training it's possible to learn the art of doing
LICENSE/NOTICE.  In that sense, I don't really see anything wrong with the
current approach, thought it does present pains for podlings who will find
frustration in learning the art without a few more lines of documentation
that talk about what a NOTICE looks like, or even three or four top-level
projects  that are "doing it right" that podlings can view as an example.

All that said, I think that a simple, consistent approach of just taking
the entire NOTICE, if it is present, is about as easy as it could get. So
ultimately, if this discussion were to go forward and there was broad
approval of it, I would be supportive of that method.



On Sun, Mar 20, 2016 at 11:34 PM, Justin Mclean <> wrote:

> Hi,
> > *   The PMC is spared from performing analysis of dependency NOTICE
> content.
> > *   Verbatim aggregation can be achieved programmatically, allowing for
> >    automated solutions.
> It simple I like that.
> However there's probably no TLP or incubator project (with bundled Apache
> licensed code) that follows that currently. It will also tend to make
> NOTICE files larger and that has a flow on effect to downstream projects.
> It will have a larger impact on connivence binaries NOTICE files.
> Would’t it be better for incubating projects to just ask IPMC or legal for
> help when putting together NOTICE files?
> Thanks,
> Justin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message