OpenJDK Community Bylaws — DRAFT 9
Mark Reinhold, editor (Oracle), John Duimovich (IBM), Jason Gartner (IBM), Doug Lea (SUNY Oswego), Adam Messinger (Oracle), & Mike Milinkovich (Eclipse)
2011/5/11 20:36 -0700 [9]
 
Preamble

The OpenJDK Community is an association of developers who collaborate upon open-source implementations of present and future versions of the Java Platform, Standard Edition, as defined by the Java Community Process, and upon closely-related projects. The goal of these Bylaws is to foster the long-term health and growth of the Community by enabling and encouraging its members to act in an open, transparent, and meritocratic manner.

Contents
1Overview
2General Roles
Participant · Contributor · OpenJDK Lead
3Voting
Lazy Consensus · Three-Vote Consensus · Simple Majority · Two-Thirds Majority · Unanimous Consent · Absolute · Transparency
4Groups
5Group Roles
Group Member · Group Lead
6Projects
Sponsor · JDK Release Projects · Availability of Specifications and Tests
7Project Roles
Author · Committer · Reviewer · Project Lead
8OpenJDK Members
Expiration · OpenJDK Members Group
9Governing Board
Chair · Vice-Chair · Meetings · Private Session · Open Meeting · Votes · Observers · Quarterly Reports · Annual Review · At-Large Members · Expansion and Contraction · Technical Appeals Process
ALicenses and Trademarks
BTransitioning to these Bylaws
CChange History
1
Overview

The OpenJDK Community is structured as a set of Groups, which are collections of individuals who engage in open conversation about a common interest, and a set of Projects, which are collaborative efforts to produce specific artifacts. There are Community-wide general roles as well as roles specific to Groups and to Projects.

The non-executive Governing Board manages the structure and operation of the Community, monitoring its health relative to the principles set forth in the Preamble. It upholds and maintains these Bylaws, resolves procedural disputes, and ensures that sufficient infrastructure is available to Community members. The Governing Board has no direct authority over technical or release decisions.

2
General Roles

A Participant is an individual who has subscribed to one or more OpenJDK mailing lists. A Participant may post messages to a list, submit simple patches, and make other kinds of small contributions.

A Contributor is a Participant who has signed the Oracle Contributor Agreement (OCA), or who works for an organization that has signed that agreement or its equivalent and makes contributions within the scope of that work and subject to that agreement. Only a Contributor may submit anything larger than a simple patch.

If a Contributor’s employment situation changes such that contributions would no longer be covered by the OCA or its equivalent then the Contributor must relinquish that role by notifying the OpenJDK Lead.

An OpenJDK Member is a Contributor who has demonstrated a history of significant contributions to the Community. OpenJDK Members may propose new Groups and are eligible to vote on new Projects, new OpenJDK Members, and new At-Large Members of the Governing Board.

The OpenJDK Lead is an OpenJDK Member who directs the major efforts of the Community, which are new implementations of the Java SE Platform known as JDK Release Projects. The OpenJDK Lead is responsible for the openness and transparency of the development process used in those Projects and can also settle certain kinds of procedural disputes. The OpenJDK Lead sits on the Governing Board.

3
Voting

Many of the actions defined in these Bylaws are approved or ratified by a group of individuals using one of the following voting methods:

The Simple Majority and Two-Thirds Majority methods have corresponding Absolute variants in which the phrase “of those voting” is replaced by “of those eligible to vote.”

Transparency Except where noted, all votes are to be conducted transparently on the appropriate public OpenJDK mailing list. All voters cast their votes on that list, and the individual who called the vote is responsible for announcing the result at the end of the specified voting period.

4
Groups

A Group is a collection of Participants who engage in open conversation about a common interest. That interest may be in the creation, enhancement, or maintenance of a specific body of code or it may lie in other areas, e.g., quality or documentation.

Groups may have web content and one or more mailing lists. Groups do not have code repositories of their own but they may sponsor Projects, which do.

Groups are expected to operate in an open, transparent, and meritocratic manner. Their alignment with these principles will be monitored by the Governing Board.

Any OpenJDK Member may propose the creation of a new Group or the dissolution of an existing Group. The Governing Board may approve the creation of a new Group by a Simple Majority vote; it may dissolve an existing Group by a Two-Thirds Majority vote.

5
Group Roles

A Group Member is a Contributor who has demonstrated a history of significant contributions to a Group and, as a result, has been granted Membership in that Group. A Member of a Group has write access to the Group’s web content and file repositories.

A Member of a Group may nominate any Contributor to be a new Member of that Group. Such nominations are approved by a two-week Lazy Consensus of the Group’s Members.

A Member of a Group may propose to remove another of that Group’s Members. Such a motion must be approved by a Two-Thirds Majority of the Group’s Members, with the Member in question abstaining.

A Group Lead is an OpenJDK Member who is responsible for directing and coordinating the Group’s activities. A Group’s Lead has:

A Group’s Lead may delegate selected obligations, but not authorities, to other Group Members as desired.

Any procedural decision by a Group’s Lead may be appealed to the Governing Board.

When a Group is created its initial Group Lead is nominated by the proposing OpenJDK Member and approved by a Simple Majority of the Governing Board.

If a Group Lead resigns or departs then a new Group Lead may be nominated by any OpenJDK Member. The nomination must be approved by a Simple Majority of the Group’s Members and ratified by a Simple Majority of the Governing Board.

Any OpenJDK Member may raise a motion to remove a Group’s Lead. Such a motion must be approved by a Two-Thirds Majority of the Group’s Members, with the Group Lead abstaining, and ratified by a Simple Majority of the Governing Board.

The Governing Board may, in exceptional circumstances, remove a Group Lead by a Two-Thirds Majority vote.

6
Projects

A Project is a collaborative effort to produce a specific artifact, which may be a body of code, or documentation, or some other material. Projects may range in scope from small features to entire JDK releases.

A Project may have web content, one or more code repositories, and one or more mailing lists.

Projects are expected to operate in an open, transparent, and meritocratic manner. Their alignment with these principles will be monitored by the Governing Board.

Any Contributor may propose the creation of a new Project. If supported by at least one Group Lead, whose Group will Sponsor the Project, and approved by a two-week Lazy Consensus of the OpenJDK Members, then the Project will be created.

A Group’s Lead may declare that Group to be a of an existing Project. The Members of a Group that is Sponsoring a Project may decide, by a two-week Lazy Consensus vote, to withdraw that Sponsorship.

If a Project loses all of its Sponsoring Groups then it is dissolved. A Project’s Committers may decide, by a two-week Lazy Consensus vote, to request explicitly that the Project be dissolved. The Governing Board may, in exceptional circumstances, dissolve a Project by a Two-Thirds Majority vote.

When a Project is dissolved its materials are archived. A dissolved Project may be re-created by being re-proposed.

JDK Release Projects New releases of Java SE Platform implementations are Projects. Such Projects may only be proposed by the OpenJDK Lead and may only be sponsored by the Governing Board. The OpenJDK Lead is the Project Lead for all JDK Release Projects. Every OpenJDK Member will have the opportunity to propose features for inclusion in JDK Release Projects, and decisions about which features to include will be made in a transparent manner.

Availability of Specifications and Tests Insofar as a Project involves the use of specifications of, and tests for, the code being developed, then all such material as may be required for a Contributor to make timely and effective contributions to the Project should be made available in the Project’s repositories under the appropriate open-source license when possible. If a relevant specification or test is not available under such terms, and a contribution is refused because it violates that specification or fails to pass that test, then those who require the use of that specification or test are obligated to explain the problem to the submitting Contributor and provide reasonable assistance to help resolve it.

7
Project Roles

An Author for a Project is a Contributor who has been granted the right to create changesets intended to be pushed into a specific Project’s code repositories, but does not have the right to push such changesets directly.

A Committer to a Project is an Author who has been granted direct push access to the Project’s code repositories.

A Committer to a Project may nominate any Contributor to be a new Committer to that Project. Such nominations are approved by a two-week Lazy Consensus of the Project’s Committers.

A Committer to a Project may propose to remove another of that Project’s Committers. Such a motion must be approved by a Two-Thirds Majority of the Project’s Committers, with the Committer in question abstaining.

A Reviewer for a Project is an experienced Committer who has the authority to approve changesets destined for code repositories designated by the Project Lead as requiring formal change review. Projects that do not require any formal change review will not have any Reviewers.

A Reviewer for a Project may nominate any of that Project’s Committers to be a new Reviewer for that Project. Such nominations are approved by a two-week Three-Vote Consensus of the Project’s Reviewers.

A Reviewer for a Project may propose to revoke the Reviewer role of another of that Project’s Committers, unless that Reviewer is the Project’s Lead. Such a motion must be approved by a Two-Thirds Majority of the Project’s Reviewers, with the Reviewer in question abstaining.

A Project Lead is a Committer to that Project who is responsible for directing and coordinating the Project’s activities. A Project’s Lead has:

A Project’s Lead may delegate selected obligations, but not authorities, to other of the Project’s Committers as desired.

Any procedural decision by a Project’s Lead may be appealed to the Governing Board.

A Project’s Lead is automatically considered to be a Reviewer, and remains a Reviewer even after leaving the Project Lead role.

When a Project is created, or when its Project Lead resigns or departs, candidates for a new Project Lead may be nominated by the Group Leads of a Project’s Sponsoring Groups. One of these candidates is then chosen by the Unanimous Consent of these Group Leads. If agreement amongst these Group Leads cannot be reached then the OpenJDK Lead will select one of the nominees; this decision may be appealed to the Governing Board.

Any OpenJDK Member may raise a motion to remove a Project’s Lead, unless the Project is a JDK Release Project. Such a motion must be approved by a Two-Thirds Majority of the Project’s Committers, with the Project Lead abstaining, and ratified by a Simple Majority of the Governing Board.

The Governing Board may, in exceptional circumstances, remove a Project Lead by a Two-Thirds Majority vote.

8
OpenJDK Members

Any Group Member or Committer may be nominated to be an OpenJDK Member by an existing OpenJDK Member. Such a nomination must be approved by a two-week Three-Vote Consensus of the OpenJDK Members.

Any OpenJDK Member may raise a motion to remove another OpenJDK Member. Such a motion must be approved by a Two-Thirds Majority vote of the OpenJDK Members, with the Member in question abstaining.

The Governing Board may, in exceptional circumstances, remove an OpenJDK Member by a Two-Thirds Majority vote.

Every OpenJDK Membership is subject to automatic Expiration after one year, but will be renewed upon request. A request for renewal must be received within one year of expiration. An OpenJDK Member whose Membership has expired and not yet been renewed may not exercise the privileges of Membership, except that roles requiring OpenJDK Membership may be retained.

If an OpenJDK Member’s employment situation changes such that contributions would no longer be covered by the OCA or its equivalent then the Member must relinquish the Contributor role by notifying OpenJDK Lead. At this point the Membership will be considered to have expired.

The OpenJDK Members Group consists of all OpenJDK Members. The OpenJDK Lead is its Group Lead. The usual rules for dissolving Groups, adding and removing Group Members, and selecting and removing Group Leads do not apply to the OpenJDK Members Group.

9
Governing Board

The Governing Board manages the structure and operation of the OpenJDK Community.

The Governing Board consists of five Contributors:

The Governing Board is, in part, a legislative body: It is empowered to revise these Bylaws to refine existing processes, to define new processes, and to dispose of processes that are no longer required. Any revision of these Bylaws must be approved by an Absolute Two-Thirds Majority of the Governing Board and then ratified by Two-Thirds Majority of OpenJDK Members.

The Governing Board is also, in part, a judiciary body: It is empowered to resolve any procedural disputes which may arise within the Community. Any procedural decision made by an individual, as described in these Bylaws, may be appealed to the Governing Board. If the Governing Board decides to hear an appeal then a proposed judgement must be approved by a Simple Majority vote.

The Governing Board is not an executive body: It has no direct authority over technical or release decisions. That authority is held, for any given Project, by that Project’s Lead, and in particular by the OpenJDK Lead for JDK Release Projects.

The Governing Board is a Group, with the Chair as its Lead. This allows the Governing Board to sponsor Projects. The usual rules for dissolving Groups, adding and removing Group Members, and selecting and removing Group Leads do not apply to the Governing Board.

Meetings The Governing Board shall meet at least once per calendar quarter, either in person or via teleconference. Meeting minutes will be posted publicly, after being reviewed and approved by the Governing Board.

The Governing Board may decide, by a Simple Majority vote, to hold a meeting or part of a meeting in Private Session, in which case the minutes thereof will not be posted publicly.

The Governing Board may also decide, by a Simple Majority vote, to hold an Open Meeting to which all OpenJDK Members are invited.

Votes Governing Board votes may be conducted during meetings. A meeting of the Governing Board is considered quorate if a majority of its members are present.

Votes may also be conducted asynchronously, via e-mail or similar mechanisms, in which case the voting period shall be seven calendar days unless otherwise stated in the call for votes, but in any case not less than 48 hours. In an asynchronous vote a majority of members must declare themselves present before the end of the voting period, even if they do not vote. An asynchronous vote is conducted transparently unless the Governing Board first votes, by a Simple Majority, to conduct it privately.

Observers The Governing Board may, by a Simple Majority vote, invite specific individuals to attend Governing Board meetings as Observers. Such individuals need not be OpenJDK Members. Observers are welcome to both listen and contribute to the conversation, but they do not have any voting rights. The Governing Board may remove an Observer by a Simple Majority vote.

Quarterly Reports Once per calendar quarter, and one week prior to that quarter’s scheduled meeting of the Governing Board, the OpenJDK Lead shall publish a written report summarizing recent activities in the Community. This report should include:

Annual Review The Governing Board shall conduct an annual review of all of the Community’s Groups and Projects, dissolving any such that are determined to have become inactive.

At-Large Members The At-Large Members of the Governing Board are chosen by a vote of the OpenJDK Members. At-Large Members serve for a term of one calendar year, starting on the first day of April each year.

During a two-week nomination period any OpenJDK Member may nominate an individual who does not currently hold an appointed Governing Board seat to fill one of the At-Large seats. That individual need not already be an OpenJDK Member. An OpenJDK Member may make more than one such nomination.

During a two-week voting period, commencing shortly after the nomination period, the new At-Large Members are chosen from the set of nominees by a vote of all OpenJDK Members.

If an At-Large Member resigns or departs mid-term, with at least two months remaining in the term, then a special election will be held to fill that seat for the remainder of the term.

Expansion and Contraction The Governing Board shall never consist of fewer than five individuals, and it shall always include a Chair, a Vice-Chair, an OpenJDK Lead, and at least two At-Large seats as described above.

The Governing Board may, by an Absolute Two-Thirds Majority vote, add or remove both appointed and At-Large Governing Board seats.

An individual may be nominated to a new or newly-empty appointed seat by any Governing Board member, and is approved by a Simple Majority of the Governing Board.

Technical Appeals Process If a Governing Board member objects in good faith to a technical or release decision made by the OpenJDK Lead then that decision may be appealed via the following process.

  1. The objecting Board member and the OpenJDK Lead will each nominate a neutral third-party technical expert to arbitrate the decision. These two arbiters will together agree on a suitable third neutral expert to join them in creating an Arbitration Panel of three individuals. These experts need not be OpenJDK Members or even Participants.

  2. Within two weeks of the selection of the Panel the objecting Board member will submit to the Panel and the OpenJDK Lead a written description, not to exceed 1,000 words, of the objection.

  3. Within two weeks of the objecting Board member’s submission the OpenJDK Lead will submit to the Panel a written rebuttal, also not to exceed 1,000 words, describing the rationale behind the decision and the way in which it is reasonable.

  4. Within two weeks of the OpenJDK Lead’s rebuttal the Panel will render a decision, made by an Absolute Simple Majority vote. The Panel may, during its deliberations, consider any other information it deems appropriate and may consult with other individuals as necessary.

Both the written submissions and the judgment of the Panel will be published as soon as they are available unless the Panel, on petition from the objecting Board member or OpenJDK Lead, determines that publication is not in the best interest of the OpenJDK Community.

Only three unsuccessful appeals by any particular Governing Board member are permitted in any twelve-month period.

A
Licenses and Trademarks

Participants in the OpenJDK Community collaborate on code licensed under the GNU General Public License (GPL) version 2 with the Classpath Exception and the OpenJDK Assembly Exception, and under other licenses approved by either the Free Software Foundation or the Open Source Initiative.

The “OpenJDK” trademark is owned by Oracle Corporation but will continue to be available for use by others under the terms of the OpenJDK Trademark Notice, or similar terms.

B
Transitioning to these Bylaws

The OpenJDK Community has, since its inception in 2006, been operating under a set of informal guidelines for Groups and Projects. The following changes will be implemented when these Bylaws take effect:

C
Change History

Version 9

Version 8, 2011/4/15