JCP.next Master List of proposed changes

Updated Feb 23 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

Procedural issues

• Decide whether the changes introduced in JCP.next should be applied to other JSRs that are "in flight."
  • We can not require that an existing JSR be ruled by new version of the JSPA.
  • 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."
    • Should we modify this language to give us the power to apply?
      • This wouldn't require us to do so, just make it possible if we wish.
• Clarify when/whether members must upgrade to the new version of the JSPA.
  • Currently there is no obligation for them to do so.
    • 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
  • We should encourage upgrading. Hopefully the new version will be attractive.
    • It's a big effort for corporations to review the revised agreement
  • Will the new version be version 3 (significant legal changes?) If so, we would want people to upgrade.
    • Not good if members are operating under different IP grants - we want everyone to have the same terms.
    • May need to give people a grace period to give time to review.
    • Suggest: Long transition period (two years?) with a common deadline
  • At the very least, the new JSPA must apply to all new JSRs - for the Spec Lead and EG participants

Transparency

Expert Groups

• Eliminate confidentiality language from the JSPA.
  • We have language (from the JSR 306 JSPA draft)
  • We said we'd target this for JSR1, but as a JSPA change it should wait for JSR2.
  • We didn't reach consensus on this. John Rizzo argued that confidentiality should still be an option, but that we should do a better job of explaining that it should be used only in exceptional circumstances. (This may not be easy to do in a legal document.)
  • Don noted that whatever decision we make Expert Groups should not discuss product features, pricing, etc.
  • During EC meeting on Feb 15 members agreed that confidentiality language should be removed from the JSPA.
• All business must be carried out on public mailing lists.
• Issues must be tracked through a publicly viewable issue tracking mechanism.
  • These two are non-controversiol. We don't have draft language. Should target for JSR1.
• 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 response - this should be tightened up.
  • Non-controversial - target for JSR1.
• 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.
• JSR2? (more effort - legal work required)
  • Is this a Process Doc or a JSPA change?
  • Do in two stages?
• Non-controversial, but we have no draft language yet.

Executive Committees

• Add semi-annual EC meetings that all JCP members are free to attend and where the agenda chosen from topics suggested by the membership.
• Create public alias (with archive) for members to provide feedback to the ECs.
  • Non-controversial, JSR1, Process Doc change.
  • Need draft text.
• Need some language to address Undocumented Practices.

TCKs

• Permit and encourage publication of TCK test results so users can see who's compatible and who's not.
  • Secrecy rules may be specific to Oracle licenses; JSPA change could explicitly mandate openness.
    • TODO: Oracle should own this - draft some language
• TCK documentation (including Compatibility Requirements) must be publicly available.
• Can we/should we publish the tests too?
  • TODO: Oracle to review this

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?
  • Need creative legal suggestions
    • Self-employed individuals should be treated differently?
    • We need suggestions. Brainstorm this.
• Modify cost section of JSPA to permit PMO to charge a nominal fee for individuals (if this should prove necessary)
  • See Wayne Carr document for justification.
  • Simple change. Since JSPA, target for JSR2.

IP

• Non-assertion patent covenant.
  • We have draft language. Patrick to circulate this and ask people to get their lawyers to comment
• IP grants flow directly to implementers, not via Spec Lead
  • Justification? TODO: Patrick to circulate this.
• Clarify what we mean by FRAND.
  • We agreed we should probably strike this since we're unlikely to reach consensus.
  • During EC meeting on Feb 15 members agreed to drop this item.

Licensing

• Require that when the license terms associated with a JSR are significantly changed from the previous release, this is explicitly called out.
  • Require change log for licensing changes.
  • Process doc change, JSR1, non-controversial.
  • Suggest changing
    • 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.
  • Can we require every variant to be disclosed? No.
• Require that offered licenses must be available to anyone who is willing to sign.
• TODO: John Rizzo to check whether existing language guarantees this, and to suggest Process Doc changes if not.
• JSR1
• May need to strengthen the language in the JSPA instead?
• 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: circulate examples for discussion

Agility

•  Enable implementations before specs are finalized, to gain real-world experience.
  • Must maintain compatibility.
    
• See Transplant JSR proposals from JSR 306
• Look for feedback from WG members.
  • What mechanism to use to gather feedback?
  • If something is critical for one or two companies but not high priority for others - may not be "on the list"
• Time-outs for inactive JSRs.
• See JSR Renewal Ballot suggestion from JSR 306
• We have language
• JSR1
• Better procedures to remove or replace non-responsive spec leads and to deal with bankrupt or defunct spec-lead organizations.
  • Have no language.
  • Process doc only, or should we modify JSPA to permit withdrawal of contributions.
  • TODO: Michael to review and suggest changes.

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.
    • http://jcp.org/en/home/terms
  • A simple membership agreement for those who want voting privileges and the right to serve on Expert Groups.
    • Would the IEPA be a useful starting point?
  • The complexities of IP and compatibility obligations are required only for Spec Leads – factor these out into a separate agreement.
• No barriers to participation in Expert Groups.
  • Requests to join EGs and the Spec Lead's responses must be made in public.
  • Discuss with EC again.
• Define a process for removing EG members who do not participate.
  • Lose voting privileges. Look at OASIS, W3C.
• 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
• 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."
  • 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"

Cleanup

• Begin phase-out of IEPA
  • See Wayne Carr document for suggestions.
• Remove Process Doc section 1.1.4 J2ME building blocks
  • TODO: Patrick to talk to Oracle ME folks about this. DONE - they're OK with removing
• 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
• Prohibit major Patform changes in Maintenance releases (see MR2 of JSR 176)
  • Patrick to follow up
• Review Appendix A of Process Document (Eduardo has some concerns?)
  • Eduardo to review and report back (also on "lack of clarity when things are supposed to happen")

Branding and compatibility

• Emphasize the value of compatibility & the brand and the risks of using incompatible implementations.
• Relax all-or-nothing compatibility reqiurements?
  • TODO: 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.
• Enable and encourage the establishment of more formal relationships with other standards bodies.
  • Some disagreement as to whether Confidentiality is an obstacle to liaison with other organizations. Need more discussion.
• 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

Additional suggestions

• 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."
• Incorporate relevant portions of the EC Members' Guide (eg the sepecification of quorum) into the Process Document.
  • Eduardo is reviewing
• Increase fees?
• Deal with the Maintenance Expert Group problem
  • Spec Leads want the EG to persist after Final Release. The Process Doc states that the EG must disband.
    • Solution is to replace 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.
• Also 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.

TODO

• Legal collaboration between Oracle and others' lawyers.
• Decide on location for f2f (Redwood Shores or Santa Clara?)
  • Assume 9-5 on Tusday, 9-4 on Wednesday
• Do the compatibility presentation at the March f2f

Transplant

• Do this for agility purposes alone?
• Necessary for "co-development" work outside of as well as inside the JCP
  • Eg, cloud technologies
• Do not permit indefinite shipment - insist that existing products be made compatible within x months?
• On the list

Hybrid

• Under what conditions would we permit this to be applied to an existing JSR?
• Makes JCP more attractive - encourages interoperability with other platforms