On 18 August 2015 at 18:35, Dennis E. Hamilton <dennis.hamil...@acm.org> wrote:
> 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 [mailto:mar...@rectangular.com] > Sent: Tuesday, August 18, 2015 09:46 > To: general@incubator.apache.org > 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. > > http://www.apache.org/dev/release > http://www.apache.org/dev/release-distribution > > 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: 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 > >
