JCP Conflict

What is limiting the competitive aspect, though, is that the JCP has always been discriminatory in the access to the TCKs, since they’ve rarely been published under open source licenses. When that fundamental component of a community initiated and maintained standard is not available to that community under an open source license, you don’t really have a community of equals among implementations. You have a walled garden, where the vendors leading the specifications are managing the toll booths at the gateways and discriminating implementations based on their implementors financial power, as they do since the TCK scholarship was instituted, or based on their current business goals, as the latest conflict of interest shows.

You can get rich and famous within JCP’s walled garden, and that’s OK, a lot of people have gone that route, and emulated the business models used by Sun, IBM, Intel, BEA, Oracle, et. al. based on exclusive control of vital elements of specifications, combined with discriminatory access to them. But if you want to turn that system on its head, you need to chose the right tool for the job, and the right point to apply the pressure on.

FSF has been instrumental in voicing the need for open source Java loud and clear, and getting people on writing the code for it, while it was still unfashionably “idealistic” to do so :). The ASF has been instrumental in making the JCP suck a lot less, while that work was still seen as unfashionably “pragmatic”. :) OpenJDK has been instrumental in removing all sorts of legalese from the JCK license, and I think it will continue to serve the community well in that respect, among many other things.

I don’t think that FSF, ASF or OpenJDK are the right tools for turning the JCP around, though, and forcing the vendors to give everyone equal, non-discriminatory access to the specifications, RIs, and TCKs without NDAs, or other limitations. Only a mandate in the JSPA for open source RIs, TCKs, etc. could guarantee that the community can enjoy the benefits of its standardization work freely. And none of the groups above is the right tool to push that through, due to such organizations always having to represent a complex set of opinions and interests, rather than being able to do the obviously right thing to do and no longer let any JSR with a proprietary component, NDA, or similar nonsense through.

The right tool for that job is a community that will demand equal access to the fruits of its labor for everyone, regardless of their corporate affiliation, size of their bank account, etc, guaranteed by the requirement that all output of community’s specification process be open source, available publicly at no cost, under a patent covenant for every implementation of community standards. A radical thought, I know, almost as radical as talking about open source Java in public was just a couple of years ago. :)

That community is not represented on the EC yet ... but it will be, sooner or later. I think it will be a community of individuals, rather then organizations, that will save Java and the JCP from being driven into the ground by squabbling vendors.

Posted by Dalibor Topic