incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cliff Schmidt" <>
Subject RE: proposal: modify incubation application process to require a reference to the code itself
Date Fri, 09 Jul 2004 08:35:38 GMT
Brian Behlendorf wrote on Thursday, July 08, 2004 6:35 PM:

> In walking through the incubation documents (helping a couple of
> groups who have asked me about how to do this) it struck me that
> there was no requirement that the proposal provide a link to download
> and evaluate the code around which a project is being proposed - in
> fact it appears the code itself could be kept secret until project
> acceptance into the incubator.  It seems to me that any honest
> assessment of the merit of accepting a proposal should include a look
> at the code itself, if only to get a gut-check on how maintainable
> and evolveable that codebase might be going forward.  Many proposals
> have provided just such a link despite it not being required. 
> Requiring it would also avoid the situation where someone says "if
> Apache approves it *then* I'll release the code". 
> Thoughts?


If someone wants to propose a project, I think it is quite reasonable
for them to show the code that would be the basis of the project.
However, I think the interesting stuff is in the details here.  For

Q: must the source be licensed under the Apache License before 
project acceptance?

IMO: no

Q: must the source be licensed under an OSI-approved open source 

IMO: I could see arguments either way.  If the purpose is to assess 
the merit of the code itself, 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.  
However, if the purpose of this new rule is also to require commitment
to open source that isn't dependent on the Apache brand, then we would
specify the code must be available under an OSI-approved license prior
to proposing.

Q: what would this mean for project proposals that do not include an
initial code base?  

IMO: While some might say that no project should start in Apache 
without an initial code base, I would personally like to allow for 
this possibility, depending on the make-up of the initial committers
and related communities.  Therefore, I would suggest that any proposal 
that suggests the new project would be built on some particular initial 
code base would need to have that code base available for review.  Any
proposal that does not suggest this (including those that might want to 
base a new project on some other piece of software without actually 
using the old source as a base) would not need to open any source.

Q: if the bar to bring projects into the incubator is meant to be 
relatively low as long as the legal and community issues are reasonable,
should we even be evaluating the code base at all?

IMO: we could probably have long discussions about whether the best
long term future for the ASF requires some degree of technical 
evaluation of projects or not; however, without diving into this issue 
for the moment, I would suggest that perusal of any significant code 
base could be done just for any glaring problems (potential legal 
entanglements with dependencies, inappropriate technical dependencies,
etc).  Problems that are found may not necessarily have to be fixed 
before project approval, but I think it would be nice to allow major
issues to be discovered and responded to during the evaluation of the

Q: how close must the evaluated code base be to the one eventually 
contributed after project acceptance?  In other words, could a proposal 
show most of the planned contribution without having 100% of it ready?  
Could the contributor make changes to the source between the time of 
proposal and the initial grant (e.g. what about changing the license 
header?  what about doing a little more than that?)

IMO: we shouldn't put strict limits on this -- any abuse of the 
intention behind this requirement (such as a significant bait-and-switch 
with code bases) would probably be obvious and could be dealt with on a 
case-by-case basis.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message