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*? 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? 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. --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
