I closed LEGAL-178 with the resolution "Not A Problem", which is quite different to a resolution of "Fixed" or "Resolved" or "Answered".
>From my investigation, things like the text of the AL and various posts in the mailing lists over the years answered the question to my satisfaction. I doubt everyone agrees yet but the answers for me are: - there is no need to vote on the convenience binary artifacts - in fact voting on them is a bit pointless as you can't easily verify the contents anyway, and the ASF only does source releases. - its ok to have unvoted on convenience binaries in the ASF distribution areas - there is no requirement to have LICENSE/NOTICE files in the root directory of a convenience binary However i think it would take a fair bit of work to build enough consensus around any documentation update. So just closing LEGAL-178 as Not A Problem seemed much easier now that it seems like no one is insisting any historic artifacts be removed. Happy to continue discussing this as it does seem an interesting topic, but if we do could it be in a new thread not so tied to Chukwa. ...ant On Mon, Sep 23, 2013 at 11:42 PM, Luciano Resende <luckbr1...@gmail.com>wrote: > On Mon, Sep 23, 2013 at 2:23 PM, Marvin Humphrey <mar...@rectangular.com > >wrote: > > > On Mon, Sep 23, 2013 at 1:45 PM, Luciano Resende <luckbr1...@gmail.com> > > wrote: > > > > > Thanks for the summary Marvin, how about we take the chance to update > > our > > > policy/documentation to clarify the social norm regarding placement of > > > LICENSE/NOTICE in the top level of a distribution but also clarify > that, > > > any artifact being release by an Apache Project should be reviewed and > > > voted, as there were some suggestions on this thread that this was not > > the > > > case. If we can't clarify that on ASF level, at least we can clarify > that > > > on the IPMC level. > > > > I understand the motivation, but I'm actually in favor of keeping the > > status > > quo. > > > > As Joe Schaefer pointed out, the VOTE only applies to the canonical > source > > release. Binary artifacts cannot be official releases of the ASF, and > the > > IPMC cannot override that policy. > > > > > Is there any written policy that states that ? I have never heard that the > ASF can't have binary artifacts as official releases ? > > Also, from Joe's message, I think he was mentioning what is done in the > context of HTTPD, not necessarily stating a policy or the social norm here > at Apache. > > > > Additionally, we still have a lot of work to do to squash licensing > > documentation bugs in our canonical source releases. When we can't even > > get > > our official releases right, I don't think it makes sense to dilute our > > already thin quality control resources. > > > > Marvin Humphrey > > > > > The issue I see, particularly when evaluating maven based java source > releases (no binaries at all), is that the a lot of the dependencies for a > project might be transient making much harder and much more work to > evaluate a source only release. While reviewing a binary release, you have > listed all the binary dependencies and all it's associated license, making > the review process much simpler, allowing the reviewer to concentrate on > making sure the dependencies are allowed, no specific jars got unaccounted > on the license/notice, etc... > > > [1] > > http://mail-archives.apache.org/mod_mbox/incubator-general/201309.mbox/%3CBF8E0313-15C2-4375-8470-FE0A1DA917C5%40yahoo.com%3E > > > > -- > Luciano Resende > http://people.apache.org/~lresende > http://twitter.com/lresende1975 > http://lresende.blogspot.com/ >
