Bylaws

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.

These Bylaws were ratified on 28  June 2011.

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 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. The Governing Board has no direct authority over technical or release decisions.

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. A Contributor may submit changes larger than a simple patch, may propose new Projects, and may take on various roles within Groups and Projects.

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 as recognized by a vote of the existing OpenJDK Members. An OpenJDK Member may propose new Groups, may lead a Group, and is eligible to vote on new Projects, new OpenJDK Members, and the selection of new At-Large Members of the Governing Board.

The OpenJDK Lead is an OpenJDK Member, appointed by Oracle, 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.

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

For all of the methods:

• Votes take place over a period of two weeks, unless otherwise specified.

• Voters may change their votes at any time during a voting period. Only a voter’s most recent vote is counted.

• The individuals participating in a vote must act in good faith.

• The individual who proposes an action must respond in a timely fashion to all questions and objections raised during the voting period.

• 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 calls a vote is responsible for announcing the result at the end of the specified voting period.

The Governing Board will monitor votes to ensure that they proceed in accordance with these Bylaws. In exceptional circumstances the Board may invalidate an individual’s vote, invalidate the entire vote, or take some other unspecified action.

Consensus voting These methods are used for decisions that do not require the full attention of the set of eligible voters.

In the consensus methods the possible votes are Yes, Veto, and Abstain.

A Veto must be accompanied by a justification; a Veto without a justification is invalid. If a Veto is raised then the voter who raised the veto and those who support the proposed action must work together to reach a mutually-agreeable resolution. If a Veto is resolved then the voter who raised the Veto must withdraw that vote by explicitly abstaining or by casting a Yes vote.

These Bylaws use two methods of consensus voting:

• Lazy Consensus — There are no vetoes.

• Three-Vote Consensus — There are no vetoes, and at least three Yes votes or else unanimity if there are fewer than three eligible voters.

As an optimization, if all eligible voters vote Yes before the voting period ends then the action is approved at that time.

The OpenJDK Lead may, in exceptional circumstances, choose to overrule an unresolved Veto; such a decision may be appealed to the Governing Board.

Majority voting These methods are used for higher-level decisions in which it is best to have the full attention of many, if not nearly all, of the eligible voters.

In the majority methods the possible votes are Yes, No, and Abstain. A No vote is not a veto, it is simply a negative vote. A No vote may be accompanied by a justification, but that is not required.

These Bylaws use two basic methods of majority voting:

• Simple Majority — There are more Yes votes than No votes.

• Two-Thirds Majority — There are at least twice as many Yes votes as No votes, and at least three Yes votes or else unanimity if there are fewer than three eligible voters.

The majority methods have corresponding though rarely-used Absolute variants:

• Absolute Simple Majority — There are more Yes votes than No votes, and at least half (rounded up) of all eligible voters vote Yes.

• Absolute Two-Thirds Majority — There are at least twice as many Yes votes as No votes, and at least two thirds (rounded up) of all eligible voters vote Yes or else unanimity if there are fewer than three eligible voters.

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.

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 Lazy Consensus of the Group’s Members.

A Member of a Group may raise a motion 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 who is the subject of the motion abstaining.

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

• The authority to sponsor Projects;

• The obligation to act as a contact point for the Group and to look after the Group’s mailing lists and web content; and

• The obligation, once per quarter, to publish a written report summarizing the recent activities of the Group.

A Group’s Lead may delegate selected obligations, but not authorities, to other of that Group’s Members as desired. A Group’s Lead may delegate all authorities to another of that Group’s Members who is also an OpenJDK Member, but only on a temporary basis.

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.

When a Group is created then its initial Group Lead, once selected, appoints the initial Members.

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.

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 Lazy Consensus of the OpenJDK Members, then the Project will be created.

A Group’s Lead may declare that Group to be a Sponsor of an existing Project. The Members of a Group that is Sponsoring a Project may decide, by Lazy Consensus, to withdraw that Sponsorship. A Project may have more than one Sponsoring Group.

If a Project loses all of its Sponsoring Groups then it is dissolved. A Project’s Committers may decide, by Lazy Consensus, 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.

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 Lazy Consensus of the Project’s Committers.

A Committer to a Project may raise a motion 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 who is the subject of the motion 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 Three-Vote Consensus of the Project’s Reviewers.

A Reviewer for a Project may raise a motion 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 who is the subject of the motion 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:

• Full authority over all technical matters relating to the Project;

• The authority to appoint and remove Authors who are not also Committers;

• The authority to designate specific code repositories as requiring formal change review;

• The obligation to act as a contact point for the Project and to look after the Project’s mailing lists, web content, and code repositories.

• The obligation, once per quarter, to publish a written report summarizing the recent activities of the Project.

A Project’s Lead may delegate selected obligations, but not authorities, to other of that Project’s Committers as desired. A Project’s Lead may delegate all authorities to another of that Project’s Committers, but only on a temporary basis.

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. Such a nomination must be approved by a Three-Vote Consensus 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.

When a Project is created then its initial Project Lead, once selected, appoints the initial Authors, Committers, and Reviewers.

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.

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 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 of the OpenJDK Members, with the Member who is the subject of the motion 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.

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

The Governing Board consists of five Contributors:

• The Chair, appointed by Oracle;
• The Vice-Chair, appointed by IBM;
• The OpenJDK Lead, appointed by Oracle; and
• Two At-Large Members, nominated and elected as described below.

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 public meeting minutes will only record any votes that were taken.

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 simple majority of its members are present; that is, more members are present than absent.

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:

• A summary of notable recent activities of Groups and Projects, including noteworthy procedural decisions;

• A list of Projects that have made major state changes such as publishing a release, integrating into a JDK Release Project, or submitting or completing a JSR;

• A list of Projects that should, in the OpenJDK Lead’s opinion, be considered for inclusion in a future JDK Release Project and its corresponding Umbrella JSR;

• An assessment of the openness and transparency of the development process and its supporting infrastructure; and

• Statistics on committer activity, bug-fix rates, and Community growth.

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 there are no more nominees than there are open seats then each nominee must be approved by a Simple Majority of voting Members. If any seat remains empty after this process then a new election will be held to fill it.

• If there are more nominees than there are open seats then the required number of At-Large Members will be selected from the nominees using the Single Transferable Vote method with the Meek algorithm.

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

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. An objection to a decision made by the OpenJDK Lead must be raised no later than two weeks after that decision.

2. Within two weeks of the initial objection, the objecting Board member and the OpenJDK Lead will each nominate a neutral third-party technical expert to arbitrate the decision. Within two further weeks 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.

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

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

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

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.

The data stored in any infrastructure provided for use by Community members must be made available by some means that enables, without undue effort, the construction of a complete functional clone of that infrastructure and its data as seen by the entire Community.

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:

• The initial set of Groups will be the current set of Groups, with their existing Group Members.

• The OpenJDK Members Group will be created, and the initial set of OpenJDK Members will be those Contributors previously voted into Group Membership. Each such new Membership will expire on the anniversary of the initial registration of that Member in the OpenJDK Community database.

• The initial set of Projects will be the current set of Projects, with their existing Committers.

• The initial Group Leads, Project Leads, and Reviewers will be appointed by the OpenJDK Lead.

• The initial At-Large Members of the Governing Board will be appointed by mutual agreement of the Chair and the Vice-Chair.