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.
|Participant · Contributor · OpenJDK Lead|
|Lazy Consensus · Three-Vote Consensus · Simple Majority · Two-Thirds Majority · Unanimous Consent · Absolute · Transparency|
|Group Member · Group Lead|
|Sponsor · JDK Release Projects · Availability of Specifications and Tests|
|Author · Committer · Reviewer · Project Lead|
|Expiration · OpenJDK Members Group|
|Chair · Vice-Chair · Meetings · Private Session · Open Meeting · Votes · Observers · Quarterly Reports · Annual Review · At-Large Members · Expansion and Contraction · Technical Appeals Process|
|A||Licenses and Trademarks|
|B||Transitioning to these Bylaws|
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.
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.
Many of the actions defined in these Bylaws are approved or ratified by a group of individuals using one of the following voting methods:
Lazy Consensus — No voters object during a defined period of time. The individual proposing the action must respond in a timely fashion to all questions and objections raised during the voting period. If a voter objects then a reason for the objection must be given and a good-faith effort must be made to resolve it.
As an optimization, if all eligible voters approve before the voting period ends then the action is approved at that time.
Three-Vote Consensus — Three voters approve and no voters object during a defined period of time. If there are fewer than three eligible voters then all voters must approve. Otherwise this method is identical to Lazy Consensus.
Simple Majority — More of those voting approve than object, and at least three voters approve or all voters approve if there are fewer than three eligible voters.
Two-Thirds Majority — At least twice as many of those voting approve than object, and at least three voters approve or all voters approve if there are fewer than three eligible voters.
Unanimous Consent — All of those voting approve.
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.
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 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 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:
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 Group Members as desired.
Any procedural decision by a Group’s Lead may be appealed to 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.
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 Sponsor 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.
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 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:
Full authority over all technical matters relating to the Project;
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 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.
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.
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 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.
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:
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.
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 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.
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.
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.
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.
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.
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.
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 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 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.
Version 8, 2011/4/15