Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Message-ID:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=DhvxVkyc69VKSxVqixzhzBY0EQNQrAbGLumDZ63vj7CQKatFukmqORoyfAjkDEF3NjMFhApda93w5oFuheVYHQjUCmn7nWWEQoFPQi6eAFE81dA9v0Vm/knfCBLYihJNehvl/Iq0UR6bJLUZJwVsSwPTK1ifsY5GcQ/et4YWQ3o=
  ;
Message-ID: <20050630211121.79502.qmail@web41205.mail.yahoo.com>
Date: Thu, 30 Jun 2005 14:11:21 -0700 (PDT)
From: Ricardo Morin <morin_ricardo@yahoo.com>
Reply-To: morin_ricardo@yahoo.com
Subject: Re: [Legal] Requirements for Committers
To: harmony-dev@incubator.apache.org
In-Reply-To: <43F59F7E-56A8-4447-96A6-7E57646365A1@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi,

I have some comments on Section I, Division of the
Repository.  In the current proposal, it appears as if
the partitioning of the repository is three big
chunks: JVM, Class library and Website/Documentation.

Due to the very large size of this project, I would
like to propose to break down the Class library part
into the following more discrete modules:

- GUI � Essentially swing
- Client � Awt, java2D, etc
- Core � lang, util, networking, io
- Enterprise � jdbc, corba, jmx, etc
- Security � security and crypto
- XML � Xerces/Xalan
- Tools � javac, jar, jdb, etc

This will move the project more in the modular
direction, which was stated as one of main goals for
Harmony. I believe that communities of interest are
most likely to form around these projects.

So Section I would look like:

I. Division of Repository
-------------------------

1) JVM
2) GUI class libraries
3) Client class libraries
4) Core class libraries
5) Enterprise class libraries
6) Security class libraries
7) XML class libraries
8) Tools
9) Website and Documentation

I would also like to propose to update Section II to
clarify the granularity of the access control list to
the division of the repository above.

Thoughts? Comments?

Thanks,

Ricardo

--- "Geir Magnusson Jr." <geirm@apache.org> wrote:

> 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 
=== message truncated ===


____________________________________________________ 
Yahoo! Sports 
Rekindle the Rivalries. Sign up for Fantasy Football 
http://football.fantasysports.yahoo.com