2011/6/1 3:10 -0700, m...@klomp.org: > Thanks for the changes made. Most look positive and well thought > out. This draft is certainly an improvement over the previous one.
Thanks -- I'm glad you (mostly) like it. > 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? The Governing Board discussed this topic earlier today. This change was made for consistency across all Groups. The Board's web content is, at least potentially, about more than just the minutes, and in general one needs to have signed the OCA in order to update web content directly, hence the change. It's theoretically possible that someone who objects to signing the OCA would want to run for a Governing Board seat, and it's true that this rule would prevent such a person from joining the Board. The sense of the present Board is that the probability of someone like that actually running for a Board seat is, essentially, zero. > 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. Understood. > 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? I won't attempt to speak for Oracle (or IBM!) on this point. I think the general concern is along the lines of wanting to ensure that significant staffing investments are well-spent. > 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? Yes, of course a future version could define a Board without any appointed seats. That's not specifically anticipated right now, however, and in any case it won't happen immediately due to the risk-reduction goal mentioned above. > "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? No. > 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? As Doug pointed out, the Board membership and voting rules are such that little can happen if more than one member objects. > 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. (That URL has since been restored.) > 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. I see your point, but at this stage merging the OCA into the Bylaws, assuming that's even feasible, would induce another long round of legal reviews, and I (and the Board) think it's relatively more important to get the Bylaws ratified and in place. > The community bylaws talk in several places about "the OCA or its > equivalent". What makes something an equivalent to the OCA? An "OCA equivalent" could be, e.g., a contractual agreement between organizations that addresses related existing commitments but otherwise has much the same effect as the OCA with regard to actions taken in the context of the OpenJDK Community. > 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. ... > ... So, what defines which code contributions can or cannot be > dropped into an openjdk project? I think these sorts of definitions ultimately belong in a separate contribution-process document, not in the Bylaws. > 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. Interesting suggestion; the Board discussed it earlier today. The problem with formalizing such a link is that it would likely be violated on a regular, if not frequent, basis. We want to allow, e.g., Projects that produce useful tools or other artifacts that are not tied to any particular JDK Release Project. The present language around Annual Reviews [1] leaves Project and Group dissolution decisions to the Board's discretion. This seems adequate to the purpose and preferable to further complicating the Bylaws. > 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". Such rules would be problematic from a legal perspective. (IANAL, so please don't ask me to say more.) I and others at Oracle have been working to achieve some of the same effects by other means, and I'm hopeful that some results of those efforts will become visible soon, but trying to mandate this in the Bylaws would actually do more harm than good. > 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? Probably, but I don't know of anyone who's looked into that. > If not, what would be the procedure to upgrade > to version 3? We haven't thought about what that procedure should be, but I doubt it would be difficult to work out. > 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 ... Hmm, thanks for pointing that out. This ball must've been dropped at some point. I'll find someone to look into it. > 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. Good point -- I'll add that to the Q&A answer. > ... 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. The Board discussed this suggestion earlier today. There's some sympathy for the noble goal you've laid out, but at the same time there's a strong desire to be able to use the best tools regardless of whether they're free or proprietary. We're therefore not going to extend the license statement to cover infrastructure code. On a related point, the Board strongly believes that it's critical for the data maintained in the infrastructure to be open to all, whether that data is code, code reviews, bug reports, or other material. In principle it should be possible to fork OpenJDK, though of course none of us wants that to happen. The final draft of the Bylaws will hence contain some new wording to mandate open data, with suitable caveats around reports of security bugs, etc. Thanks very much for your thoughtful and constructive comments! - Mark [1] http://openjdk.java.net/groups/gb/bylaws/draft-openjdk-bylaws-09#annual-review
