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 > >
