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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to