incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject RE: Convenience Binary Policy
Date Thu, 23 Oct 2014 16:26:53 GMT
<orcnote> below,

-----Original Message-----
From: [] On Behalf Of Roman Shaposhnik
Sent: Wednesday, October 22, 2014 21:37
Subject: Re: Convenience Binary Policy

On Tue, Oct 21, 2014 at 5:57 AM, Marvin Humphrey <> wrote:
> On Mon, Oct 20, 2014 at 10:26 PM, Roman Shaposhnik <> wrote:
>>> P.S.: Why anyone would think voting on binaries makes any kind of sense
>>> around here is, of course, a different question. I can't even begin to
>>> count the number of times it's been pointed out that binaries are not
>>> Apache releases.
>> And yet that issue keeps rearing its ugly head. Given the amount
>> of traffic I've seen around clarifying some finer (and not so fine)
>> points of release/licensing implication it is about time we start
>> an FAQ on that. Me thinks at least.
> We have several release FAQs spread across the ASF, though -- which, taken
> together, are comprehensive beyond the point of excess.
> The problem is that we lack a concise policy document.  That's where the "ASF
> release policy codification proposal" as worked through on legal-discuss a few
> months ago is supposed to help.
> It's delayed because I got swamped but it seems that the need has not
> diminished.

It would be really nice if you/we could finish this. That said, I
still maintain,
that focusing exclusively on source releases will simplify our life greatly.
IOW, Apache FOO version x.y.z can only designate a source release.

I understand the need of projects like OO to provide binaries of some sort,
I just don't understand why do they have to be 'blessed' by ASF. Once
source gets built and packaged a whole new set of issues kick in. I don't
think the foundation is well prepared to deal with those. We might as
well admit it explicitly.

   That's fine.  However the Apache OpenOffice project has an important
   need to establish the provenance and integrity of the end-user 
   binary distributions it makes.  There are an incredible variety of
   poseur builds that are distributed by third parties for the purpose
   of embedding adware. These also pose as "official" releases, including
   all of the links to support, pinging for updates, etc.  When folks come
   with complaints, the project lists refer them to the authentic builds
   that the project curates.  This is a significant portion of support
   requests to users @oo.a.o and dev @oo.a.o.
      Now that there is code-signing for the Windows (and Mac?) builds,
   this is going to become easier to fend off.  Having the binary distros
   available from the operating-system "store" applications will provide
   further safeguards.
      It is true that the package systems of *nix systems is helpful
   in terms of authenticity and sourcing of OS-integrated builds and 
   their updates.  There is no such source for 80% of the community of
   Apache OpenOffice users.  Before, that community was served by Sun,
   Oracle, Novell, and IBM.  Now, but for the Apache OpenOffice project
   and The Document Foundation, there are no prominent, responsible parties
   for distributions to the Windows and Mac communities of users.
      I do agree that this can be considered a project-specific arrangement
   and does not need to be under ASF governance as strictly as for source
   distributions, so long as the "more-than-merely-convenient" binary
   distributions do not reflect badly on the foundation.  Guidance would
   still be helpful, since there are many projects and podlings need some
   touchstone to encourage good behavior in this area.


P.S. To be super explicit: I'm not saying that binary artifacts should be
banned, rather that a binary artifact compiled by a member of a project
is no different from one compiled by RedHat or Debian and thus requires
no special treatment whatsoever.

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

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

View raw message