On Thu, 2011-05-19 at 14:51 -0700, mark.reinh...@oracle.com wrote: > The second public draft of the OpenJDK Community Bylaws is now > available [1], with an accompanying Q&A document [2]. > > [1] http://openjdk.java.net/groups/gb/bylaws/draft-openjdk-bylaws-09 > [2] http://openjdk.java.net/groups/gb/bylaws/qanda.html
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 whole. 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 publicly". 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 http://mail.openjdk.java.net/pipermail/discuss/2008-March/000687.html 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. Cheers, Mark
