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
