The normal way this is done is by having someone to submit an ILCA 
(  This makes it clear that their 
contributions are intended to be licensed appropriately and clarifies legally 
their intent.  After that, they should submit patches to the project via JIRA 
so the code is open and transparent and has a clear chain of ownership.  The 
project committers should vet new entries periodically (with the appropriate 
number of nag notes by the contributor if its sitting for a while).  After 
reviewing the code and implementing it the committer would let the contributor 
know.  After sustained contribution (project defined but probably several 
commits to demonstrate commitment and consistency) they can be nominated as a 
new committer.

Normally, the PMC would make a recommendation for a new committer and vote on 
the private thread.  If the PMC votes them in then they get notified. 

Of course this is something the project would need to discuss and decide on how 
they want to do this.

On Dec 9, 2009, at 9:55 AM, Kevan Miller wrote:

> On Dec 8, 2009, at 10:36 AM, Josh Thompson wrote:
>> Hash: SHA1
>> How does it work (legally) for someone in the community to submit a patch?  
>> I've always viewed the process for someone to become a committer to be that 
>> they must first submit some code indirectly (meaning, an existing committer 
>> vets it and then checks it in to source control).  After a few rounds of 
>> submitting code that way, the person can be approved by the community as a 
>> new committer (at which point they submit a CLA and gain write access to 
>> source control).
> Hi Josh,
> Different projects can have different ground rules for what they look for in 
> new committers. Typically, a community will look for contributions from an 
> individual, before considering to invite them to become a committer.
> You can submit a CLA to the ASF at anytime. You don't have to be invited to 
> become a committer first. 
>> However, how do we know that the code they submit indirectly is clear of 
>> copyright and license restrictions?  Is it up to the committer that actually 
>> checks it in to verify it is clear?  If so, how do we go about verifying 
>> that?
> Patches submitted by a contributor should grant the ASF permission to apply 
> the Apache License to their work. Contributors should only do this if they 
> created the patch and they hold the copyright to the code. Having a CLA on 
> file is also helpful in clarifying this...
> There's a radio button on "Attach Files" in Jira for this very purpose:
> "Grant license to ASF for inclusion in ASF works (as per the Apache License) 
> Contributions intended for inclusion in ASF products (eg. patches, code) must 
> be licensed to ASF under the terms of the Apache License. Other attachments 
> (eg. log dumps, test cases) need not be."
> In general, the expectation is on the contributor. If the committer suspects 
> there is a problem (e.g. the contributor does not hold the copyright or that 
> the code may have license restrictions), then this is something that the 
> committer (and other project members) should investigate.
> --kevan

Matt Hogstrom

A Day Without Nuclear Fusion Is a Day Without Sunshine

Reply via email to