You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@allura.apache.org by Dave Brondsema <da...@brondsema.net> on 2013/10/01 16:58:33 UTC

Re: RFC: LICENSE and NOTICE cleanups (ASF release)

Cory asked about PyPI releases on the incubator list and we got this reponse:
http://mail-archives.apache.org/mod_mbox/incubator-general/201309.mbox/%3CCAAS6%3D7i4Nq4Pg6de205nn-swW4VrN%2BfZ5bUu7tDRqHEKomqwBQ%40mail.gmail.com%3E

Does that help us enough to decide what way we want to go with this?

On 9/24/13 5:40 PM, Dave Brondsema wrote:
> I think sebb's comments could be interpreted either way :)  But it sounds like
> we agree that it's better not to have extra LICENSE & NOTICE files that may
> confuse people.
> 
> I like Peter's suggestion of keeping them in the source so that they're ready if
> we need them later for PyPI releases, and then have a little release script to
> remove them from the tarball.  A little release script could be nice anyway to
> make sure we don't fat finger any details (git archive params, proper filename,
> add git tag, create hash files).  We would have to keep them both maintained
> when we add new bundled dependencies.
> 
> I also see Cory's point that we might not even need the per-package LICENSE &
> NOTICE files if we release via pypi.  But if we do end up needing them, then
> splitting them back out of the combined top-level file to reconstruct
> individually could be difficult and error-prone.
> 
> -Dave
> 
> On 9/24/13 3:32 PM, Cory Johns wrote:
>> 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).
>>
>>
>> [1]
>> http://mail-archives.apache.org/mod_mbox/incubator-general/201309.mbox/%3CCAAS6=7hTA13GHbBwwy3-X+Bz5i38X4UoM+cYsv7Q13x+azp7mw@mail.gmail.com%3E
>>
>>
>> On Tue, Sep 24, 2013 at 2:36 PM, Peter Hartmann <ma...@gmail.com>wrote:
>>
>>> W dniu 24.09.2013 o 20:27 Cory Johns <jo...@gmail.com> 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 :(
>>>
>>
> 
> 
> 



-- 
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
              <><