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 19:32:48 GMT
I'm not arguing that he didn't suggest that we *should* have only a single
LICENSE and NOTICE file, but that is different than *must*.  I was also
reading that in context of the previous statement that the top-level
LICENSE and NOTICE files were incorrect and, subsequently, that the extra
files were confusing.  I took that to mean that if the top-level files were
correct, the additional files would be less of an issue.  Particularly when
taken together with Marvin's message in the [DICSUSS] thread [1] explicitly
discussing the sub-package LICENSE and NOTICE files; his advice was they
needed to be reduced to be minimally complete for their respective
sub-package, just like the top-level LICENSE and NOTICE file must be
minimally complete for the whole release.

That said, I do think that it might be better to remove the extra LICENSE
and NOTICE files, particularly since we won't be distributing the
individual PyPI packages through ASF channels so it is quite possible that
the legal requirements do not apply (and the file headers should be
sufficient for PyPI).


On Tue, Sep 24, 2013 at 2:36 PM, Peter Hartmann <>wrote:

> W dniu 24.09.2013 o 20:27 Cory Johns <> pisze:
>  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.
> With respect, I think he said exactly that:
> "There should be a single NOTICE and LICENSE file in the parent
> directory (allura/) which covers all the contents (and nothing else)."
> At least that's the way I read it, "single NOTICE and LICENSE (...) and
> nothing else" looks and sounds quite definitive to me.
>   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.
> I'm pretty shure it shouldn't :)
> On a NOTICE point, if that's how it is determined - perfectly fine.
> Perhaps I'll propose some better wording to these legal docs, If I'll be
> able to someday :(

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