incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Howe <cjhowe76...@yahoo.com>
Subject Re: Making a non ASF project, ASF friendly
Date Mon, 15 Jan 2007 04:35:23 GMT

--- Leo Simons <mail@leosimons.com> wrote:

...snip...
> > 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  
> patches.

The purpose of the other project is to be a sort of
impromptu venue for collaboration of things related to
the ASF project.  The ASF project in question (The
Apache Open for Business Project - OFBiz), has a
history of being relatively stable in SVN.  So
generally, contributions that get put back into the
project _work.  Following the one contributor per JIRA
patch approach makes it difficult for people in the
community to share their works in progress.  Since the
goal is to share their works in progress to get them
"inclusion worthy" anything that moves from Project A
to OFBiz will by design have more than one
contributor.

> 
> #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  
> promptly.
> 

Most of the contributions that come from Project A
will be derivative of OFBiz, so jars end up creating
redundant code or make it difficult to incorporate. 

> 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.
> 

While I see #5 being the front runner approach, this
does put quite a burden on the ASF project. In work
that is to be contributed from Project A to the ASF
project the temporary "partnership" wants to
collectively and individually grant the ASF the
license as in #2, but has no mechanism to provide that
grant collectively. 

Thanks for taking the time to ponder this for me,
Chris
P.S. I never thought it would be this hard to give
stuff away for free :-)

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message