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.

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.

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

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

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.

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.

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:

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

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.

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

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.

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.

An objection to a decision made by the OpenJDK Lead must be
raised no later than two weeks after that decision.

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.

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

Within two weeks of the OpenJDK Lead’s rebuttal the Panel will
render a decision, made by an AbsoluteSimple 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.

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.

Rewrote the Voting section to clarify the differences between
the consensus and majority methods by explicitly defining Vetoes for the consensus methods and refactoring the
text.

In consensus voting, a resolved Veto must explicitly be
withdrawn.

In all types of votes the “good faith” requirement applies to all
those who participate.

The Governing Board will monitor votes to ensure that they proceed
in accordance with these Bylaws.

Rewrote the initial descriptions of OpenJDK Member and OpenJDK
Lead into proper definitions.

Expanded the initial Contributor and OpenJDK Member
definitions to mention to say more about what individuals in these roles
may do.

In the section on Expansion and Contraction, removed the
extraneous paragraph stating that “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.”

Stated explicitly that a Project may have more than one Sponsoring
Group (this was already implied).

Stated explicitly that the initial Project Lead of a newly-created
Project appoints the initial Authors, Committers, and Reviewers (this
was already implied).

Stated explicitly that the initial Group Lead of a newly-created
Group appoints the initial Members (this was
already implied).

Clarified the wording about voting upon motions to remove Group
Members, Committers, Reviewers, and OpenJDK Members to make it clear that
it is the individual who is the subject of the motion who abstains.

Clarified the Licenses and Trademarks appendix to identify the GPLv2 with the
Classpath Exception and the Assembly Exception as the primary
license.

Version 8, 2011/4/15

Any revision of the Bylaws must not only be approved by an Absolute
Two-Thirds Majority of the Governing Board but also then ratified by a
Two-Thirds Majority of OpenJDK Members.

Specifications and tests should be open-source-licensed, but if not
then those requiring the use of closed specifications or tests are
obligated to assist Contributors who do not have access to those
materials.