incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <>
Subject Re: apache binary distributions
Date Tue, 18 Aug 2015 19:40:32 GMT
On 18 August 2015 at 18:35, Dennis E. Hamilton <>

> Marvin's comprehensive response is very helpful.
> However, the first described case is about a third-party distribution of
> binaries, even though some or all of the third parties are participants on
> the project.  (I assume the executable was not produced by the project in a
> manner that constitutes distribution and it is not authenticated by the
> project, especially a release manager.)
> Off the top of my head, the trademark policy comes into play, because
> these are not folks acting with their Apache Project hats on.  It seems
> that the first responsibility about this is for the PMC of the
> (hypothetical) project.

Yes that was my analysis of the question: If I decide to produce an
unofficial binary release of Maven without the approval of the rest of the
PMC, I may not call it Maven. If I did call it Maven then the remainder of
the PMC would be responsible for sending me a C&D.

>  - Dennis
> -----Original Message-----
> From: Marvin Humphrey []
> Sent: Tuesday, August 18, 2015 09:46
> To:
> Subject: Re: apache binary distributions
> On Tue, Aug 18, 2015 at 2:02 AM, Kalle Korhonen
> > So what if a project (members) does not vote but unofficially
> > releases binary executable packages, perhaps along with source to some
> > other location than /dist/? Clearly, it's not an official release by
> Apache
> > policy but there the bits are in the wild anyway.
> At Apache, software that is published beyond the group that develops it
> must
> be assembled, vetted and voted in accordance with Release Policy and
> distributed in accordance with Release Distribution Policy.
> Apache is deliberately decentralized in that technical decisions are
> officially delegated to a PMC, but projects are still obligated to follow
> Foundation policy with regards to project governance, IP diligence, etc.  A
> primary function of the Incubator is to prepare projects to self-govern in
> accordance with Apache policy and traditions.
> As a last resort, policy violations eventually escalate to the Board of
> Directors, which has the authority to take actions including termination of
> the project.  But a healthy project self-governs and does not require Board
> intervention -- individual contributors on the ground like you and me are
> expected to address problems before they become severe.
> > I'm asking since at least
> > for many of the Java/Maven based projects it's very easy and inexpensive
> to
> > distribute software through Maven Central. NPM also happily uses Github
> as
> > their central repository so you could technically make lots and lots of
> > "convenience artifacts" available without ever officially releasing
> > anything.
> Apache software does get (re)published to Maven Central, NPM, and any
> number
> of other downstream distribution channels -- it just has to be released in
> accordance with Apache release policy first.
> Apache's release policy is deeply enmeshed with our governance
> institutions,
> our IP controls, and the legal structure of the Foundation.  For example,
> holding release votes helps ensure that small contributors are not run over
> and that power is not consolidated in the hands of the few, jeopardizing
> project independence.  It also helps to ensure that our projects actually
> make
> pure open source releases, something that is really worth fighting for in
> this
> era of privacy violations and aggressive three-letter agencies.
> I've focused more on "how policy is administered" than the "why policy is
> the
> way it is" in this email, because we're deep in a thread and this email is
> long enough.  For those who are interested, I suggest reading the the
> Release
> Policy page, as it captures some of the rationales, sometimes eloquently.
> HTH,
> Marvin Humphrey
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message