Return-Path: Delivered-To: apmail-incubator-general-archive@www.apache.org Received: (qmail 35133 invoked from network); 12 Jul 2004 19:34:58 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 12 Jul 2004 19:34:58 -0000 Received: (qmail 98603 invoked by uid 500); 12 Jul 2004 19:34:55 -0000 Delivered-To: apmail-incubator-general-archive@incubator.apache.org Received: (qmail 98510 invoked by uid 500); 12 Jul 2004 19:34:55 -0000 Mailing-List: contact general-help@incubator.apache.org; run by ezmlm Precedence: bulk X-No-Archive: no List-Post: List-Help: List-Unsubscribe: List-Subscribe: Reply-To: general@incubator.apache.org Delivered-To: mailing list general@incubator.apache.org Received: (qmail 98380 invoked by uid 99); 12 Jul 2004 19:34:54 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [66.112.202.2] (HELO mail.devtech.com) (66.112.202.2) by apache.org (qpsmtpd/0.27.1) with SMTP; Mon, 12 Jul 2004 12:34:51 -0700 Received: from localhost ([127.0.0.1]) by mail.devtech.com (JAMES SMTP Server 2.2.0) with SMTP ID 841 for ; Mon, 12 Jul 2004 15:34:47 -0400 (EDT) From: "Noel J. Bergman" To: Subject: RE: proposal: modify incubation application process to require a reference to the code itself Date: Mon, 12 Jul 2004 15:33:54 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <40F262F5.90009@Golux.Com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N As I see it, community is our concern. Either we have a strong community coming in, or we believe that we have the ability to form one around some catalyst. If we are accepting a contribution based upon its community, the quality of its code is probably not a pre-determining criteria, and we would be unlikely to terminate the project when we do see it. On the other hand, perhaps we might have a group of ASF people interested in some problem domain, but who feel that without a major starting point, the ramp up effort is too great. Someone comes along and proposes to contribute a starting point. In that scenario, the code could be an important desiderata, and we do risk terminating the project if the community decides that the seed isn't strong enough. That said, if there are ASF Members who want to incubate a project, I would prefer that we give them a chance to succeed, even if the endeavor ultimately fails. I don't share the concern that "it's code that the ASF will become responsible for maintaining." I don't see that we have an obligation to maintain a failed project, although I would put the CVS tarball in the archives, or preferably just do an svn remove, as an audit trail. Nor do I believe that there is any requirement for the Incubator to expend extraordinary efforts to make a project successful beyond that which ASF Members are willing to contribute as mentors. An IP pre-review could cause a problem. IP made available for review would have to be free of encumbrances. We do not want a situation where people who have reviewed it become tainted. Certainly that can be the case if the license were a proprietary one, but it does not seem to matter if the license is an OSI-approved one or not. Claims can be made based upon (L)GPL as easily as upon more classically recognized proprietary licenses. So, no, I do not agree that "any legal mechanism that provides for anyone in the community to conveniently read the source should be acceptable, even if the license restricts distribution, for instance." If you want it in blunt terms, I would not want to see a situation where someone can poison the well. IANAL, but until we have an encumbrance-free contribution, I don't believe that anyone, including prospective mentors, should be reviewing it. And since the contributor may not want to sign the Software Grant until a decision has been made to accept the project, if we make it a *requirement* to review the code prior to Incubation, we could have a Catch-22. Therefore, since I feel that we could have valid reasons for accepting a project without a prior review, and since performing a prior review could create problems, I'm not sure that we want to make this a mandate, and lose a perfectly good project. --- Noel --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org For additional commands, e-mail: general-help@incubator.apache.org