On Sun, Mar 20, 2016 at 12:28 PM, Marvin Humphrey <mar...@rectangular.com> wrote:
> On Sun, Mar 20, 2016 at 11:24 AM, Henri Yandell <bay...@apache.org> wrote: > > I suspect 'relevant' means those parts of a NOTICE relating to the parts > of > > the product you use. > > Yes, that was the intent. That sentence references section 4d of the ALv2, > specifically this phrase: > > excluding those notices that do not pertain to any part of the > Derivative Works, > > > I suspect 'relevant' needs clarification in the docs. > > Over time, I have come to think our approach to NOTICE should be more > formulaic. The expectation that our PMCs will edit dependency NOTICE > content > is too burdensome. > > It is quite challenging to analyze which parts of a NOTICE file may be > omitted > -- especially when you take into account the vagaries of subsuming the > notice > requirements of licenses besides the ALv2. Only a handful of our PMCs > possess > sufficient collective expertise in open source licensing to perform such > license analysis accurately. > > Yet, our goal should be for *every* Apache release to conform to both legal > requirements and policy. We can't change our legal obligations -- but we > can > and should craft policy and best-practice recommendations so that the > process > of assembling LICENSE and NOTICE is not so taxing and yields consistently > correct results. > > The proposal from last month to cease NOTICE aggregation entirely[1] > failed to > achieve consensus. The next-best alternative, it seems to me, is a > completely > mechanical approach to aggregation: verbatim copying of NOTICE comment from > dependency NOTICE files to the top-level NOTICE file. This has two > significant advantages: > > * The PMC is spared from performing analysis of dependency NOTICE > content. > * Verbatim aggregation can be achieved programmatically, allowing for > automated solutions. > > In the case of a NOTICE file from a non-ASF ALv2 product, verbatim > propagation > is a completely defensible choice. But I think we should consider > recommending it for all ALv2 dependencies, including ASF products. > +1. License compliance is best when it's simple, and errs on being over-informative. I think defining the structure of the files would be valuable. A standard delimiter (---- etc) between different sections and a 'header' to a section; ie) "Contents of Jackson 1.3 NOTICE file". Hen