-
A very astute move by Oracle here. They are proposing that the seat on the Java Community Process Executive Committee vacated by Apache should be filled by the São Paulo-based Brazilian Java User Group SouJava, represented by my charming and smart friend and former Sun colleague Bruno Souza (who incidentally also represents ForgeRock in Brazil and is a co-author here on webmink.com).
I think that given the circumstances this is the best outcome that could have been achieved and I hope Bruno and SouJava will be able to use their new position of influence to fix the broken things (like the opaque decision-making and the ability to have FOSS-hostile licensing terms on JSRs).
Also:
-
Great, balanced reference on the issues surrounding your privacy on the internet. Very worthwhile reading.
-
This is rather a long letter, but it conveys all the unease that was tangible at Campus Party among the software livre, digital inclusion and free culture camps.
Wild Webmink 
[…] very astute move by Oracle here,” Phipps wrote on his personal blog. “I think that given the circumstances this is the best outcome that could have been achieved […]
I’ve posted a detailed response to Simon’s concerns about JCP secrecy at http://blogs.sun.com/pcurran/entry/for_your_eyes_only
Thanks for the response, Patrick, and for being willing to discuss this important topic. I have had feedback from various community members asking why I even think the JCP is relevant post-Apache. I have explained to them that there’s still hope, that it’s still worth engaging. Your willingness to engage in discussion encourages me to carry on!
When I said:
I was referring to the situations you and especially Mark refer to.
Concerning transparency, the JCP has for over a decade had too many places where the option of secrecy is still available. While the improvements you describe are a good gesture, the JCP needs to move to a model where there is no secrecy anywhere apart from truly exceptional circumstances involving personal privacy, and even then the use of secrecy must be justified publicly and open to challenge. Having casual secrecy even as an option breeds mistrust and prevents the JCP being respected in open communities.
You didn’t respond to my comment on JSR terms. As Mark says both here and on your blog there is the serious anomaly that while open source community members may be able to engage openly in creating a specification, it is perfectly acceptable in the JCP (especially for the platform JSRs) for it to be licensed in a way that means even those contributors themselves are unable to use the specification. I understand the problem of changing legacy JSRs, but the JCP needs to move to a model where license terms for all new JSRs must be licensed in such a way that they can be freely implemented under the terms of any OSI-approved license.
It’s these changes I hope SouJava will be able to advocate and achieve through their membership of the JCP. Without them, the current “trial separation” between the JCP and much of the open source movement could well become a divorce.
Thanks for the reply Patrick, but I don’t think it really addresses one of the main points Simon makes. The secrecy often pops up in the JSR licensing terms.
For example as Simon points out the JCP doesn’t prevent specs, TCKs and/or reference implementations to be published under GPL-compatible terms.
This causes the weird situation that as you say the specification is actually done mostly in the open (for example through OpenJDK), but then when the spec/tck/ri is published the same people who worked in the open are then no longer allowed to refer to it since the final JSR terms are incompatible with the way the open community works.
See also my older blog post on this:
http://gnu.wildebeest.org/blog/mjw/2010/11/28/moving-java-forward-through-the-jcp/