incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Re: How to bring code to Apache?
Date Sat, 04 Nov 2006 12:31:30 GMT
The "important part" here is not to validate the process but the  
provenance of the code being contributed. It does not matter whether  
the code was developed in an open or closed manner, by one individual  
or by many, what we have a responsibility to establish is that the  
code can legally be contributed to the ASF.

Unlike an employer, the ASF has no initial rights to any code; those  
are granted to it through the ICLA when the code is contributed. We  
operate on an ongoing assumption that the committer abides by the  
ICLA and does actually have the rights to contribute that code.  
However, for any body of code we (the ASF) should have the ability to  
ask the committer to reconfirm this, especially if there is increased  
potential that the IP for the code is not owned solely by them (as  
would be the case if it was developed by multiple people or for an  
employer outside a CCLA). AIUI, that is the role of the IP Clearance  
process: to obtain that confirmation.

The openness of the development process used is only relevant here to  
the extent that it exposes the provenance of the code - an open  
process allows us to backtrack and see who created the code and owns  
the IP. It's much more of an issue for the receiving PMC in gauging  
the health of the community.

I'd suggest changing that part to something like "the important part  
is whether anyone else may own any of the code, for example if it was  
developed with other people or as part of your job"

--
Jeremy

On Nov 3, 2006, at 2:09 PM, Henri Yandell wrote:

> On 11/3/06, Daniel John Debrunner <djd@debrunners.com> wrote:
>> Henri Yandell wrote:
>>
>> [snip]
>>
>> > Any thoughts on the below?
>>
>> [snip]
>>
>> > the important part is that the code was developed outside of the  
>> ASF
>> > SVN repository and the ASF public mailing lists.
>>
>> I struggle with what that really means. Code is technically  
>> developed in
>> IDEs on people's machines, not on mailing lists.
>
> Agreed - to the point that I used the text on the documentation page
> rather than trying to paraphrase it.
>
> The other phrase I've heard is:
>
> "Created using the ASF development process"
>
>> If I create a new file for an ASF project it's developed on my  
>> machine
>> and subsequently committed to the project or posted as a patch. So  
>> for
>> sometime the new file was outside the ASF SVN repository and not  
>> visible
>> on a public mailing list.
>>
>> What really makes something developed "inside" the ASF?
>>    - intention to contribute to a project?
>
> Definitely not.
>
>>    - JIRA entry created before the file is created?
>
> Not important.
>
>>    - discussion in mailing list before the file is created?
>
> Openness is a lot of it - so this is often a good example of openness.
>
>>    - creating the file in a local SVN copy from the ASF SVN?
>
> I think this can be a warning sign. If a large 'svn add' commit is
> done, then it's a warning sign to ask whether the change was developed
> openly.
>
> The barracks-lawyer (aka pain in the arse) in me looks at the
> documentation and thinks "What if it was on a public asf mailing list,
> was by people with asf clas but didn't use the svn repos?". I think
> getting the answer for that would not be worth the small effort
> required to file an ip clearance - but if the style was to have an
> external svn and then slowly bring pieces over, it might be worth
> figuring it out. Biggest question here would be 'why not the asf
> svn?'.
>
> Another case that is interesting is 'the big rewrite' style of commit.
> If someone works on the next version of their project on their own and
> then code dumps a lot of changes in, that also seems like it's going
> to need IP clearance.
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>


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


Mime
View raw message