incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@apache.org>
Subject Re: Advice on binary NOTICE
Date Sun, 20 Mar 2016 21:13:36 GMT
On Sun, Mar 20, 2016 at 12:28 PM, Marvin Humphrey <marvin@rectangular.com>
wrote:

> On Sun, Mar 20, 2016 at 11:24 AM, Henri Yandell <bayard@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

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