JCP.next Master List of proposed changes

Updated March 28 2011

TODO for each item

• Prioritize.
• Process Doc or JSPA change.
• Decide whether in JSR1 or JSR2.
• Do we have consensus or need more discussion?
• Do we already have draft text?
• Find volunteer to flesh out the idea

Documents to be modified

• The JSPA
  • Normative
• The Process Document
  • Normative
• The EC Members' Guide
  • Currently non-normative: incorporate into, or reference from the Process Document; make normative?
  • Review Appendix A of Process Document; combine this with the (currently non-normative) EC Members Guide.
• The Spec Lead Guide
  • Non-normative: referenced from Process Document

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,
  • The JSPA also forbids us from applying changes to JSRs that are in-progress:
  • 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.
• When will the changes in the Process Document take effect?
  • The JSPA currently prohibits us from applying Process Document 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 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 the requirements of the Process Document will apply to all JSRs when they next make a formal state-change through the process.

Transparency

Expert Group transparency

• JSPA changes (JSR2)
  • Eliminate confidentiality language from the JSPA.
    • We have draft language (from the JSR 306 draft)
• Process Document changes (JSR1) (draft language required)
  • All significant business must be carried out on public mailing lists.
    • EG-private mailing list may be maintained for administrative matters.
  • Issues must be tracked through a publicly viewable issue tracking mechanism.
  • Expert Groups must respond publicly to all comments before JSRs can move to the next stage.
    • We have language requiring comments to be published, but not requiring responses - this must be tightened up.

Executive Committee transparency

• Process Document changes (JSR1) (draft language required)
• Add semi-annual EC meetings that all JCP members are free to attend and where the agenda chosen from topics suggested by the membership.
  • Meeting schedules are currently specified in the EG Members Guide rather than in the Process Document. Fix this by merging the two documents.
• Create a public alias (with archive) for members to provide feedback to the ECs.
  • We can do this now, without any Process Doc or JSR changes.
  • Nevertheless, should mandate it in the EC Processes portion of the new docs.
• Need some language to address Undocumented Practices.
  • For example, PMO/Oracle Legal review of license terms.
• Incorporate EC Members Guide recommendations into the Process Doc as normative requirements.
  • Meeting schedules, quorum requirements.
  • Voting procedures.
  • Publish EC meeting agenda in advance.
  • Specify whether agenda items are for discussion or for action.

TCK transparency

• Permit and encourage publication of aggregate TCK test results so users can see who's compatible and who's not.
  • Oracle TCK licenses require confidentiality - JSPA change could explicitly mandate openness.
    • TODO: Oracle should own this - draft some language for the JSPA.
• Permit and encourage the discussion of individual TCK test results.
  • We permit this now for OpenJDK testing - generalize this to commercial testing.
• TCK documentation (including Compatibility Requirements) must be publicly available.

Individual membership

• Fix potential issues with JSPA Exhibit B.
  • Needs legal review
  • TODO: Oracle to start this
  • Others should feel free to offer suggestions.
• Individual members' votes - how to avoid ballot-stuffing?
  • Recommendation:
    • Change this language in the Process Doc: "All JCP Members are eligible to vote in a ratification ballot subject to the provision that if a Member has majority-ownership of one or more other Members, then that group of Members will collectively have 1 vote." to “...has majority-ownership of or is the employer of one or more other Members...”
      • It might be difficult for the PMO to enforce this in practice, but we would have the authority to do so if necessary.
• Neither the JSPA nor the Process Doc mentions the fee structure. One or other document should - perhaps permitting the PMO to adjust on the fly.
  • Modify cost structure to permit PMO to charge a nominal fee for individuals if this should prove necessary.
    • Eg, "fees for individuals are $50 per year, but are currently waived..."
    • See Wayne Carr document for justification.
  • Should we increase fees for large corporations?

IP flow

• Non-assertion patent covenant.
  • We have draft language. Patrick to circulate this and ask people to get their lawyers to comment

Licensing

• Require that when the license terms associated with a JSR are significantly changed from the previous release, this is explicitly called out.
  • Recommendation - change:
    • definition - Change Log: An area accessible from the Spec Page that lists all changes made to the Specification after Final Release. There are three sections: PROPOSED (changes not yet made to the Specification), ACCEPTED (changes made), and DEFERRED (change items to be considered in a new JSR).
  • To:
  • definition - Change Log: An area accessible from the Spec Page that lists all changes made to the Specification and Licenses after Final Release. There are four sections: PROPOSED (changes not yet made to the Specification), ACCEPTED (changes made to the Specification), DEFERRED (changes to be considered in a new JSR) and LICENSING (changes to licensing terms.)
• Note also that strictly speaking the change log does not list all changes "after Final Release" but only those since the previous release. We should therefore change "after Final Release" to "since the previous release."
  
• Clarify the requirement to disclose licenses, particularly if different licenses are available for various types of implementation or different fields of use and require that offered licenses must be available to anyone who is willing to sign.
  • Recommendation - change this JSPA language:
    • The Spec Lead (including Sun) for a JSR approved by the JCP shall offer to any interested party licenses concerning the RI and TCK -- and also the TCK separately when developed under any JSR submitted hereafter -- on terms and conditions that are non-discriminatory, fair and reasonable.
  • To:
    • The Spec Lead (including Oracle) for a JSR approved by the JCP shall offer to any interested party licenses concerning the RI and TCK -- and also the TCK separately when developed under any JSR submitted hereafter -- on terms and conditions that are non-discriminatory, fair and reasonable. RI and TCK licenses should permit both commercial and non-commercial implementations and should be granted to all who agree to their conditions.
• 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

Agility

• Time-outs for inactive JSRs (JSR1) (we have draft language)
• See JSR Renewal Ballot suggestion from JSR 306
•  Enable implementations before specs are finalized, to gain real-world experience.
  • Must maintain compatibility.
    
• See Transplant JSR proposals from JSR 306
• Better procedures to remove or replace non-responsive spec leads and to deal with bankrupt or defunct spec-lead organizations.
  • The Dormant JSR language in section 4.1.2 of the Process Doc apply only to completed (in-Maintenance) JSRs.
    • We need similar sanctions for in-progress (but stalled) JSRs.
  • Do we need to modify the JSPA to permit withdrawal of contributions?
  • TODO: Michael to review and suggest changes.
• Section 2.1.3 of Process doc: Uncooperative or unresponsive Expert Group Members seems incomplete. It starts by talking about how to deal with EG members but the proposed remedies then address the Spec Lead role. Clarify.
• Clarify the Maintenance process
  • Spec Leads want the EG to persist after Final Release. The Process Doc states that the EG must disband.
    • Recommendation:
      • Rplace the Expert Group with a Maintenance Expert Group.
        • Initial membership of the MEG would be recruited (automatically?) from the EG?
      • We need to maintain the history of which members were on the EG when it completed its work, but it should also be possible for EG to evolve.
      • We really should "snapshot" the membership at every Release.
  • Clean up Maintenance Release requirements. Currently there's no absolute requirement for the Maintenance Lead to actually deliver an updated spec, RI, and TCK. (The process simply says "the maintenance changes will be considered final when the RI and TCK are synchronized with the Specification.) We should require a formal Maintenance Release just as we do a Final Release.
  • Clarify requirements for RI and TCK to be posted within x weeks of Final Release (and Maintenance Release?)
• How to "undo" if materials not posted?
  • PMO to draft something

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.
    • Oracle-legal have drafted a TOU document. It's still long and potentially intimidating, but less so than the JSPA.
  • A simple membership agreement for those who want voting privileges and the right to serve on Expert Groups.
    • The IEPA is not a useful starting point since it still includes all of the Spec Lead obligations; it's no better a starting-point than the JSPA itself.
  • The complexities of IP and compatibility obligations are required only for Spec Leads – factor these out into a separate agreement.
• Clarify Terms of Use for collaboration software used by Expert Groups
  • Should ensure sufficient IP grants, but not impose requirements more strict than the JSPA
• See Wayne Carr document for explanation.
• Recommendation:
  • During the submission process the Spec lead tells the PMO what collab software will be used.
  • Oracle legal reviews the Terms Of Use and reports to the EC.
  • EC approves, or requires an alternative.
    • If OK - add to approved list. If not, look elsewhere
  • Must deal with possible changes to terms of use over time.
    • May need to review each time, even if previously reviewed.
  • TODO: Patrick to talk to Oracle Legal about this.
  • This is probably JSR2 rather than JSR1 (more effort - legal work required)
    • Is ir a Process Doc or a JSPA change?
• Non-controversial, but we have no draft language yet
• No barriers to participation in Expert Groups.
  • Requests to join EGs and the Spec Lead's responses must be made in public.
• EG members who do not participate should be penalized.
  • Lose voting privileges. Look at OASIS, W3C.
    • This assumes the EG is operative by voting rather than by consensus.
• Penalties for EC members who do not attend meetings or do not vote.
  • First step: lose voting privileges (which would solve the quorum problem.)
    • Would need to change the definition of quorum to be "of those who are eligible to vote."
    • Suggestion from Eduardo: if you miss two meetings in a row you lose voting privileges. Can restore by attending two meetings in a row.
  • Second step?
    • Lose membership if...
      • Miss x meetings in a year...
      • Losing voting privileges more than x times per year...
  • If people routinely miss meetings, members who attend only occasionally are "disruptive"

Collaboration

• Enable and encourage the establishment of more formal relationships with other standards bodies.
  • Needs more discussion.
• Incorporate the Hybrid and Transplant JSR proposals from JSR 306.

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.
• Remove Process Doc section 1.1.4 J2ME building blocks
• Correct typos and errors in JSPA.
• Correct typos and errors in Process Document.
• Remove the ambiguity of the term Spec Lead in the Process Document (sometimes it refers to the Member and sometimes to the person representing the Member and leading the EG.)
  • See Wayne Carr document for explanation

Branding and compatibility

• Emphasize the value of compatibility & the brand and the risks of using incompatible implementations.
• Relax all-or-nothing compatibility reqiurements?
  IN PROGRESS: Patrick to give the the compatibility presentation to EC...
• Publish lists of compatible implementations and report what optional features are implemented.
• Publish lists of incompatible implementations.
• No JSPA or Process Doc changes required for these proposals – Oracle/PMO commitment is sufficient?
• More formal reporting requirements for conformance claims?
• Where would the language be written? In TCK licenses?
  • Too hidden?
  • How to make this more public?
• What would the remedy be if someone makes a false claim?
• Oracle to drive this...

Miscellaneous

• Clarification of 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.
• Transplant JSRs (enable incorporation and standardization of work developed outside the JCP.
  • Need some use-cases?
  • Early availability was an issue. Permitting implementations before specs go final. IP-flow issues?
• Hybrid JSRs (allowing non-Java implementations of a JSR's specification)
• Discuss these two next week - notify EC members in advance we'll be doing so - invite those who are interested to participate - review the actual docs/drafts

Jurisdiction

• 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."

TODO

• Legal collaboration between Oracle and others' lawyers.