• JSRs by Platform
• JSRs by Technology
• JSRs by Stage
• JSRs by Committee
• List of All JSRs



Register for Site

Use of JCP site is subject to the JCP Terms of Use and the Oracle Privacy Policy


• About JCP
  • Program Overview
  • JCP Process Document
  • Calendar
  • JCP Members
  • Executive Committee
  • Elections
• Get Involved
  • Overview
  • Becoming a JCP Member
  • Java in Education
• Community Resources
  • Overview
  • Tutorials
  • JCP Podcasts
  • Spec Lead Guide
  • TCK Tool & Info
  • License Reference
• Community News
  • News
  • Programs & Awards
  • Press Releases
  • Success Stories
• FAQ
• Contact Us

JCP.next JSR2 list of proposed changes

Updated April 22 2011

Categories

• Transparency
• Participation
• Agility
• IP flow
• Licensing
• Legal issues
• Collaboration
• Fee structure
• Cleanup
• Other

Transparency

Expert Group transparency

• Eliminate confidentiality language from the JSPA.
  • We have draft language (from the JSR 306 draft)

Executive Committee transparency

• (Overflow from JSR1 if necessary.)

License transparency

• (Overflow from JSR1 if necessary.)

TCK transparency

• Changes discussed but not incorporated into JSR1
• Publish lists of incompatible implementations.
  • This is legally risky, and unnecessary (the list of incompatible implementations can be derived from the list of compatible implementations.)
• Publish information about optional features that are implemented.
  • This would be difficult to implement (what level of granularity would we choose?)
• Strengthen the TCK quality requirements
  • Before we do, make sure we're effectively policing existing requirements
• Require more formal reporting requirements for conformance claims.
  • Would require generalizing compatibility requirements.

IP flow transparency

• (Overflow from JSR1 if necessary.)

Participation

• Make the JSPA less intimidating by refactoring into three layers
  • Simple Terms Of Use for non-members who wish to comment on specs in public forums.
  • A simple membership agreement for those who want voting privileges and the right to serve on Expert Groups.
  • The complexities of IP and compatibility obligations are required only for Spec Leads – factor these out into a separate agreement.

Agility

•  Enable implementations before specs are finalized, to gain real-world experience.
  • Must maintain compatibility.
    
  • See Transplant JSR proposals
  • Must declare during JSR submission that this is a Transplant JSR or that it will become one if the JSR doesn't complete within 3 years.
    • The "it will become one" addition is new - need to revise the existing language.

IP flow

• Non-assertion patent covenant.
  • We have draft language. Patrick to circulate this and ask people to get their lawyers to comment
  • May need to add wording to ensure that the non-assert promise transfers with IP ownership.
• Should people be permitted to withdraw their IP grants? At any time?
  • JSPA Section 4D D. Withdrawal of Contributions due to Change in Announced License Terms says Yes.
  • Review this language - make sure it's consistent with possibly-changed processes.
• Fix potential issues with JSPA Exhibit B.
  • Needs legal review
  • TODO: Oracle to start this
  • Others should feel free to offer suggestions.
  • Clarify what is a "duly authorized representative of Employer."
    • Replace "Employer" with "Assignee"
  • Implementation issues:
    • People change employers
      • Require individuals to "re-confirm" their membership each year and at that point to confirm that the Exhibit B is still valid or submit a new one.
      • PMO to require a current Exhibit B whenever an individual (or someone associated with a group where there is not an employer-employee relationship joins an EG.
    • What about members of groups where there is no employer relationship?
      • Eg JUG, research institution, university, open source community.

Licensing

• Define a mandatory standard Spec License.
  • TODO: Patrick to circulate the "recommended" Spec License for comments.
• Recommend (but do not require) standard RI and TCK licenses.
  • Provide separate templates for Independent (open source) and commercial implementors.
  • TODO: Patrick to circulate examples for discussion

Legal issues

• Clarifiy the JSPA as discussed within the EC.
  • Members will be asked to sign the new/revised JSPA (resulting from JSR2) - some may insist on this clarification at that point.
  • Modified JSPA should not grant rights to one player that others don't have.
• Address the issue of where litigation should be located. California, or elsewhere?
  • California is an obstacle to Brazilian state involvement.
  • According to Java Champion Douglas Jenssen this is also an issue within the US. He has said in private mail: "The issue is a legal one, where do legal disputes between Sun/Oracle and a member -- whether individual, sponsored by his employer, or corporation -- get litigated. When I last met with the JCP, the answer was it has to be in California. No public institution such as a state university is going to agree to that, and many corporations will not agree either. Hence I was told there are no members from public universities, only from private ones that choose to agree."
  • The JSPA says: "Any action related to this Agreement will be governed by California law, excluding choice of law rules, provided, however that neither party has consented to the jurisdiction of any court located in the other party´s country of incorporation."

Collaboration

• Changes to make it easier to collaborate with other standards-setting organizations
• Incorporate the Hybrid and Transplant JSR proposals from JSR 306. .,
  • Transplant JSRs (enable incorporation and standardization of work developed outside the JCP)
  • Hybrid JSRs (allowing non-Java implementations of a JSR's specification)

Fee structure

• Modify cost structure (in JSPA) to permit PMO to charge a nominal fee for individuals if this should prove necessary.
  • Eg, "fees for individuals are $250 per year... Fees may be waived at the discretion of the PMO."
• Iincrease fees for commercial entities?
• Explicitly place JUGs in the same category as individuals.

Cleanup

• Phase-out the IEPA provisions (no longer used.)
  • IEPA agreements never expire - we need to deal with this.
  • Encourage existing IEPA members to "resign" or to become full members.
    • There aren't very many of them, so hopefully the PMO can handle this.
  • Remove references to IEPA from JSPA.
    • Need legal approval for this.

Other

• Governance
  • Create an Architecture Council?
    • Council would gather input from implementors, developers, and users and to provide guidance to Platform Expert Groups on platform evolution in the interests of maintaining competitiveness, compatibility and relevance.
    • The membership of this group should be primarily technical, and it must operate by consensus and through negotiation with the Platform Spec Leads.
    • Possible deliverables for the Council:
      • Yearly survey of the community
      • Written responses to Platform JSRs.

Procedural issues

• When will the changes in the JSPA take effect?
  • We can not require that an existing JSR be ruled by new version of the JSPA.
  • Currently there is no requirement that members upgrade to the latest JSPA.
    • Note that section 2B uses the term "expires" but it seems there is no way for a JSPA to expire (merely "terminate") - we should fix this,
  • Will the new version be version 3 (containing significant legal changes?)
    • Presumably yes - otherwise why make the effort to modify it?
    • If so, we want people to upgrade - all members should be operating under similar IP grants.
  • Recommendation:
    • Specify a lengthy transition period (two years?) with a common deadline, allowing ample time for review.
    • All new JSRs must adopt the latest JSPA. This implies that the Spec Lead and EG members must sign it when the JSR is submitted.
• The JSPA also forbids us from applying changes to JSRs that are in-progress
  • "The Process is described on the JCP Web Site (at http:/jcp.org), and may be revised from time to time in accordance with terms set forth in the Process document, provided that no such revisions shall apply to any JSR that has already been approved for development."
  • Recommendation:
    • Modify this language to give us the power to apply Process Doc changes to in-flight JSRs.
      • This wouldn't require us to do so, just make it possible if we wish.
      • The language should specify that at the EC's discretion some or all of the requirements of the Process Document will apply to all JSRs when they next make a formal state-change through the process