Community Bylaws Q&A
What happened to the previous Governing Board?
The Interim Governance Board's Charter expired in May 2010, and Oracle chose not to renew it.
Why are a majority of the Governing Board seats appointed?
This reduces the near-term risk carried by the corporations represented on the Governing Board. The Bylaws already allow for the expansion of the Governing Board, so a future version of the Bylaws could well define a Governing Board in which a minority of seats are appointed.
Why are some of the appointed Board seats held by people who have never actually been involved directly in the OpenJDK Community?
It's true that the Chair and Vice-Chair positions are held by business executives who have not yet been active in the Community. These individuals are, however, responsible at their respective companies for directing the efforts of hundreds of engineers who will contribute to the Community. They are also responsible to their companies for delivering supported products based upon JDK Release Projects.
Why are the appointed Board seats held only by Oracle and IBM? What happened to the other major corporate contributors?
Oracle and IBM are the only two companies that, by joining forces, could bring the resources required to ensure the long-term success of the OpenJDK Community. Oracle, through its acquisition of Sun Microsystems, has been by far the largest single employer of OpenJDK contributors. IBM is new to the Community but has fifteen years of extensive experience with what is now the OpenJDK code base and is fully committed to devote significant engineering effort to OpenJDK going forward.
The draft Bylaws state that the Board can revise the Bylaws by an absolute two-thirds majority vote. Shouldn't such major changes be voted on by all Members?
Yes; that's a good idea. The next draft of the Bylaws will state that revisions must be also approved by a Two-Thirds Majority of OpenJDK Members.
Isn't it a little strange to allow Governing Board seats to be held by people who are not OpenJDK Members?
No, not really. The Chair and Vice-Chair serve, effectively, as proxies for the OpenJDK Members employed by their companies. The At-Large members of the Governing Board are appointed only initially; they will thereafter be elected by the OpenJDK Members, who will have the freedom to nominate and elect OpenJDK Members or other individuals as they see fit.
Why do the draft Bylaws define a "Technical Appeals Process" when earlier it is stated that the Governing Board has no direct authority over technical or release decisions?
The Governing Board's only authority over technical or release decisions is via the Technical Appeals Process, which is indirect rather than direct. The Governing Board does not make technical or release decisions itself, but it is responsible for making sure that the Community is functioning well. As part of that responsibility it has the power to ensure that the OpenJDK Lead makes decisions that are fair to all interests.
The Technical Appeals Process says that "only three unsuccessful appeals by any particular Governing Board member are permitted in any twelve-month period." What happens if there is a fourth unsuccessful appeal? Is the objecting Governing Board member removed?
No. If a Governing Board member makes at least three appeals within a twelve-month period, and three of them prove unsuccessful, then that member is not permitted to make another appeal until twelve months after the first unsuccessful appeal. This rule is intended to prevent gratuitous invocations of the appeals process.
Relationship to the JCP
So, does OpenJDK define Java SE, or not?
The definition of the Java SE Platform will continue to be governed by the Java Community Process. Code, specifications, tests, and other materials contributed to the OpenJDK Community will always be available under appropriate free-software or open-source licenses. Such materials might additionally be republished elsewhere under terms defined by the Java Community Process.
Can the Bylaws be revised to ensure that projects and contributions consist of everything necessary under free licenses, i.e., code, specifications, and conformance tests?
That's an excellent idea, but unfortunately such a blanket requirement is infeasible. A large body of existing proprietary tests is used to qualify JDK release builds, and the cost of making those tests available under a free-software or open-source license is prohibitive. A similar situation exists with components whose specifications are licensed only under terms defined by the Java Community Process.
The next draft of the Bylaws will address this issue by including (something like) this paragraph in the section on Projects:
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.
Will the Bylaws explicitly define the minimum (i.e., GPL) copyright, trademark and patent grants that participants will collaborate under, so people know they can rely on them?
The next draft of the Bylaws will state that Participants in the OpenJDK Community collaborate on code licensed under GPLv2 with the Classpath Exception and the OpenJDK Assembly Exception, and other other licenses approved by either the Free Software Foundation or the Open Source Initiative. It will also state that the "OpenJDK" trademark will continue to be available under the terms of the current OpenJDK Trademark Notice, or similar terms.
The draft Bylaws effectively say that only those who assign all rights on their contributions to Oracle can be OpenJDK Members. Is that fair?
As Simon Phipps has observed, there are good historical reasons for the present asymmetrical arrangement, and so it is unlikely to change. Becoming an OpenJDK Member requires making significant contributions to the Community. Such contributions will almost always take the form of code or other materials covered by the Oracle Contributor Agreement or its equivalent, so there seems little reason not to require OpenJDK Members also to have agreed to these terms by first becoming Contributors.
What, exactly, are "simple patches" and "small contributions", as mentioned in the definition of the Participant role?
A small or simple contribution is one that has very little intellectual content of its own. It might fix a typographical or grammatical error in a comment, rearrange a code loop for better performance, or report a failure in existing code but not provide a solution. There is, unfortunately, no universal numerical measure of "small" or "simple" in this context.
There appears to be no way to remove a badly-behaving Group Member from a Group, or Project Committer from a Project. Isn't that a bug?
Yes; the next draft of the Bylaws will fix that.
What mechanism or procedure exists for Participants to submit patches and retain recognition for those contributions?
There is an existing convention for acknowledging such contributions in the permanent metadata of the source-code control system.
The draft Bylaws state that the Governing Board "ensures that sufficient infrastructure is available to Community members". What is the "infrastructure", where does it come from, and who maintains it?
In this context "infrastructure" means the hardware, power, and bandwidth required to host the Internet-based services available to, and maintained by, Community members. These services include, but are not limited to, code repositories, web content, mailing lists, bug databases, and build-and-test systems. Decisions about changes in infrastructure will be made in an open and transparent manner, just like other kinds of decisions. The members of the Governing Board are not necessarily the exclusive infrastructure providers; other individuals and organizations may contribute as well.
Why do the draft Bylaws define both Projects and Groups, and why do Projects need Groups to sponsor them in order to stay alive? Don't the Group Lead and Project Lead roles overlap anyway?
Groups are meant to capture the long-lived, slowly evolving social structure of the Community, whereas Projects are time-bound efforts to create specific artifacts. The Core Libraries Group, e.g., has existed for many years, and its Members participate in a variety of Projects (e.g., JDK 7, New I/O, Coin, and Jigsaw). The Sponsorship mechanism allows a Project that does not have the attention of at least one Group to be garbage-collected, and also provides for the selection of a Project's Lead by the Group Leads of all Sponsoring Groups. Large Projects may well be led by individuals who also happen to be Group Leads; small Projects, by contrast, might be led by Contributors who are not yet even OpenJDK Members.
Why are "JDK Release Projects" called out as a special case?
JDK Release Projects are expected to be the largest efforts undertaken within the OpenJDK Community. The corporate members of the Governing Board intend to make significant commitments of their employees' time to these Projects. To ensure that these investments are managed wisely these members require JDK Release Projects to be Sponsored by the Governing Board and led by a known individual, namely the OpenJDK Lead.
The draft Bylaws state that "an OpenJDK member is a Contributor who has demonstrated a history of significant contributions to the Community". Who determines "significant"? This seems essential, given effectively these members get control over most of OpenJDK as a whole (voting rights, etc.).
The intent here is to enable a self-governing meritocracy, just as is found in other open-source communities. After the Bylaws are in place the only way to become an OpenJDK Member will be to be nominated by an existing OpenJDK Member and then approved by a vote of the rest of the existing Members. By this process the OpenJDK Members will themselves define the meaning of "significant".
Last update: 2011/5/11