incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <>
Subject Re: Making a non ASF project, ASF friendly
Date Sun, 14 Jan 2007 13:58:28 GMT
On Jan 6, 2007, at 10:42 AM, Chris Howe wrote:
> I am currently in the process of setting up a project
> that will hopefully complement the Apache Open for
> Business Project and help get some community newbies
> down the learning curve a bit faster than is currently
> possible with the tools available within the ASF.


> Scenario:
> A project (Project A) is set up on Source Forge by
> individuals as the only legal entities.  Project A is
> setup under the Apache License V2.  What would Project
> A need to do beforehand to ensure that all code
> committed to Project A's SVN is available for an
> existing ASF project to incorporate into it's code
> base in  the following scenarios:
> 1) ASF committer incorporates code from Project A
> directly into the ASF project
> 2) Member of Project A submits a patch file to the
> JIRA of the ASF project
> 3) Non Member of Project A submits patch file from
> Project A to the JIRA of the ASF project.

IANAL, but am pretty sure I'm right :)

#2 is fine in any and all cases, as far as the ASF is concerned --  
for #2, the responsibility is on the member of Project A to ensure he  
can contribute the patch (ie, normally, any IP rights on the patch  
should be his only, and he asserts so by contributing). Our jira  
config requires this for any attachment. It is best if this member of  
Project A contributes the patch under a CLA. The ASF project doesn't  
need to do anything special. Note this should only be done for small  

#1 and #3 are scenarios that are hairy, complicated, harder to audit,  
and, hence, discouraged.

Instead, it is better to follow one of these two scenarios:

4) Project A releases a source and binary distribution (probably as  
a .jar) which can be used directly from the ASF project. The ASF  
project adds information in the LICENSE file about the dependency,  
and doesn't need to do anything else. Project A releases early and  
often and incorporates patches from the ASF project's committers  

5) an ASF project does not want to do #4, so all the developers on  
Project A sign a CLA and a code grant for a sizeable chunk of the  
Project A source. The ASF project follows the incubator's "IP  
clearance" process.

The main advantage is that both #4 and #5 are easy, documented,  
tested, and done often in practice. #1,#3 are possible too, but the  
responsibility to get all the details right lies with Project A's  
PMC, and its much more difficult to get them right than to follow   
either #2 or #5.


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

View raw message