On Wed, 2011-06-01 at 08:27 -0400, Doug Lea wrote: > 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.
But it is kind of hard to amend the rules if we don't actually know the risks we are guarding about in the first place :) > 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. That really wasn't my point. And I think the new license section in the bylaws, plus the previous statements that the rights granted by the GPL should be interpreted like the FSF as license steward says, already gets you a long way there. The only thing missing is a link from the OCA to that promise in the Bylaws. I will write a bit more on why I think the OCA as it is, isn't protecting the rights of contributors, when (a new?) version reappears. But basically it comes down to the OCA being way too broad. It does not just allow Oracle to relicense your contribution to another party (without your knowledge), so they can make some proprietary spinoff. But also grants rights nobody seems to think are a good idea. Like allowing Oracle to take contributions, transform them into specifications, reference implementations and JSRs that then come with terms that actively hurt openjdk contributors by being GPL-hostile and/or blocking other free software projects from implementing the same contributions. > > 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. So, this is just a naming issue. Not a difference is rights granted to/from Oracle? If so, then the bylaws should just state that. > > 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. OK, I didn't know you required all util-concurrent contributors to also sign the OCA. Then util-concurrent was a bad example. I just listed some that I had recently see come through. But there are others, like w3c, zlib, xalan, xerces, sax, etc. and of course the ones that didn't make it through I mentioned like rhino, netx, etc. Those get contributed and imported without such a contribution under the OCA, just because not all owners can or want to sign it. Since this does work some of the time and not others, what are the actual contribution rules for the project? Some of these things are now maintained inside IcedTea, which is fine, but apparently not for any good reason, since other contributions are inside OpenJDK itself already. > > 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! Sorry! I didn't mean to. It was an accident really. I was under the impression it had been upgraded to 1.2 a long time ago. But since the oca was missing, I thought it better to click all links in the bylaws to make sure nothing else was. > > > > 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. My suggestion would just be to be clear that all code of the project, including infrastructure code, is covered by the license section of the bylaws. Thanks, Mark
