If you have concerns about Apache OpenOffice it is no longer incubating. If you will contact the project on its lists with a concrete example.
Otherwise to my knowledge LICENSE and NOTICES are correct at an appropriate level. Regards, Dave Sent from my iPhone On Sep 18, 2013, at 7:49 PM, Eric Yang <eric...@gmail.com> wrote: > Thank you Elder for filing the LEGAL-178. Tim, the link provided is for > source file headers and reference to Apache distribution of source code > tarball. We will wait for LEGAL-178 to be resolved to react. This implies > that Apache OpenOffice is also not doing the right thing. OpenOffice has > its license translated to multiple languages, hence LICENSE and NOTICE > files are not at top level. We should plan to make the system scale and > improve upon. We can plan to make course correction for future release. > The existing artifacts have been released for years, and it may not be the > best interest of Apache Foundation to recall those artifacts. There could > be users who depends on them. Binary artifacts did not violate any license > terms. We appreciate your understanding on the subject at hand. > > regards, > Eric > > > On Mon, Sep 16, 2013 at 1:44 AM, ant elder <ant.el...@gmail.com> wrote: > >> Perhaps, but AFAICT the existing documentation is either incorrect, >> lacking, or ambiguous so i've raised LEGAL-178 to clarify. >> >> ...ant >> >> On Mon, Sep 16, 2013 at 12:56 AM, sebb <seb...@gmail.com> wrote: >>> On 15 September 2013 14:16, Tim Williams <william...@gmail.com> wrote: >>>> On Sun, Sep 15, 2013 at 5:19 AM, ant elder <ant.el...@gmail.com> wrote: >>>>> Tim, one of the things we're trying to teach podlings is how to handle >>>>> disputes and resolve problems in a happy respectful manner. You've out >>>>> of the blue come on to their dev list without introducing yourself >>>>> demanding that something that happened nearly two years ago be undone. >>>> >>>> My mail on their list wasn't intended to be 'demanding' or rude - my >>>> apologies if it came across that way. I honestly went in thinking it >>>> was a mistake - a simple misunderstanding. >>>> >>>>> Its a testament to Chukwa that they've engaged in discussing the >>>>> matter with you promptly and politely, never the less in under 48 >>>>> hours of starting the discussion you've escalated this to general@ >>>>> with a fairly negative email. >>>> >>>> I agree, Eric was prompt and polite. I "escalated" this for two >> reasons: >>>> >>>> 1) It became apparent that it wasn't a misunderstanding - it's a >>>> question of policy and it doesn't seem fair to hash that out on their >>>> dev list. It wasn't so much "escalation" as taking policy discussions >>>> to the right audience - if there were a mentor@ list, I would have >>>> aimed there. >>>> >>>> 2) This PMC has a release artifact published that was never voted >>>> upon. That was news to me and, I felt, worthy of sunlight - >>>> especially after the [prompt/polite] defensive reaction received. >>>> >>>> Sorry for the negativity, it was borne of frustration. It's >>>> frustrating to ask podlings to work hard dotting I's and crossing T's >>>> only to look around and see other podling's lackadaisical approach. >>>> >>>>> Lets take your LICENSE/NOTICE file issue, you initially said the >>>>> binary artifact didn't have any, it was then pointed out that in fact >>>>> it did have them just not where you were looking, you then asserted >>>>> that is not acceptable and they must only be right at the top >>>>> directory, it was then pointed out other types of binary distributions >>>>> like jars also don't have them at the top either, but you have ignored >>>>> that and instead come here to general@. >>>> >>>> I guess I viewed that as a frustrating rationalization. Their distro >>>> is a standard tarball - where those files are well expected to be in >>>> the standard place by both policy and social norm - not some other >>>> artifact type where an difference is obvious. Anyway, moving it here >>>> was less about that and more about the fact that they released an >>>> artifact without voting. >>>> >>>> Though, since you bring it up I'd appreciate that if there's going to >>>> be no accountability for podlings to locate those source files in the >>>> right place[1], then yeah, I think we should change the policy to >>>> state that anywhere in the artifact is acceptable. >>> >>> I think the only proper places are at the top level for tarballs with >>> the option of the META-INF directory for jars. >>> >>>> --tim >>>> >>>> [1] - http://apache.org/legal/src-headers.html#notice >>>> >>>>> I have no doubt that Chukwa will be happy to help resolve this in >>>>> whatever way is necessary to satisfy all the ASF policy's, but we >>>>> don't need a big general@ flame thread to do that. >>>>> >>>>> ...ant >>>>> >>>>> On Sun, Sep 15, 2013 at 3:46 AM, Tim Williams <william...@gmail.com> >> wrote: >>>>>> Moving this[1] to general@ >>>>>> >>>>>> On Sat, Sep 14, 2013 at 2:55 AM, ant elder <ant.el...@gmail.com> >> wrote: >>>>>>> On Saturday, September 14, 2013, Tim Williams <william...@gmail.com> >> wrote: >>>>>>>> Hi Eric, >>>>>>>> I've included references inline for your convenience. I'll once >> again >>>>>>>> [strongly] suggest you guys remove that artifact. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> --tim >>>>>>>> >>>>>>>> On Fri, Sep 13, 2013 at 6:53 PM, Eric Yang <eric...@gmail.com> >> wrote: >>>>>>>>> Hi Tim, >>>>>>>>> >>>>>>>>> There is LICENSE.txt and NOTICES.txt in both source and binary >> package. >>>>>>> In >>>>>>>>> the binary package, the files are located in >> $PREFIX/share/doc/chukwa to >>>>>>>>> match what standard Linux file system layout. We voted for source >>>>>>> release >>>>>>>>> and there is no Apache restriction that a source release, can not >>>>>>> procedure >>>>>>>>> a binary package. >>>>>>>> >>>>>>>> "Votes on whether a package is ready to be released use majority >>>>>>>> approval -- i.e., at least three PMC members must vote affirmatively >>>>>>>> for release, and there must be more positive than negative votes." >>>>>>>> >>>>>>>> Each vote is on signed, hashed artifacts, so yes, if you say it's a >>>>>>>> "source vote" then no binary should accompany it. >>>>>>>> >>>>>>>> http://www.apache.org/dev/release.html#approving-a-release >>>>>>>> >>>>>>>>> There is also no restriction that binary release must >>>>>>>>> have LICENSE.txt and NOTICES.txt in the top level directory. >>>>>>>> >>>>>>>> How do you reach that understanding from the sentence below? >>>>>>>> >>>>>>>> "Every Apache distribution should include a NOTICE file in the top >>>>>>>> directory, along with the standard LICENSE file." >>>>>>> >>>>>>> Plenty of other release artifacts from other projects have these >> files >>>>>>> somewhere other than the top directory, eg most jar releases have >> them in >>>>>>> the meta-inf directory. >>>>>>> >>>>>>> There is also ambiguity around convenience binary releases in the >> ASF docs >>>>>>> and the historical mailing list discussions around those, so a little >>>>>>> flexibility is warranted. I recall there was once a some bugs in the >> maven >>>>>>> plugin for building jars which meant several projects distributing >> jar >>>>>>> artifacts with missing or completely incorrect license/notice files, >> and >>>>>>> those artifacts weren't pulled . I also recall on one project where >> an >>>>>>> artifact was discovered distributed without a release vote and the >> solution >>>>>>> was just to have a posthumous vote. The important thing here in my >> opinion >>>>>>> is to get a common understanding of how convenience binary artifacts >> will >>>>>>> be handled in the future that everyone is happy with. >>>>>> >>>>>> No offense, but this is ridiculous. If our job as mentors is to help >>>>>> podlings rationalize violations of most basic policies (e.g. release >>>>>> artifacts require a vote, NOTICE/LICENSE files), to play the >>>>>> well-they-got-away-with-it game, then this process is really a joke >>>>>> and we should close up shop. If such basic things as this are really >>>>>> up for debate by seemingly clueful folk, then the incubator isn't >>>>>> serving a useful purpose and should be dissolved as it means we're >>>>>> actively graduating podlings that are somewhere between just not >>>>>> getting it and putting the foundation at risk. (alarmingly, discussion >>>>>> of Chukwa's graduation was recently had!). I dunno, that podlings are >>>>>> defending the idea of releasing unvoted on artifacts only to have >>>>>> their mentor follow suit is frustrating - I really assumed this was >>>>>> as simply case of "oh, we didn't understand that"... >>>>>> >>>>>> Thanks, >>>>>> --tim >>>>>> >>>>>> [1] - >> http://mail-archives.apache.org/mod_mbox/incubator-chukwa-dev/201309.mbox/browser >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>>>>> For additional commands, e-mail: general-h...@incubator.apache.org >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>>>> For additional commands, e-mail: general-h...@incubator.apache.org >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>>> For additional commands, e-mail: general-h...@incubator.apache.org >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>> For additional commands, e-mail: general-h...@incubator.apache.org >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
