OpenJDK Community Bylaws: Second Public Draft
Doug Lea
dl at cs.oswego.edu
Wed Jun 1 05:27:17 PDT 2011
Thanks for the comments! I'll let Mark Reinhold continue
to address those about definitional and procedural details,
but here are a few notes about others:
On 06/01/11 06:10, Mark Wielaard wrote:
> 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 don't think there is an answer to this that doesn't entail
non-public business plans (that I don't know) within each of the
competing companies. The best we can do is make rules amenable to
change if these (and perhaps additional competing companies)
re-assess risks.
> 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?
Note that the membership and voting rules are such that
almost nothing can happen if more than one
non-appointed GB member objects. As others have pointed out,
this isn't a full safeguard, but I think it is enough.
>
> I wanted to better explain why the OCA is not balanced, but I can no
> longer find a copy.
Hmm. Me neither. I've heard that an OCA revision is soon
forthcoming, so maybe that's why.
To address your later points about it: I don't think
there are any plans to remove the non-reciprocity properties
of OCA itself; i.e., that by contributing, you do not
automatically get the right to distribute non-contributed
parts of OpenJDK or builds. Oracle still requires separate
negotiation of distribution rights. A lot of things having
little to do with OpenJDK per se would need to change for
this to happen, so I don't expect any near-term progress on it.
Although it would be nice if there were a better explanation of
how anyone could go about getting such rights, and nicer
still if there were a simple standard way for non-corporate
contributors and researchers to get permission
to distribute non-branded experimental test releases ant the like.
>
> The community bylaws talk in several places about "the OCA or its
> equivalent". What makes something an equivalent to the OCA?
I think this is just a safeguard to avoid the kinds of problems
encountered when the SCA became 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.
I don't see how this is an issue? For example, we let
java.util.concurrent settle elsewhere (under different
packaging) before integrating, but still contribute it under OCA.
>
> While looking at the trademark license I was surprised to find version
> 1.1 at http://openjdk.java.net/legal/openjdk-trademark-notice.html
Thanks for the reminder about adding discussions about
revisions of this to GB todo list!
>
> 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.
I confess that I don't have any good ideas about this, so
have stayed out of that discussion, hoping that others do.
-Doug
More information about the gb-discuss
mailing list