Thanks for the changes made. Most look positive and well thought
out. This draft is certainly an improvement over the previous one.
There was just one change that is a step backwards.
gb-members can no longer be just participants, but need to be
contributors. Contributors are in this draft still defined as being
those who assign all their rights to Oracle. Does Oracle really need
the rights to re-license the gb-board minutes to other companies so
they can make closed and proprietary derivatives of the documented
processes of the community?
Of course as others have already pointed out, there were also a lot of
changes that were needed to make the community really open and
meritocratic that weren't yet made in this draft.
The qanda tries to explain why some of these changes weren't yet made,
but some of the explanation was somewhat unclear to me. It says that
"this reduces the near term risk carried by the corporations
represented on the Governing Board". What are these risks precisely?
It also says the "a future version of the Bylaws could well define a
Governing Board in which a minority of seats are appointed". Can it
also define a version without any appointed seats? And if such a
change to make the board more meritocratic is already anticipated,
then why not do it immediately?
"The Chair and Vice-Chair serve, effectively, as proxies for the
OpenJDK Members employed by their companies". Does that imply that such
members are not represented by or allowed to vote for At-Large
members? Isn't there a danger that these companies completely dominate
the board otherwise since they already provide the most "resources"
and so by definition of meritocracy the most members?
I wanted to better explain why the OCA is not balanced, but I can no
longer find a copy. The draft points to http://oss.oracle.com/oca.pdf but that just results in a 404. This is another reason to just make
the OCA an integral part of the community bylaws. If it is so
fundamental to the definition of the core principles and roles, then
it should actually be part of it, instead of being a separate document
that can just disappear. That also makes it easier to discuss whether or
not it is specific enough to serve the interests of the project as a
The community bylaws talk in several places about "the OCA or its
equivalent". What makes something an equivalent to the OCA?
Something I missed while reviewing previous drafts is that there
doesn't seem to be a definition of contribution and/or how/which code
gets integrated into a project. One could assume that the OCA (or its
equivalent) defines that. But, even if you accept that as guiding
principle, those are for new original works. But OpenJDK often sees
contributions of code that are not covered by that definition. Like
the periodic import of util-concurrent, the jaxws drops, etc. All
which contain of existing code, owned by several other parties. On the
other hand we have things like the javax.script rhino code integrated
into the icedtea build process or the icedtea applet and webstart
support, which currently aren't accepted as contributions into OpenJDK
to provide various support of functionality that people expect from a
JDK. So, what defines which code contributions can or cannot be
dropped into an openjdk project?
It might make the definition of "Project" a bit less abstract by
making clear that the eventual goal is to get their artifacts into a
JDK release Project. They might fail to do that of course. But then at
least you have some measure of progress for a project.
The "Availability of Specifications and Tests" section is a very good
start. Please make this so that it is a requirement for new
specifications and tests that a project may adopt. We cannot change
the past. But we can make sure the rules are clear and transparent for
the future. So add something like "for new specifications and tests
adopted by project, this is a must, not a should". Also please make
clear that the "reasonable assistance to help resolve it" should be
made public. e.g. "provide an alternative public test case and/or
publish the relevant portion of the specification requirement
I am really happy about the addition of the section pointing out the
community collaborates on code licensed under GPL. Since this is now
part of the Bylaws, does this also mean the board and members can
upgrade from version 2 to version 3 of the GPL according to the rules
formulated in clause 9? If not, what would be the procedure to upgrade
to version 3?
While looking at the trademark license I was surprised to find version
1.1 at http://openjdk.java.net/legal/openjdk-trademark-notice.html and
in the actual code repositories. A long time ago there was a proposal
for a version 1.2 of the trademark license that would allow IcedTea to
present itself as OpenJDK under some circumstances (swapping out
hotspot for a newer version, backporting stuff from 7 to 6, etc. but
not when swapping out hotspot for cacao for example). It seems this
upgrade never actually happened, but IcedTea does now present itself
as if it is called OpenJDK in certain cases that don't seem allowed by
the 1.1 version. Oops... The 1.2 variant/discussion can be found at
The qanda (15) reply to recognition question points to the convention
of preserving credits in the metadata of the mercurial commits. But
there is IMHO actually a better mechanism in place thanks to the OCA
(see, I am actually able to say at least one positive thing about
it). Since the OCA is not a copyright assignment, you only share your
rights on the contribution, the contributor will keep its copyright on
the contribution. And such copyright statements have to be retained in
the source code.
The bylaws say that there should be "An assessment of the openness and
transparency of the development process and its supporting
infrastructure", but don't really describe sanctions. Currently there
are a couple of proposals for infrastructure changes (bug database,
code review framework) that are in danger of being implemented using
closed proprietary code. This would effectively make it impossible for
contributors to implement effective code changes to this
infrastructure. The licenses section should explicitly also
cover the infrastructure code used and deployed by the project. These
are tools developers will have to work with every day, and so they
should be free to change, adapt and share their modifications to them
with others to make their usage more effective.