On Tue, Sep 17, 2013 at 12:41 PM, Cory Johns <john...@gmail.com> 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: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
