On 6/5/11 10:16 PM, William A. Rowe Jr. wrote: > On 6/5/2011 11:43 PM, Phil Steitz wrote: >> Agreed. I wish I had a clearer idea of what constitutes a good >> reason to reject an incubator proposal on principle, though - even >> just a good enough reason to reject this one. As long as there is >> some promise of building a community and IP / grant issues are not >> insurmountable, we tend to say yes. In the present case, we are >> avoiding discussion of two core issues: >> >> 0) Where do we draw the line in terms of commercial exploitation of >> the ASF and the apache brand - and how do we even define "exploitation"? >> 1) Do we feel obligated to "do no harm" to OSS communities outside >> of the ASF? >> >> I know there is an easy answer to 1) that "competition is OK; we >> have that inside the ASF ... blah, blah" but that is rationalization >> in this case. We are talking about *the same codebase* and >> basically forking the community. Is that consistent with our >> mission? If not, is that inconsistency a "good reason" to reject >> an incubator proposal? > Actually, we aren't, and the TDF/LO project will tell you as much. > They have made a great deal of progress and diverged from Oracle's > code. In the interim, contributors continue to patch OOo code. So > these are not the same, now. But even if they were, every fork > starts at the same place as its parent; you comment is nonsense. > > A TDF package would likely leverage GPL resources such as icon sets, > fonts, and other desktop elements that we routinely reject from the > ASF code. An ASF package would likely leverage BSD licensed icon > sets and the like (or at least under an appropriate CC license, not > NoDerivatives). These have diverged and will continue to diverge. > > There is a host of code at the center that can, and should continue > to be commons, for the benefit of everyone, and that's what these > lengthy discussions are all about. > > If you want examples of commercial "exploitation", we aught to have > rejected stdcxx (used ongoing by RougeWave after graduation), and > Geronmio (used ongoing by IBM after graduation) etc etc etc. > > There is a real question here; does the fork at the incubator seek > to do something that can't be accomplished at the parent (child, in > this case) project? The answer is yes, the licensing differs, and > the ASF is in a position to obtain the entire codebase under more > liberal license terms than existing commercial exploiters had paid > for, previously. That is a quantitative and qualitative difference. > > But what if a dozen committers came to us from project X, and asked > to begin a fork, for the only reason that they couldn't get along > with the personalities at the existing project. Would we say no? > I tend to doubt it; if there were willing mentors and it appeared > that the proposers were serious in moving the code forward, I guess > that the incubator would say yes. And this is extreme example is > clearly not what we are talking about with OOo. > >> Item 0) is harder. I don't think we have anything close to >> consensus on what is OK. Many of us seem to have just accepted the >> fact that companies use the ASF to "collaborate as peers" and there >> is nothing wrong with BigCos using the ASF as a low risk, low cost >> environment for commercial software development. As long as >> individuals can at least in theory also get involved and the paid >> developers play by the ASF rules, many (most?) of us seem to be OK >> with it. So other than exclusionary practices or smoke-filled room >> decision-making what do we object to? Projects that produce only >> cripple-ware or encourage lock-in to closed source commercial >> products? Projects that damage other OSS communities? >> >> I admit that I am more conservative than most on the issues of >> growth and commercialization that we have been wrestling with >> @apache for as long as I have had the privilege of being involved >> here. That conservatism leads me to recommend strongly that we take >> the items above very seriously and consider taking a more selective >> approach to what we allow in the incubator and a more hard line >> approach on how we engage with commercial entities. I am on the >> fence in the present case. Personally, I think we do have an >> obligation to "do no harm" or at least "do no harm needlessly" to >> external OSS communities and there is more to the ASF that the ASL. >> I also think it is appropriate for us to consider whether we, the >> members of the ASF, should devote the considerable energy and >> resources required to support what looks to me like a commercial >> collaboration in search of a community. > Wow. Did it occur to you that the original project, Apache httpd, > was commercially exploited by vendors *even prior to the creation > of the Apache Software Foundation*?
There is a difference between commercial entities using code vs manipulating communities. Clearly we disagree on this and what the ASF is for. Fine. I hope there is room for both of our views. > And somehow, people still wanted > to have the source code, hack on it, and give back. Even those very > vendors. The second and third project were exactly what you have > described above, Tomcat and XML. Why do you suppose the ASF should > consider undoing the roots from whence it was born? > > Let's spin backwards a bit more... it was abandoned by the authors > who moved on to create entirely closed solutions. And within not > five years the original creation leapfrogged the closed alternatives. > > Every fork creates harm. I'm optimistic that after these very > educational discussions, here and at TDF, this will be one of the > least harmful cases ever. The fork exists, and the prime question > is should the ASF accept transfer of one prong of that fork? Unity > is not an option per Oracle. The fork was created by the TDF in the > hope that the fork does more harm than good. And with some level of > collaboration between OOo-future and TDF, I expect it will, whether > OOo lives at the ASF or elsewhere. > > ASF members wish to devote considerable time and energy to this > project, so exactly who the hell are you to decide what they should > and shouldn't devote that time and energy to? I am just a volunteer who has seen the ASF struggle with growth-related issues for several years now. I think it is a fair question to ask whether we should think about different / more selective criteria for entrance to the incubator. Sorry if asking that question offends you. > Go through the entire > incubator list looking for commercial projects that sought collaboration > by opening their kimono. The results might surprise you, in spite of > how long you've volunteered at the incubator and the projects which > you have mentored. > > I'm sorry that I'm aggravated, but your comments above just don't jive > with my understanding of what the ASF does, which makes them somewhat > questionable in terms of measuring sticks to evaluate incubation here. > There are some questions remaining, but these are not those. This illustrates what I said in my original post - we do not have consensus on the core issues that I presented. Of course, It is possible that I am just a solitary lunatic :) Sorry to have aggravated you. Phil > > --------------------------------------------------------------------- > 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
