incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <>
Subject Re: binary release artifacts
Date Thu, 19 Sep 2013 05:06:06 GMT
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.


Sent from my iPhone

On Sep 18, 2013, at 7:49 PM, Eric Yang <> 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 <> 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 <> wrote:
>>> On 15 September 2013 14:16, Tim Williams <> wrote:
>>>> On Sun, Sep 15, 2013 at 5:19 AM, ant elder <> 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] -
>>>>> 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 <>
>> wrote:
>>>>>> Moving this[1] to general@
>>>>>> On Sat, Sep 14, 2013 at 2:55 AM, ant elder <>
>> wrote:
>>>>>>> On Saturday, September 14, 2013, Tim Williams <>
>> wrote:
>>>>>>>> Hi Eric,
>>>>>>>> I've included references inline for your convenience.  I'll
>> again
>>>>>>>> [strongly] suggest you guys remove that artifact.
>>>>>>>> Thanks,
>>>>>>>> --tim
>>>>>>>> On Fri, Sep 13, 2013 at 6:53 PM, Eric Yang <>
>> wrote:
>>>>>>>>> Hi Tim,
>>>>>>>>> There is LICENSE.txt and NOTICES.txt in both source and
>> 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
>>>>>>>> Each vote is on signed, hashed artifacts, so yes, if you
say it's a
>>>>>>>> "source vote" then no binary should accompany it.
>>>>>>>>> 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
>> them in
>>>>>>> the meta-inf directory.
>>>>>>> There is also ambiguity around convenience binary releases in
>> 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
>> and
>>>>>>> those artifacts weren't pulled . I also recall on one project
>> an
>>>>>>> artifact was discovered distributed without a release vote and
>> 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
>>>>>> defending the idea of releasing unvoted on artifacts only to have
>>>>>> their mentor follow suit is frustrating  - I really assumed this
>>>>>> as simply case of "oh, we didn't understand that"...
>>>>>> Thanks,
>>>>>> --tim
>>>>>> [1] -
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail:
>>>>>> For additional commands, e-mail:
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail:
>>>>> For additional commands, e-mail:
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> For additional commands, e-mail:
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message