NOTE : THE FOLLOWING IS FOR DISCUSSION PURPOSES. THIS PROPOSAL GOES
BEYOND STANDARD APACHE PRACTICE, AND WILL HAVE TO BE REVIEWED - IF WE
CHOOSE TO FOLLOW THIS ROUTE - BY THE ASF.
There are many legal and political concerns about the Apache Harmony
project, and it behooves us to do the best job we can at all times in
ensuring that the software contributed or created by the community is
as "clean" (in the IP sense) as possible. We do this to protect the
ASF, the committers, and the users of the software.
There are are few issues that come to mind when thinking about
committers :
1) What IP has the committer been exposed to,
and what is the position of the owner of that IP
with respect to the committer's participation?
For example, has the committer been exposed to
copyrighted or patented material, in which an
accidental re-creation would put the project
or users at risk of legal action from the
IP owner?
2) If people have been exposed to code that would be
problematic for us, what can we do to allow the maximum
participation with the minimal risk?
3) How do we ensure that we carefully track our
committers and what they've been exposed to?
To solve, consider the following :
I. Division of Repository
-------------------------
For starters, we can divide our SVN repository into parts :
1) JVM
- VM
- JIT
- GC
- etc
2) Class library
- VM/lib interface :-b
3) Website and Documentation
and we limit access to the SVN to which your contributions have no
"taint" as we understand it at the moment. Because attitudes will
change over time, I think that "taint" can go away as an individual's
issue that causes the 'taint' gets resolved.
We can start with access for website and docs immediately w/o much
consideration for 'taint'.
II. Specific Access Control Lists
----------------------------------
Through fine-grained (as necessary) access control lists for the SVN
repo, we'll allow committers into repos for project components for
which they have no "taint". If they've worked on Sun's class
libraries in the past but no exposure to VM, we keep them from any
class library work we do (if any) and allow them into VM-related code.
I think for simplicity in accounting, we should be conservative and
explicit about access. You are granted access only to repos that you
ask to be granted access to (although with the exception of the
"taint" issue, we should grant to anything asked for...) and
encourage people to keep their personal list small, and ask for
access to be removed if they no longer need it.
III. Strict Limits on Committer Contribution
---------------------------------------------
Committers can only commit contributions to the repositories that
they personally created specifically for contribution to Apache
Harmony. This is the standard stream of fresh original work, small
enhancements and patches that are the normal flow of project life.
The purpose of this rule is to explicitly prohibit re-purposed "bulk"
code that the contributor believes is their original work. We can
still accept those, but wish to track them explicitly.
IV. Be Proactive in Committer Education
---------------------------------------
People sometimes forget or don't understand the intricacies of
copyright and authorhsip, and just want to get work done. Therefore,
we should make a special effort to remind the committers of the
limits, give them clear information on what to do if a commit isn't w/
in the rules, and where to ask questions (and a list of answered
questions for reference).
We could have this as part of a standard svn commit message template,
for example. Other ideas welcome.
V. Required Committer Paperwork
-------------------------------
Each committer is required to complete an standard Apache Individual
Contributor License Agreement. This document asserts that the
contributor is licensing their material to the ASF under the Apache
license and is their original work (there's some other details).
For employed committers where it's appropriate, I'm interested in
what we can do to get validation that the employer doesn't own the
rights to the employee's work in the project. While this is not
applicable to many legal jurisdictions, it is applicable to the US,
and an element of concern here for Apache Harmony. We don't want
code to be contributed that will later be deemed to be a work for
hire or other kind of property of the employer, and thus give a third
party some claim on us or our users.
We would like to know who is contributing to the project. To this
end, we might consider a form asking information like the following.
This goes beyond standard ASF practice, and we would of course have
this reviewed and approved by ASF lawyers and other interested
members of the community (yes, it's fairly conservative...) :
-------------------------------------------
1) Identification
Please provide the following information
- Name (real name, please)
- E-mail and other electronic contact information
- Mailing address (include Country)
- If you have an employer, include name and address of employer
2) Access to Repositories :
Apache Harmony would like to limit write access to repositories
to those that need it, but will grant all that is asked for as long
as there are no 'taint' issues.
- Which components are you interested in working on?
3) Taint
The Project is committed to producing an implementation of Java that
can be licensed freely under the Apache License. To do this,
only those who have not accessed the source code for other
implementations of the applicable project components (or the
source code for the corresponding classes from other Java platforms)
will be permitted to commit to those components.
The following activities are not considered “accessing’ the
source code and would not generally disqualify you from
committing to the related repository here at Apache Harmony
a) Having a copy of src.jar on a computer as long as you never
viewed or edited the contents of the file.
b) While running a debugger on a Java language program, having
had occasion to step into the source code for the implementation
as long as you did not attempt to understand or debug the
implementation code itself.
c) Having implemented "plug-ins" or other component software which
interact with an implementation, but doing so only with
reference
to the published service provider interfaces.
d) Have written or executed test cases that probed the behavior
of an implementation as long as you did so with reference
only to published specifications and interfaces.
With those activities in mind, have you done any of the following
to an
implementation of one or more of the components you listed in
item (2)
above :
- Read some or all the source code for an implementation?
- Fixed defects or performed other maintenance activity on an
implementation?
- Enhanced the source code for an implementation with additional
function,
performance or other qualities of service?
- Ported an implementation to a different operating system or
hardware platform?
- Reverse compiled or otherwise reverse engineered an
implementation?
If you have answered yes to any question above, you may not be
an contributor to
the related component of Apache Harmony unless the copyright
owner of that
implementation either:
a) submits the implementation to this project under the
Software Grant or
the Corporate Contribution License Agreement (the CCLA);
b) if the copyright owner is your current employer, signs a
CCLA and
lists you as a designated employee; or
c) if the copyright owner is not your current employer, submits
a written authorization disclaiming any copyright or
confidentiality
interest in your current or future contributions to this
project.
4) Bulk Contribution
Have you personally written all of the code or other material
that you are intending to contribute to this project?
If not, you need to satisfy both a) and b) below.
a) All of the other authors are committers for the component and
b) You have a written agreement with those who wrote the material
that either gives you ownership of the material or otherwise
provides you sufficient rights to submit this material to the
project on their behalf. (please provide the details of this
agreement)
5) Confidential Exposure
Have you had access to any information regarding a proprietary
implementation of a component that could be considered
confidential? If so, you may be a committer for that component only
if the owner of that potential confidential information submits
a written authorization disclaiming any confidentiality interest
in your current or future contributions to this project.
6) Non-Compete Restrictions
Are you subject to a non-compete agreement that covers the
development of software? If so, you may be an committer only if
the other party submits a written authorization acknowledging that
your participation in the project is not in conflict with the
non-compete agreement.
7) ICLA
Please execute a Individual Contributor License Agreement.
8) Employment Limitations
Are you employed as a programmer, systems analyst, or other
IT professional? If so, you may be an commiter
only if your employer either:
a) signs a Corporate Contribution License Agreement with Apache
and lists you as a designated employee or
b) submits a written authorization for your participation in this
project and disclaims any copyright or confidentiality interest
in your current or future contributions to this project.
-------------------
Comments?
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
