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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
