JCP.next JSR1 list of proposed changes

Updated April 22 2011

Documents to be modified

• The Process Document
  • Normative
• The EC Members' Guide
  • Create a normative EC Standing Rules document from Appendix A of the Process Document and the currently non-normative EC Members Guide.
  • This will be referenced from the Process Doc and will address issues such as:
    • Meeting schedules, quorum requirements.
    • Voting procedures.
    • Publish EC meeting agenda in advance.
    • Specify whether agenda items are for discussion or for action.
  • NOTE: once created, this document will not require a new JSR to modify - instead this can be done by a vote of the ECs after a one-month review period.
• The Spec Lead Guide
  • Non-normative: referenced from Process Document

Categories

• Transparency
• Participation
• Agility
• Cleanup

Transparency

Expert Group transparency

• Draft language required for Process Document:
  • 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.
• Given the existing structure of the document, this new language won't easily fit anywhere.
• Add Section 0/General Procedures that apply to all of the subsequently-described stages, to avoid duplication.

Executive Committee transparency

• Create formal and normative EC Standing Rules document from the non-normative EC Members Guide.
  • We have a draft.
• Draft language required for Process Document changes:
  • Address PMO/Oracle Legal review of license terms (currently undocumented)
  • Recommendation:
    • Oracle legal drafts an opinion - presents to EC before the appropriate vote.
    • What if the license is in clear violation (eg, Apache license for Spec license) and ECs vote to approve this?
      • We'll face that problem if/when it occurs.
    • TODO: Patrick to review this suggestion with legal.
      • Need an SLA to guarantee turnaround (no unreasonable delay.)

License transparency

• We have draft language for Process Document changes:
  • Require that when the license terms associated with a JSR are significantly changed from the previous release, this is explicitly called out. We should also require change logs for the RI and TCK.
  • Note 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."
    • Recommendation - in the Process Document 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, RI, TCK, and licenses since the previous release. There are six 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 RI (changes made to the RI), TCK (changes made to the TCK) and LICENSING (changes to licensing terms.)
• Draft language required for Process Document changes:
  • All approved licenses must be offered "for ever." New (modified) licenses may also be offered subsequently.
    • NOTE: requiring licensees to adopt the latest TCK when updating their product may force them to accept new and unreasonable terms.
      • Under these conditions, they should be permitted to take the updated TCK on the original licensing terms.
        

TCK transparency

• Draft language required for General Requirements section of the Process Document ( Patrick TODO):
  • Recommendations
    • Publish lists of compatible implementations so users can see who's compatible and (by implication) who's not.
      • Spec Leads must submit to the PMO (quarterly, and at every Maintenance Release) a list of all devices/platforms that have been certified as compatible.
        • The PMO will publish these lists on jcp.org (and will publicise their existence.)
    • Emphasize the value of compatibility & the brand and the risks of using incompatible implementations.
      • This is a marketing issue - cannot be solved by Process Doc change.
    • TCK documentation must be publicly available.
      • TCK User's Guide must include Compatibility Requirements.
  • Non-recommendations (reconsider these for JSR2)
  • Do not 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.)
  • Do not (yet) publish information about optional features that are implemented.
    • This is too difficult to implement (what level of granularity would we choose?)
  • Do not strengthen the TCK quality requirements (except for requiring Compatibility Requirements)
    • Better to police what we have now.
  • Do not require more formal reporting requirements for conformance claims.
    • Would require generalizing compatibility requirements.
  • TBD
    • Permit and encourage the discussion of individual TCK test results.
      • We permit this now for OpenJDK testing - any value to generalizing to commercial testing?
        • No value to discussing with the general public, but there may be value in discussing with the licensees' customers.

IP flow transparency

• We have draft language for Process Document changes:
  • Review, clarify, expand the brief reference to anti-trust compliance..
• Draft language required for Process Document:
  • 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
    • Recommendation:
      • During the JSR 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
      • We must ensure that java.net is on the Approved List.
      • 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.
      • We may need to delay to JSR2 because of the legal effort required.

Participation

• Draft language required for EC Standing Rules:
  • Add semi-annual EC teleconferences that all JCP members are free to attend and where the agenda chosen from topics suggested by the membership.
  • Hold an annual open meeting at JavaOne.
  • Create a public alias (with archive) for members to provide feedback to the ECs.
• Draft language required for Process Document:
  • No barriers to participation in Expert Groups.
    • Requests to join EGs and the Spec Lead's responses, and decisions to remove or replace EG members, must be made in public.
  • 2.1.3 Uncooperative or Unresponsive Expert Group members.
    • 2/3 majority of the EG can vote out an EG member (the company, or the person representing that company.)
      • EG members should make a reasonable effort to resolve any such issues among themselves, for example by asking the member company to replace the representative.
        • NOTE: this paragraph is buggy - switches to Spec Lead in the middle. Duplicate it so we have one section dealing with Spec Leads and one with EG members..
  • 2.1.3a Uncooperative, Unresponsive, or Inactive Spec Leads
    • 2/3 of EG can vote to refer a problem to the PMO. The PMO may ask the Spec Lead organization to replace the Spec Lead (individual) or to seek an alternative Spec Lead.
      • If seeking an alternative Spec Lead, make sure this syncs with the Transfer Ballot language.
  • 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...”
        • NOTE: this doesn't deal with the JUG/JUG-member relationship. We think that's OK.
        • It might be difficult for the PMO to enforce this in practice, but we would have the authority to do so if necessary or to take corrective action after the fact.
    • Need similar language to clarify that employees of EC members are ineligible to run for election as individuals.
• Draft language required for EC Standing Rules:
  • Penalties for EC members who do not attend meetings..
    • Miss two meetings in a row - lose voting privileges until you have attended two in a row.
      • Non-voting members don't count towards quorum.
        • Make sure we distinguish between voting and non-voting members elsewhere in the document.
      • EC may waive this penalty under exceptional circumstances.
    • Miss 6 meetings in a row (or 5, or 4?) and you lose your seat.
      • EC may waive this penalty under exceptional circumstances.
    • Need regular reports from the PMO to the EC and warnings to those who approach the limits.
  • Penalties for EC members who don't vote?
    • Can't take away voting privileges. We could expel from EC in extreme cases. (But if people aren't voting they're probably not attending meetings either...)

Agility

• We have draft language for Process Document:
  • Time-outs for inactive JSRs.
    • See JSR Renewal Ballot suggestion from JSR 306.
      • Reduce the numbers: 12 months to Early Draft, 2 years to Public Draft Review, 3 years to Final Release.
      • Make sure this is sync'd with the Dormant JSR language.
• Draft language required for Process Document:
  • Clarify the Maintenance process
    • Spec Leads want the EG to persist after Final Release. The Process Doc states that the EG must disband.
    • This was presumably to ensure that IP vests in a clean manner. Need legal confirmation
    • Recommendation:
      • The Expert Group must shut down and be re-formed at each release.
        • Spec-lead will typically recruit from the previous EG, perhaps adding some new members.
      • We need to maintain the history of which members have been on the EG between its most recent re-formation and the next release.
        • These are the members who have potentially contributed IP.
      • Need legal check on this, but hopefully we can complete this for JSR1.
• 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.
  • What should the process be?
    • For Maintenance Review we get a change log, an updated (supposedly-final) Spec, an updated RI and TCK if necessary (or a statement explaining why these aren't necessary.)
    • We post these for review.
    • At the end of the review period, if no objections by EC, approval is automatic.
      • If there are objections, an exception ballot is held.
    • Alternatively, should we get rid of the exception ballot process and always require an approval ballot, just as we do with Final Releases?
      • Recommendation: yes
      • We could then harmonize the two processes (JSR development/release and Maintenance)
• Clarify requirements for RI and TCK to be posted within x weeks of Final Release and Maintenance Release.
  • We post the Spec, but never the RI and TCK. We get a URL.
  • When we get a working URL the state becomes "final" - IP vests at this point.
  • What if the URL is later broken - becomes non-functional?
    • PMO gives Spec/Maintenance lead 30 days to fix.
    • If no fix, revert to Proposed Final Draft or Maintenance Review stage; must complete the process again.
      

Cleanup

• Draft language required for Process Document:
  • Remove Process Doc section 1.1.4 J2ME building blocks
  • Correct typos and errors in Process Document.
  • Remove the ambiguity of the term Spec Lead in the Process Doc (sometimes it refers to the Member and sometimes to the person representing the Member and leading the EG.)
    • See Wayne Carr document for explanation.

Procedural issues

• 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."
    • We may fix this in JSR2 but for now we'll need to apply moral pressure to in-flight JSRs to adopt the new procedures.