harmony-dev mailing list archives

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

On Jun 30, 2005, at 2:11 PM, Ricardo Morin wrote:

> 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

If we ever have to do a class library, this is fine by me.

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

Yes, indeed.  But for now, until we have a compelling reason to  
consider our own class library, we're working out how to work with  
GNU Classpath.

>
> 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'd rather see, if we did classlib :

1) JVM
     a) core
     b) mm
     c) JIT
        i) interpreter
        ii) compiler

2) ClassLibrary
     a) GUI
     b) Client
     c) core
     d) ....
      .....
     z) tools

3) Website and documentation


This is a minor restructuring, but one that seems to make more  
hierarchical sense to me.


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

That or finer, because we may need to partition some of the large  
grain down, such as having a person who has to be kept out of  
jvm.jit.compiler but can work in interpreter.

Right?

geir

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

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org



Mime
View raw message