Re: apache binary distributions
On Thu, Aug 13, 2015 at 8:58 PM, Marvin Humphrey wrote: > On Thu, Aug 13, 2015 at 8:35 PM, Luke Han wrote: > > There's one discussion in Kylin community about to add binary > > package in release, people are really would like to have one: > > > http://mail-archives.apache.org/mod_mbox/incubator-kylin-dev/201508.mbox/%3CCAKmQrOZ_MFUyF_y7HXE7iVMCfJHuuOFuU4T8ibsPWfnw0z2Opw%40mail.gmail.com%3E > > > > For some reason, people (especially in China) is not easy > > to build from source, since there are many library hosted on > > some services which can't be access directly. > > > > Beyond that, the first impression of a project is how to setup > > correctly and successfully, it not make sense to have everyone to > > build from source. And the reality is many projects already DO binary > > package for convenience purpose. > > > > After read so long mail thread here, I have a little bit confusion:-( > > there are too many messages...should we have some clear > > guide or practices for such binary release ? > > Apache produces open source software, and official Apache releases consist > of > source code. Alongside such official releases, projects may offer binary > packages supplied by volunteers which meet certain criteria: > http://www.apache.org/dev/release#what > In some cases, binary/bytecode packages are also produced as a > convenience > to users that might not have the appropriate tools to build a compiled > version of the source. In all such cases, the binary/bytecode package > must > have the same version number as the source release and may only add > binary/bytecode files that are the result of compiling that version of > the > source code release. > > I've always wondered about the "official Apache releases consist of source code". 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. 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. Kalle
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
RE: apache binary distributions
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. - 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
Re: apache binary distributions
On 18 August 2015 at 18:35, Dennis E. Hamilton 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 > >
Re: apache binary distributions
On Wed, Aug 19, 2015 at 3:40 AM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > > 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. > Well, if "Debian" can publish their built Apache Maven as "maven" and "Steve&Nick" can't publish their built Apache Maven as "maven", then the inescapable question is; On what non-arbitrary grounds is one acceptable and the other is not? It can't be "we like Debian, but not Steve&Nick", that is morally weak. Niclas
Re: apache binary distributions
On Tue, Aug 18, 2015 at 6:46 PM, Niclas Hedhman wrote: > Well, if "Debian" can publish their built Apache Maven as "maven" and > "Steve&Nick" can't publish their built Apache Maven as "maven", then the > inescapable question is; On what non-arbitrary grounds is one acceptable > and the other is not? It can't be "we like Debian, but not Steve&Nick", > that is morally weak. We need to distinguish between two situations: * Redistributor starts from official Apache release. * Redistributor starts from unreleased code. "Debian" consumes official Apache releases, and they make changes that are often very small. Whether we should be aggressive in enforcing our trademarks under those circumstances is a judgment call. Should "Steve&Nick" also start from an official release and make changes of similar scope to those made by "Debian", I would agree that the case for enforcing our trademarks would be roughly analogous. However, if "Steve&Nick" are Apache project contributors publishing unreleased code and making an end run around Apache release policy, there's greater cause for concern. * Are other PMC members being denied their right to participate in release decision making? * To what extent does the privileged position afforded "Steve&Nick" undermine project independence? * While our communities strive to maintain codebases in compliance with Apache legal and release policies, we accept that raw repository code may be imperfect between releases. Just how far out of compliance is the unreleased code "Steve&Nick" are publishing under our trademark? * To what extent is the 501(c)(3) status of the Foundation put at increased risk by the actions of this project? What if the practices spread to other projects? If "Debian" were to systematically consume unreleased code from us (aside from patches they've contributed themselves), I imagine we would have similar concerns. But that seems like a weird theoretical. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: apache binary distributions
On Tue, Aug 18, 2015 at 10:15 PM, Marvin Humphrey wrote: > However, if "Steve&Nick" are Apache project contributors publishing > unreleased > code and making an end run around Apache release policy, there's greater > cause > for concern. > On the other hand, if Steve&Nick are contributors publishing unreleased code with VERY LARGE WARNINGS that it is their NON-APACHE APPROVED RELEASE, then the use of the trademark is probably just fine. Indeed, the PMC may view it as a service for, say, testing purposes. The problem comes from the level of confusion. If the Debian package were not a repackaging of a real release from Apache, I would find it very misleading and confusing. As it is, I prefer it because of the packaging convenience and the knowledge that Debian does a nice job of moving the released Apache bits to me in an understandable and manageable way.
