incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject Re: [DISCUSS] Release of Apache Allura (incubating) v1.0.0
Date Tue, 17 Sep 2013 22:19:55 GMT
On Tue, Sep 17, 2013 at 12:41 PM, Cory Johns <> wrote:
> I had one question regarding the NOTICE and LICENSE files issue that you
> mentioned on the [VOTE] thread.  We were considering, in the future,
> potentially releasing each of the Allura and Forge sub-packages separately
> on pypi to ease configuration of an Allura system, which is why were
> providing separate NOTICE and LICENSE files for each sub-package.

The key principle is that the top-level LICENSE and NOTICE must represent the
exact contents of the specific distribution they reside in.

*   The licensing of nested dependencies must be accounted for at the top
    level.  Consumers shouldn't have to hunt through every file in every
    directory of the source tree to discover the complete licensing of the
    product they're consuming.  Bundling dependency licensing info "as is"
    may satisfy hard-and-fast requirements for some dependency licenses, but
    it is ASF policy to provide "flattened" licensing info at the top level of
    our distros for the benefit of our users.
*   Don't include entries in the top-level LICENSE and NOTICE for dependencies
    which are **not** bundled in the distribution in question.  If consumers
    are obtaining those bits from an outside source, they must obtain the
    licensing info for those bits from the same outside source.
*   If you provide "convenience binaries" in addition to your canonical source
    release artifacts and those binaries bundle dependencies which are not
    bundled with the source release, then the LICENSE and NOTICE for the
    binary artifacts must account for the additional IP and will presumably
    differ from the LICENSE and NOTICE of the source release.
*   If you provide a "-deps" bundle to complement the primary release
    artifacts, it should have its own LICENSE and NOTICE info which varies
    independently and represents its own exact contents.

Note that since these are ASF policies which have evolved over the years
rather than absolute legal requirements, compliance varies somewhat across
TLPs and time.  The Incubator PMC will also sometimes let licensing
documentation bugs go, depending on their impact on downstream consumers and
assuming that they don't cause the release to violate anybody's license.
However, it's definitely in your interest to make a best effort to adhere to
the policy.

> Is the separate pypi release something that the ASF release is amenable to,
> and, if so, should we still stick to a single NOTICE or single NOTICE &
> LICENSE file?

Any artifact that is being distributed through Apache channels is supposed to
adhere to our policies.

"Convenience binaries" and derived source releases are alike in that both are
"downstream" from the canonical source release, so to speak.  I infer from
your description that in this case the PyPI-flavored release artifacts consist
of subsets of files extracted from the canonical source release.  The same key
principle applies: LICENSE and NOTICE must represent the exact contents of the
specific distribution they reside in.  That means if there are dependencies in
the canonical source release which are not present in the PyPI release, the
PyPI distro's LICENSE and NOTICE files need to be edited down to remove any
licensing info which does not apply.

Marvin Humphrey

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message