incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cory Johns <john...@gmail.com>
Subject Re: [DISCUSS] Release of Apache Allura (incubating) v1.0.0
Date Wed, 25 Sep 2013 16:02:25 GMT
Marvin,

We've been having some discussion and I'd just like to clarify something
you said:

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

Does this mean that as long as we are releasing the sub-packages on PyPI
only, and not through Apache channels, that we can leave out the LICENSE
and NOTICE files (with license headers remaining in the individual files
and the top-level LICENSE and NOTICE file remaining in the ASF release, of
course)?


Thanks


On Tue, Sep 17, 2013 at 6:19 PM, Marvin Humphrey <marvin@rectangular.com>wrote:

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

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