The point most people seem to make out of "sanctioned" or "official" builds revolves around indemnifying volunteers involved in the production of the release.
I'm tired of rehashing release.html for the umpteenth time simply because Brane or you or some other newb lacks the experience to know the context behind the document, but as they say patches welcome (on site-...@apache.org). Every committer can alter the wording on that page and do something more productive than make clueless arguments on this ever devolving thread. AOO is mentored by some of the most experienced people in the org, please just ignore any further chaff from this thread and pay attention to the guidance you have been repeatedly given on this issue. AOO doesn't need to change anything to their current release processes other than to stop pointing source downloads at svn (which is the sole reason I won't vote for AOO candidates). ----- Original Message ----- > From: Rob Weir <robw...@apache.org> > To: general@incubator.apache.org > Cc: > Sent: Sunday, August 26, 2012 9:54 AM > Subject: Re: [VOTE] Apache OpenOffice Community Graduation Vote > > On Sun, Aug 26, 2012 at 7:26 AM, Branko Čibej <br...@apache.org> wrote: >> On 26.08.2012 13:15, Tim Williams wrote: >>> Marvin gave the link earlier in this thread. 4th para is the relevant > bit. >>> >>> http://www.apache.org/dev/release.html#what >> >> The relevant part is in the last paragraph. However, that says >> "convenience" and defines version numbering requirements, but it > does >> /not/ state that the binaries are not sanctioned by the ASF and are not >> part of the official ASF release. >> > > And again, as I and others have stated, this is merely a label with no > content to it. What does "sanctioned (or not sanctioned) by the ASF > mean"? Anything specific? > > Remember, the binaries (or "Object form" in the words of the license) > are also covered by the Apache License 2.0, and sections 7 and 8 of > that license already say that it is provided as-is, and disclaims > warranty and liability. > > In other words, the same license and the same disclaimers apply to > source (which we seem to agree is part of the ASF release) and to > binaries. > > So again I urge the IPMC to mind the seductive appeal of mere labeling > and instead consider whether there is any actual constraints on > activities and behavior for Podlings (or TLP's for that matter) based > on whether something is a source or binary, e.g.: > > 1) Is there some required (or forbidden) way in which a distinction > must be acknowledged in a release vote? > > 2) Is there some required (or forbidden) language on the download webpage? > > 3) Any required (or forbidden) language on release announcements? > > 4) Is there some required (or forbidden) constraint with distribution? > > So far I have heard some on this list suggest the AOO podling is doing > something incorrect, something against ASF policy. But dispute > repeated queries, no one has stated what exactly this is. This is > extremely unfair to the podling, to any podling. It denies us the > opportunity of addressing issues. Is this really how the IPMC > operates? It reminds me of tactics practiced by Microsoft against > open source -- intimate that something is wrong, but never offer > specifics. We call it FUD there. What do we call it at the ASF? > >> It would be very useful if that paragraph were amended to say so >> explicitly. I've had no end of trouble trying to explain to managers > and >> customers that any binaries that come from the ASF are not > "official". > > That may be true for your users, but for mine they would just come > back with, "What does that mean in practice?" > >> Regardless of the policy stated numerous times in this thread and on >> this list, this is not clear anywhere in the bylaws or other online >> documentation (that I can find). >> > > I agree. > >> -- Brane >> >> P.S.: I asked this same question on legal-discuss a week ago. My post >> has not even been moderated through as of today, so referring people to >> that list doesn't appear to be too helpful. >> >> >> --------------------------------------------------------------------- >> 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
