harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@apache.org>
Subject [Legal] Requirements for Committers
Date Tue, 07 Jun 2005 22:08:15 GMT

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

     - Enhanced the source code for an implementation with additional  
       performance or other qualities of service?

     - Ported an implementation to a different operating system or  
hardware platform?

     - Reverse compiled or otherwise reverse engineered an  

     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  
         interest in your current or future contributions to this  

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  

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.


    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.



Geir Magnusson Jr                                  +1-203-665-6437

View raw message