JCP Ready for the Hard Stuff: Revising the JSPA

During the first Oracle-sponsored JavaOne conference in 2010, representatives from the Java Community Process (JCP), the group that certifies Java specifications, told attendees that changes were coming to the organization. That first year, JCP chair Patrick Curran said, would be about transparency, participation, agility and governance, all addressed in Java Specification Request (JSR) 348 ("Towards a new version of the Java Community Process"). A year later, Curran and company announced plans to merge the two JCP Executive Committees (ECs) -- the SE/EE EC and the ME EC -- under JSR 355 ("JCP Executive Committee Merge"). That plan was approved in September.

That's a lot to accomplish in just under three years, but during a Java Community Panel at this year's JavaOne event, Curran described (again) the issues addressed by those two JSRs as "low-hanging fruit." Now, Curran said, they're ready for the hard stuff -- namely, revising the Java Specification Participation Agreement (JSPA). JSR 358 ("A major revision of the Java Community Process"), which was announced in June, also seeks to modify the Process Document and the EC Standing Rules.

The JSPA sets forth the basic legal structure that allows companies and individuals to participate in the development and distribution of specifications, reference implementations, and technology compatibility kits (TCKs) within the JCP. The current version was created in 2002 through JSR 99. A lot changed in the decade that followed, and sponsors of JSR 358 argue that it's high time for the JCP "to revise this document to ensure that it meets our current needs."

But why does revising this document promise to be such a challenge?

"The JSPA was patched together from what we had at the very beginning," Curran explained, "and now it's this weird mishmash of old-style, Sun-centric [rules and procedures] and the modern way where everybody is collaborating. It's confusing legal spaghetti, and it needs to be revised to ensure that everyone understands the intellectual property flow, that the rights of people who contribute are protected, and that when people go out to implement they have confidence that they have the legal right to do so."

Among the issues being considered in this revision are: independent implementations, licensing and open source, transparency, compatibility policy and TCKs, the role of individual members, patent policy, intellectual property flow, and refactoring and cleanup.

This new JSR is part of what Curran called "a multi-year effort to reform and modify the governance and processes of the organization." What is striking about this ambitious enterprise is that it's being undertaken entirely through the existing procedures -- JSRs are filed to modify the group's governing documents, and the process changes the process.

Curran made no promises about when this JSR might be completed and approved. "This is a much more complex JSR that we've just started, and next year we'll probably still be talking about it," he said.

Posted by John K. Waters on October 5, 2012