incubator-allura-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cory Johns <>
Subject Re: RFC: LICENSE and NOTICE cleanups (ASF release)
Date Tue, 24 Sep 2013 18:27:07 GMT
Sebb didn't say that we *must* have *only* top-level LICENSE and NOTICE
files, just that: 1) the top-level LICENSE file was incomplete and the
top-level NOTICE file contained items it shouldn't; 2) that (possibly
because of point 1) the LICENSE and NOTICE files in the sub-directories
would be confusing to the reviewers and end-users.  I think that, from a
legal standpoint, as long as the top-level LICENSE and NOTICE file are
correct, we're ok.  The additional files LICENSE files might be confusing,
but we can (and do) bundle third-party libraries that contain a LICENSE
file, so I don't think we're going to be able to remove them entirely.
 Trying to come up with some process or program to add or remove licenses
when building a release might be nice, but I'm not sure that it should
block our initial release.

Regarding the public domain code, "permissive licenses" refers to all of
the licenses that are allowed to be distributed along with an ASF project
release, and "attribution is required" refers to the reference in the
LICENSE file.  My understanding now is that it's very unlikely that we need
anything in the NOTICE file, as the only time something should be added to
that is if a bundled library's license *specifically* requires it, most
likely by having its own NOTICE file or by explicitly mentioning it in the
license.  Dave found a specific example of this, the Creative Commons
Attribution License:

After we come to a consensus on these items, it would probably be worth
asking again on the existing [DISCUSS] thread to verify our understanding,
prior to moving forward with the next release.

On Tue, Sep 24, 2013 at 1:56 PM, Peter Hartmann <>wrote:

> My free time has shortened again, for a while. I only occasionally come
> home and check email. I hope my comments are not coming too late and will
> be helpful anyways.
> About multiple LICENSE: I did set it up this way having future PyPI
> releases in mind and took care to ensure that the content is not in
> conflict. I don't remember there be statement like "one LICENSE and nothing
> else", but I assume sebb is right on that.
> Dave suggested, that for PyPI we'll need to prepare some (presumably
> automated) way to put individual LICENSE and NOTICE files. I think it would
> be very difficult from engineering standpoint to split licenses like that.
> Instead, I propose to treat Apache releases in a special way. That is,
> remove per-package files from archive before releasing and not reflect this
> in source tree. Source code repository, even with open access, is not
> considered a distribution channel and is not required to follow release
> guidelines. And building top-level LICENSE from per-package files can be
> automated fairly easy.
> About NOTICE: legal docs clearly state that for public domain code,
> "Attribution is required (in a similar fashion to permissive licenses)"[1].
> For what I know, public domain code isn't licensed - in fact, that's a
> very important distinction. Thus, I read this as "in a similar fashion to
> required attributions in permissive licenses". And these fall in category
> of "required third-party notice"[2] - consider the last sentence/paragraph
> - which belong in NOTICE.
> Either sebb is wrong about NOTICE or legal guidelines are misleading, I
> don't see third option.
> [1]**resolved.html#can-works-**
> placed-in-the-public-domain-**be-included-in-apache-products<>
> [2]**resolved.html#required-third-**party-notices<>

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