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 <mar...@rectangular.com>wrote: > 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 > >
