• 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 2.11 |  JCP 2.10 |  JCP 2.9 |  JCP 2.8 |  JCP 2.7 |  JCP 2.6 |  JCP 2.5 |  JCP 2.1 |  JCP 2.0 |  JCP 1.0  

The formal procedures for using the Java Specification development process. Read the .pdf file here.This process was developed via JSR 355, and also includes revisions to the rules under which the Executive Committee operates. Read the EC Standing Rules here.

Version 2.9 (August 15, 2012)

Comments to: pmo@jcp.org
Copyright (c) 1996 - 2012 Oracle America, Inc.

CONTENTS

I. EXECUTIVE SUMMARY

II. DEFINITIONS

III. THE JAVA COMMUNITY PROCESS^SM PROGRAM

I. EXECUTIVE SUMMARY

The international Java community develops and evolves Java? technology specifications using the Java Community Process (JCP.) The JCP produces high-quality specifications using an inclusive, consensus-based approach that produces a Specification, a Reference Implementation (to prove the Specification can be implemented,) and a Technology Compatibility Kit (a suite of tests, tools, and documentation that is used to test implementations for compliance with the Specification.)

Experience has shown that the best way to produce a technology specification is to gather a group of industry experts who have a deep understanding of the technology in question and for a strong technical lead work with that group to create a first draft. Agreement on the form and content of the draft is then built using an iterative process that allows an ever-widening audience to review and comment on the document.

An Executive Committee (EC) representing a cross-section of both major stakeholders and other members of the Java community is responsible for approving the passage of Specifications through the JCP's various stages and for reconciling discrepancies between Specifications and their associated test suites.

There are four major stages in this version of the JCP:

1. INITIATION: A Specification targeted at the desktop/server or consumer/embedded space is initiated by one or more Members and approved for development by the EC. A group of experts is formed to assist the Spec Lead with the development of the Specification.
2. DRAFT RELEASES: The Expert Group develops the Specification through an iterative process, releasing drafts for public review and comment. After the formal Public Review the EC holds a ballot on whether the JSR should proceed to the Final Release stage.
3. FINAL RELEASE: The Spec Lead submits the Specification to the PMO for publication as the Proposed Final Draft. When the RI and TCK are completed, and the RI passes the TCK, the Specification, the RI, and the TCK are submitted to the PMO, which circulates them to the EC for final approval.
4. MAINTENANCE: The Specification, Reference Implementation, and Technology Compatibility Kit are updated in response to ongoing requests for clarification, interpretation, enhancements, and revisions. The EC reviews proposed changes to the Specification and indicates which can be carried out immediately and which should be deferred to a new JSR.

   This version (2.9) of the JCP was developed using the Java Community Process itself by means of JSR 355, led by Oracle with all Executive Committee members forming the Expert Group.

II. DEFINITIONS

Agent: an individual - for example an employee, a contractor, or an officer - who is authorized to act on behalf of a company or organization.

Appeal Ballot: The EC ballot to override a first-level decision on a TCK test challenge.

Ballot: See Appeal Ballot, Final Approval Ballot, Final Approval Reconsideration Ballot, JSR Approval Ballot, JSR Reconsideration Ballot, JSR Renewal Ballot, JSR Renewal Reconsideration Ballot, JSR Withdrawal Ballot, Maintenance Review Ballot, Maintenance Renewal Ballot, Maintenance Release Withdrawal Ballot, Public Draft Specification Approval Ballot, Public Draft Specification Reconsideration Ballot, Transfer Ballot.

Contribution Agreement: A legal agreement defining the terms, particularly those concerning the grant of intellectual property rights, under which contributions are made to a project.

Dormant Specification (Dormant): A Specification that the PMO has determined has no assigned Specification Lead or Maintenance Lead, or that is not being actively developed and on which no further development is anticipated.

Early Draft Review: A 30 to 90 day period during which the public reviews and comments on the draft Specification.

Elected Seat: An EC seat filled by the election process described in section 6.4.4.

Executive Committee (EC): The Members who guide the evolution of the Java technologies. The EC represents a cross-section of both major stakeholders and other Members of the Java community. EC members are appointed in an annual election process. The EC Policies and Procedures are specified in the EC Standing Rules, which is a separate document.

Expert: A Member or Member Representative who has expert knowledge and is an active practitioner in the technology covered by the JSR.

Expert Group (EG): The group of Experts who develop or make significant revisions to a Specification.

Final Approval Ballot: The 14-day EC ballot to approve the Final Draft along with its associated RI and TCK.

Final Approval Reconsideration Ballot: The 14-day EC ballot to reconsider an initial rejection of a Final Draft, RI, and TCK.

Final Draft: The final draft of the Specification that will be put forward for EC approval.

Final Release: The final stage in the JSR development process when the Specification, RI, and TCK have been completed and can be licensed by implementors.

First-Level TCK Appeals Process: The process defined by the Spec Lead that allows implementors of the Specification to appeal one or more tests defined by the Specification's TCK.

Issue: an explicit reference to an item defined in an Issue Tracker.

Issue List: A list of Issues generated from an Issue Tracker, identifying the disposition of each.

Issue Tracker: A mechanism to allow issues (problems, tasks, comments, or requests for change) to be recorded and tracked by priority, status, owner, or other criteria. The Issue Tracker should permit issues to be identified by states such as open, resolved, and closed and should support the assignment of resolution types such as deferred (postponed to a follow-on release,) fixed (implemented,) challenged (no satisfactory resolution,) and rejected (deemed inappropriate or out of scope.)

Java Community Process (JCP): The formal process described in this document for developing or revising Java technology Specifications.

Java Community Process Member (Member): A company, organization, or individual that has signed the JSPA and is abiding by its terms.

Java Specification (Specification): A written specification for some aspect of the Java technology. This includes the language, virtual machine, Platform Editions, Profiles, and application programming interfaces.

Java Specification Request (JSR): The document submitted to the PMO by one or more Members to propose the development of a new Specification or significant revision to an existing Specification.

Java Specification Participation Agreement (JSPA): A one-year renewable agreement between Oracle America and a company, organization or individual that allows the latter entities to participate in the Java Community Process.

JCP Website: The website where the public can stay informed about JCP activities, download draft and final Specifications, and follow the progress of Specifications through the JCP.

JSR Approval Ballot: A two-week EC ballot to determine if the initial JSR submission should be approved

JSR Reconsideration Ballot: The EC ballot to determine if a revision of an initial JSR submission should be approved.

JSR Page: Each JSR has a dedicated public web page on the JCP Website where the JSR's history is recorded and where other relevant information about the JSR is published.

JSR Renewal Ballot: An EC ballot to confirm that a JSR should continue in its work. JSR Renewal Reconsideration Ballot: An EC ballot to determine if a revised JSR should continue its work.

JSR Review: A two- to four-week period (the length to be set at the discretion of the submitter) during which the public can review and comment on a proposed new JSR before the JSR Approval Ballot.

JSR Withdrawal Ballot: An EC ballot to confirm that a completed JSR that appears to have been abandoned should be withdrawn.

Licensor Name Space: The public class or interface declarations whose names begin with "java", "javax", "com.sun" (or ?com.Your name? if You are the Specification Lead) or their equivalents in any subsequent naming convention adopted by Oracle.

Maintenance Lead (ML): The Expert responsible for maintaining the Specification.

Maintenance Lead Member: The individual JCP member who is a Maintenance Lead, or the company or organization that is represented by the Maintenance Lead.

Maintenance Release: The final stage in the JSR maintenance process when the Specification, RI, and TCK have been updated and can be licensed by implementors.

Maintenance Review: A period of at least 30 days prior to finalization of a Maintenance Release when Members and the public consider and comment on the change the Maintenance Lead proposes to include in the release, as identified in the associated Issue List.

Maintenance Review Ballot: An EC ballot to determine whether the changes and time line proposed by a Maintenance Lead are appropriate for a Maintenance Release.

Maintenance Renewal Ballot: a ballot during which EC members vote on whether to permit a Maintenance Lead to extend the deadline for delivery of materials for Maintenance Release, or whether the previous Maintenance Review should be rescinded and the ML be required to start the process again.

Maintenance Release Withdrawal Ballot: An EC ballot to confirm that a completed Maintenance Release that appears to have been abandoned should be withdrawn.

Member: See Agent, Java Community Process Member, Member Associate, Member Representative.

Member Associate: An individual who is associated with a Member organization but is not an Agent of that organization.

Member Representative: An Agent of a Member company or a Member organization who represents its interests within the JCP.

Platform Edition Specification (Platform Edition): A Specification that defines a baseline API set that provides a foundation upon which applications, other APIs, and Profiles can be built. There are currently three Platform Edition Specifications: Java SE, Java EE, and Java ME.

Profile Specification (Profile): A Specification that references one of the Platform Edition Specifications and zero or more other JCP Specifications (that are not already a part of a Platform Edition Specification.) APIs from the referenced Platform Edition must be included according to the referencing rules set out in that Platform Edition Specification. Other referenced Specifications must be referenced in their entirety.

Program Management Office (PMO): The group within Oracle America that is responsible for administering the JCP and chairing the EC.

Proposed Final Draft: The version of the draft Specification that will be used as the basis for the RI and TCK.

Public Draft Specification Approval Ballot: The EC ballot to determine if a draft should proceed after Public Review.

Public Draft Specification Reconsideration Ballot: The EC ballot to determine if a revised draft should proceed after Public Review.

Public Review: A 30 to 90 day period when the public can review and comment on the draft Specification.

Ratified Seat: An EC seat filled by the ratification process described in section 6.4.3. Reference Implementation (RI): The prototype or "proof of concept" implementation of a Specification.

Release: A Final Release or a Maintenance Release

Specification: See Java Specification.

Specification Lead (Spec Lead): The Expert responsible for leading the effort to develop or make significant revisions to a Specification and for completing the associated Reference Implementation and Technology Compatibility Kit. A Spec Lead (or the Spec Lead's host company or organization) must be a Java Community Process Member.

Specification Lead Member (Spec Lead Member): The individual JCP member who is a Spec Lead, or otherwise the company or organization that is represented by the Spec Lead.

Technology Compatibility Kit (TCK): The suite of tests, tools, and documentation that allows an organization to determine if its implementation is compliant with the Specification.

Transfer Ballot: The EC ballot to approve transfer of ownership of a Specification, RI, and TCK from one Member to another Member. ¹

Umbrella Java Specification Request (UJSR): A JSR that defines or revises a Platform Edition or Profile Specification. A UJSR proceeds through the JCP like any other JSR.

The use of the term day or days in this document refers to calendar days unless otherwise specified.

The use of the words ?must?, ?must not?, ?required?, ?shall?, ?shall not?, ?should?, ?should not?, ?recommended?, ?may? and ?optional? in this document is done in accordance with the IETF's RFC 2119.

III. THE JAVA COMMUNITY PROCESS^SM PROGRAM

1. GENERAL PROCEDURES

1.1 EXPERT GROUP TRANSPARENCY

Each Expert Group is free to use the working style that it finds most productive and appropriate, so long as this is compatible with the requirements specified in this document. For example, an EG may choose to move forward only when there is general agreement among its members, or by voting on issues when there is disagreement.

As specified below, Expert Groups must operate in a transparent manner, enabling the public to observe their deliberations and to provide feedback. All feedback must be taken into consideration and public responses to such feedback must be provided. EGs must maintain a publicly-accessible document archive from which all of their working materials such as source documents, meeting agendas and minutes, and draft documents can be downloaded. The EC should take the Expert Group's transparency record into consideration when voting on its JSR.

In the initial JSR submission the Spec Lead must specify the transparency mechanisms (for example, the communication mechanisms and Issue Tracker) that the Expert Group intends to adopt, and must provide the URLs for accessing the chosen collaboration tools. The PMO shall publish this information on the JSR Page. The Spec Lead must also provide a pointer to any Terms of Use required to use the collaboration tools so that the EC and prospective EG members can judge whether they are compatible with the JSPA.

If the EG changes its collaboration tools during the life of the JSR these changes must be reported to the PMO, which shall update the relevant information on the JSR Page. Any such changes must ensure that previously-published information is incorporated into the new tools.

When voting to approve a JSR's transition to the next stage, EC members are expected to take into consideration the extent to which the Spec Lead is meeting the transparency requirements.

Spec Leads should be aware of their obligations under the JSPA to license the output of their JSR on Fair, Reasonable, and Non Discriminatory terms, and to make certain patent grants. Incorporating feedback provided through public email lists or forums without ensuring that the provider has signed the JSPA or an equivalent Contribution Agreement may make it impossible to meet these requirements or may expose the Spec Lead Member to legal liability.

The use of Confidential Information (as defined in the JSPA) by Expert Groups limits transparency, is strongly discouraged, and will be prohibited in a future version of the Process. If the Spec Lead intends to permit the use of Confidential Information (such as emails, drafts, or submissions marked as Confidential) this must be specified in the initial Java Specification Request. ²

1.1.1 PUBLIC COMMUNICATIONS

Expert Groups may choose to keep purely administrative matters private, but all substantive business must be performed in a manner that allows the public to observe their work and to respond to it. All proceedings, discussions, and working documents must be published, and a mechanism must be established to allow the public to provide feedback. One common way of meeting these requirements is through the use of mailing lists, but other alternatives such as blogs, Wikis, and discussion forums may be preferred. Whatever communication mechanisms are chosen, these must include an archiving function so that a record of all communications is preserved. Archives must be readable by the public. ³

1.1.2 ISSUE TRACKING

Issues must be tracked through a publicly readable Issue Tracker. The Expert Group may choose to use a publicly writable Issue Tracker, thereby permitting the public to log issues directly, or alternatively to identify formal comments in some other manner and to enter them into the Issue Tracker on behalf of the submitter. Whatever mechanism is used, a publicly-readable audit trail of all comments and Issues must be maintained.

Whenever a Spec Lead or a Maintenance Lead submits materials to the PMO for review or ballot they must also provide an Issue List indicating the disposition of all of the Issues that have been logged against the JSR. Issues logged late in the review cycle may be deferred for later consideration, and Issues that are blatantly off-topic or that appear to have been submitted maliciously or erroneously may be ignored.

In order to enable EC members to judge whether Issues have been adequately addressed, the Issue List must make a clear distinction between Issues that are still open, Issues that have been deferred, and those that are closed, and must indicate the reason for any change of state.

The PMO shall publish the Issue List or a pointer to it together with the other materials.

EC members should review the supplied Issue List and take it into consideration when casting their ballot. If they have any reservations or concerns about a 'yes' vote, or if they wish to vote 'no,' they should accompany their ballot with comments which reference one or more Issues (perhaps logged by them) that they would like to see addressed in the future. EC members should vote 'no' if they believe that the Spec Lead or Maintenance Lead has not adequately addressed all Issues including those that have been rejected or otherwise closed by the Expert Group.

1.1.3 CHANGES TO LICENSING TERMS

As described in Section 2.2.1 below, the proposed licensing terms must be disclosed during JSR submission. The Specification license must not be modified after initial submission since to do so could invalidate IP grants. It may be necessary, however, to modify the proposed RI or TCK license. Any such changes must be disclosed when the Specification is next submitted to the PMO for public posting or review.

For as long as a JSR is licensed and while it is legally possible to do so the Spec Lead Member must offer the RI and TCK licenses that were published at the time of Final Release, with the exception that reasonable increases in price are permitted. At subsequent Maintenance Releases alternate RI or TCK licenses may also be offered so long as all changes are disclosed, but licensees must be free to choose the original terms if they wish. For example, existing licensees who do not wish to accept a modified license when required to adopt a newer TCK shall have the option to license the updated TCK under the previous terms. If a JSR changes hands the new Maintenance Lead Member must present a license with terms comparable to, or more favorable to licensees than the existing license.

When a newer version of a technology is created through a follow-on JSR, the Specification, RI, and TCK license terms for the new JSR may differ from those offered for the previous JSR, but any such changes must be disclosed during JSR submission. The original terms for the previous JSR must be offered for as long as that JSR is licensed.

1.2 EXPERT GROUP MEMBERSHIP

1.2.1 EXPERT GROUP COMPOSITION

There is no size limit on the Expert Group. The Spec Lead may add additional Experts at any time so long as existing EG members are consulted. New members may be added, for example, to increase diversity of opinion.

Any JCP Member, Member Representative, or Member Associate may request to join an Expert Group at any time by submitting their nomination via the online form provided on the JSR Page. Member Associates, since they are not covered by the JSPA of their organization, must sign the JSPA in their own right before they will be permitted to join an Expert Group.

Details of such requests, including the organizational affiliation of the requester, together with the Spec Lead's official response, substantive deliberations within the EG about the matter, and any other official decisions related to EG membership must be published through the EG's public communication channel. The PMO will ensure that the JSR Page lists the Members who are members of the EG together with the names of individual Member Representatives or Member Associates where appropriate.

1.2.2 WITHDRAWAL OF AN EXPERT FROM THE EXPERT GROUP

An Expert may withdraw from the Expert Group at any time. If the withdrawing Expert is the Spec Lead, the Expert Group, with the help of the PMO, should approach the Member who originally contributed the Expert, if any, and request them to provide a suitable replacement; if no such replacement is forthcoming, the Expert Group should choose one of its members as the new Spec Lead. If the withdrawing Expert is not the Spec Lead, the Spec Lead should approach the Member who originally contributed the Expert, if any, and work with that organization to find a suitable replacement. If no replacement is offered or is not otherwise available, the Spec Lead may recruit a replacement from amongst other Members.

1.2.3 DISRUPTIVE, UNCOOPERATIVE OR UNRESPONSIVE EXPERT GROUP MEMBERS

There may be rare instances when members of the Expert Group feel that one of their fellow Experts is not acting in ways that advance the work of the Expert Group, and is being disruptive, uncooperative or unresponsive. EG members are expected to make a reasonable effort to resolve any such issues among themselves, with the active help of the Spec Lead. However, if the situation cannot be resolved in a timely manner, any three members of the EG can approach the Spec Lead and request that the EG member in question be excluded from further participation in the EG. If the Spec Lead agrees to the request he can then do so. In the case where the EG Member in question is a Member Representative, the Spec Lead must first request that the Member replace its representative. If the Member does not do so in a timely manner, the Spec Lead can exclude the Member itself from further EG participation. The Spec Lead's decision as to whether or not to exclude can be appealed to the EC by following the process outlined in Section 1.7, ?Escalation and Appeals?

1.2.4 UNRESPONSIVE OR INACTIVE SPEC LEAD

There may be rare instances when members of the Expert Group feel that the Spec Lead is not acting in ways that advance the work of the Expert Group and is being unresponsive or inactive. The EG is expected to make a reasonable effort to resolve any such issues in a timely manner. However, if the situation cannot be resolved these concerns should be brought to the attention of the EC as quickly as possible so they may be proactively addressed and resolved.

If the problems cannot be resolved informally, any three members of the EG may request the EC to replace the Spec Lead. All such requests must clearly state the cause of the concern and provide all necessary evidence. If the EC agrees that there is cause, it may ask the PMO to replace the Spec Lead. In the case where the Spec Lead is a Member Representative the PMO shall ask the Member to replace the Spec Lead. If the Member refuses to do so, the PMO shall seek to put in place an alternative Spec Lead, in which case the EC must conduct a transfer ballot as specified in section 5.1.2 of this document. If no Spec Lead replacement can be found, the EC shall initiate a JSR Renewal Ballot to determine whether the JSR should be shut down.

1.3 JSR DEADLINES

If a JSR does not begin Early Draft Review within 9 months of completing its JSR Approval Ballot, or does not begin Public Review within 12 months of first submitting an Early Draft, or does not reach Final Release within 12 months of commencing Public Review, then the EC should initiate a JSR Renewal Ballot unless it is agreed that there are extraordinary circumstances that justify the delay. The PMO shall inform the Spec Lead and Expert Group of this decision and will request the Spec Lead and Expert Group to prepare a public statement to the EC. The JSR Renewal Ballot shall start 30 days after the request. If the JSR Renewal Ballot is approved by the EC, then another renewal ballot cannot be initiated for that JSR for an additional year.

If the JSR Renewal Ballot fails, the Expert Group will have 30 days to update the JSR in response to the concerns raised by the EC, and may submit a revised version to the PMO. If a revised JSR is not received by the end of the 30 days, the original decision by the EC shall stand and the JSR shall be closed. If a revision is received, then the PMO shall forward it to the EC and initiate a JSR Renewal Reconsideration Ballot. At the close of balloting, all comments submitted by EC members, together with their ballots shall be circulated to the Expert Group by the PMO. If this ballot fails, the JSR shall be closed and the Expert Group shall disband.

If a JSR that is closed through these processes was a revision to an existing Specification, the Spec Lead shall resume the role of Maintenance Lead of the current Specification.

1.4 COMPATIBILITY TESTING

The Spec Lead is responsible for defining the process whereby the TCK is used to certify implementations of the JSR as compatible. The Maintenance Lead must submit to the PMO at least quarterly a list of all implementations that have been certified as compatible and that have been released publicly or commercially. The PMO will publish this information on the JCP Website. If the Spec Lead submits the information in the form of a pointer to an already published list the PMO may choose simply to reference that list rather than duplicate it.

TCK license terms must permit implementors to freely and publicly discuss the testing process and detailed TCK test results with all interested parties.

1.5 EXECUTIVE COMMITTEE DUTIES

1.5.1 TRANSPARENCY

All substantive Executive Committee business should be conducted in the most transparent manner possible. EC transparency requirements are specified in a separate document, EC Standing Rules.

1.5.2 DRAFT REVIEWS

During JSR reviews EC members are strongly encouraged to ensure that one or more technical members of their organizations review the draft and provide feedback using the mechanism specified by the Spec Lead. EC feedback is particularly important to the Expert Group, and EC members are encouraged not to wait until ballot periods to raise concerns and issues.

1.6 PMO RESPONSE TIMES

Materials to be posted on the JCP Website for review, comment, or any other official EG or EC business should be submitted to the PMO, which shall post them on the JCP Website and announce their availability to Members and the public within seven days of receipt (holiday closures excepted.)

1.7 ESCALATION AND APPEALS

Unless otherwise specified in this document, any EG member can appeal to the EC regarding a decision, an action, or inaction by the PMO, a Spec Lead, or a Maintenance Lead that affects EG participation or issue-resolution and which cannot be resolved by other reasonable means. An appeal must be initiated by sending an email message to the PMO (pmo@jcp.org) in all cases, even if it affects the PMO itself. The message must describe the issue under appeal clearly and concisely, with a short and relevant subject line, and must provide all relevant documentation to support the appeal. The PMO shall transmit the message to the EC no later than seven days after receipt. The EC shall then respond to the appellant within 30 days, either with a resolution or with a request for clarification and/or further documentation.

2. INITIATE A NEW OR REVISED SPECIFICATION

2.1 INITIATE A JAVA SPECIFICATION REQUEST

One or more Members may initiate a request to develop a new Specification, or carry out a significant revision to an existing one, by submitting a JSR proposal through the JCP Website, as described in the Spec Lead Guide. Upon request to the PMO any JSR proposal may be withdrawn by the submitter(s) without explanation prior to the completion of the JSR Approval Ballot.

The following information must be provided with each JSR:

• the Members making the request (the submitters,) the proposed Spec Lead, and the initial members of the Expert Group,
• a description of the proposed Specification,
• the reason(s) for developing or revising it,
• the primary Platform Edition, as well as any consideration given to other Platform Editions,
• an estimated development schedule,
• any preexisting documents, technology descriptions, or implementations that might be used as a starting point,
• a transparency plan, which outlines the tools and techniques that the Spec Lead will use during the development of the Specification to communicate with and seek feedback from JCP Members and the public.

2.1.1 REVISE EXISTING SPECIFICATIONS

Existing Specifications, together with their associated RIs and TCKs, are maintained by a designated Maintenance Lead using the processes described in section 5 of this document. Maintenance Lead Members are expected to assume long term ownership of the Specification, RI, and TCK while respecting the wishes of JCP Members with regard to evolution. Maintenance Leads shall therefore be the Spec Leads for all significant revisions to their Specifications, but they shall not have the exclusive right to decide when a significant revision will take place. That shall be decided by the EC in response to a revision JSR that can be initiated by any JCP Member. Submitter(s) should make a reasonable effort to recruit members of the previous Expert Group to join any such revision effort.

2.1.2 PROTECT THE INSTALLED BASE AND GUARD AGAINST FRAGMENTATION

Changes to the Java programming language, the Java virtual machine (JVM,) the Java Native Interface (JNI,) packages in the "java.*" space, or other packages delivered only as part of Java SE, have the potential to seriously disrupt the installed base if carried out inconsistently across the Platform Editions. In order to protect the installed base, any such changes can only be accepted and carried out within a UJSR for Java SE.

In order to guard against fragmentation, new Platform Edition Specifications must not substantially duplicate existing Platform Editions or Profiles.

2.1.3 PROFILES AND API SPECIFICATIONS TARGET CURRENT PLATFORM EDITIONS

All new or revised Specifications must be compatible with the most recent versions of the targeted Platform Edition Specifications. In order to achieve this, all UJSRs to define new Profile Specifications or revise existing Profile Specifications must reference either the most recent Release version of the Platform Edition Specification they are based upon or a newer version of that Specification that is under development via an active UJSR.

2.1.4 PLATFORM INCLUSION

The JSR submission form requires the submitter to state whether the JSR's RI and TCK should be delivered as part of a Profile or Platform Edition, in standalone manner, or both. The final decision as to whether a specific JSR is included in a Profile or a Platform Edition is made by the Spec Lead and Expert Group of the Platform Edition or Profile JSR, and is confirmed by the EC ballots on the relevant JSR. If the Spec Lead for the Platform Edition or Profile JSR turns down a request for inclusion then the JSR must deliver a standalone RI and TCK.

Technologies may be incorporated into a Profile or Platform Edition after having been initially delivered standalone. A JSR for a new version of an API that proposes to become part of a Profile or Platform Edition and is considering discontinuing standalone availability must state the rationale for this change and must inform the public of the intention to discontinue the availability of the standalone RI, and TCK one JSR submission in advance.

2.2 JSR REVIEW

When a JSR is received, the PMO shall give it a tracking number, create its JSR Page, announce the proposed JSR to the public, and begin JSR Review. Comments on the JSR should be sent to the JSR's public feedback communication mechanism. Comments shall be forwarded to the EC for its consideration and shall be made available from the JSR Page (similar comments may be consolidated.) Members who are interested in joining the Expert Group (should the JSR be approved) should identify themselves by submitting a nomination form to the PMO.

2.2.1 DISCLOSURE OF LICENSING TERMS

The Spec Lead Member is responsible for developing the Reference Implementation and Technology Compatibility Kit and for licensing them as described in the JSPA. The Spec Lead Member must provide the EC with complete copies of the proposed Specification, RI, and TCK licenses no later than the start of JSR Review. The licenses shall be published on the JSR page. EC members should provide feedback on the terms as an indication of how the community as a whole might react to the terms. If EC members believe that the proposed licensing terms are not compatible with the licensing guidelines established for use within the JCP, then balloting on the proposed JSR shall be delayed until Oracle legal provides an opinion on the matter.

2.3 JSR APPROVAL BALLOT

After the JSR Review, EC members shall review the JSR and any comments received, and cast their ballot to decide if the JSR should be approved.

If the JSR Approval Ballot fails, the PMO shall send all EC comments to the JSR submitter(s) who may revise the JSR and resubmit it within 14 days. If a revised JSR is not received in that time, the original EC decision shall stand and the JSR shall be closed. If a revised JSR is received, the PMO shall post it to the JSR Page, announce the revised JSR to the public, and send it to all EC members for a JSR Reconsideration Ballot. If that ballot fails, the JSR shall be closed.

2.4 FORM THE EXPERT GROUP

When a JSR is approved the PMO instructs the identified Spec Lead to form the Expert Group. If the Member contributing the Spec Lead withdraws from the JCP before the JSR is approved, the PMO shall request the preliminary Expert Group to choose a replacement from among themselves who is willing to take on the duties defined in this document.

3.1 WRITE THE FIRST DRAFT OF THE SPECIFICATION

The Expert Group should begin work by considering the requirements set forth in the JSR, any contributed documents or technology descriptions, comments received during JSR Review and, if this is a revision of an existing Specification, the Issue List maintained by the Maintenance Lead (see section 5.) Additional input can be obtained from discussions with other Members, industry groups, software developers, end-users, and academics. The goal is to define requirements and then write a draft Specification suitable for review by the community and the public.

When the Expert Group decides that the first draft is ready for review, the Spec Lead shall send the draft, along with any additional files required for review, to the PMO. The Spec Lead should also suggest the length of the Early Draft Review period if the Expert Group feels it should go beyond the minimum 30 days.

Multiple Early Drafts (and Early Draft Reviews) are encouraged where the Expert Group feels that this would be helpful.

3.2 EARLY DRAFT REVIEW

Refinement of the draft Specification begins when the PMO posts it to the JCP Website and announces the start of Early Draft Review. The goal of Early Draft Review is to get the draft Specification into a form suitable for Public Review as quickly as possible by uncovering and correcting major problems with the draft. Early Draft Review is an early-access review, and should ideally take place when the Specification still has some unresolved issues. The public's participation in Early Draft Review is an important part of the process since in the past, comments from the public have raised fundamental architectural and technological issues that have considerably improved some Specifications.

3.2.1 UPDATING THE DRAFT DURING EARLY DRAFT REVIEW

If the Expert Group makes major revisions to the draft during Early Draft Review the Spec Lead should send the revised draft, along with a synopsis of the changes, to the PMO, which shall publish these online and make them available for download by the public.

After the Early Draft Review period has ended, the Expert Group can make any additional changes to the draft it deems necessary in response to comments before submitting the draft to the PMO for the next review.

3.3 PUBLIC REVIEW

Public Review begins when the PMO posts a new draft Specification on the JCP Website and announces its availability for public review and comment.

The Spec Lead is responsible for ensuring that all comments are read and considered. If those comments result in revisions to the draft, and those revisions result in major changes (in the opinion of the Expert Group,) then the Spec Lead must send an updated draft (with a summary of the changes) to the PMO before the review period ends. The PMO shall post the new draft and the change summary on the JCP Website and shall notify the public that the new draft is available.

3.4 PUBLIC DRAFT SPECIFICATION APPROVAL BALLOT

The Public Draft Specification Approval Ballot starts when the Public Review closes. At the close of balloting, all comments submitted by EC members with their ballots shall be circulated to the Expert Group by the PMO.

If the Public Draft Specification Ballot fails, the Expert Group will have 30 days to update the draft in response to the concerns raised by the EC and to submit a revised version to the PMO. If a revised draft is not received within 30 days, the original decision by the EC shall stand and the JSR shall be closed. If a revision is received, the PMO shall forward it to the EC and initiate a Public Draft Specification Reconsideration Ballot. At the close of balloting, all comments submitted by EC members with their ballots shall be circulated to the Expert Group by the PMO. If this ballot fails, the JSR shall be closed and the Expert Group shall disband. If the JSR was a revision to an existing Specification, the Spec Lead shall resume the role of Maintenance Lead of the current Specification (see section 5.)

4. FINAL RELEASE

4.1 PROPOSED FINAL DRAFT

If the Public Draft Specification Approval Ballot (or Reconsideration Ballot) is successful, the Expert Group shall prepare the Proposed Final Draft of the Specification by completing any revisions it deems necessary in response to comments received. The Spec Lead shall then send the Proposed Final Draft to the PMO, which shall post it on the JCP Website for public download.

4.1.1 COMPLETE THE RI AND TCK

The Spec Lead Member is responsible for the completion of both the RI and the TCK. JSRs that are targeted at more than one platform are required to support each environment, which may require a separate RI and TCK for each environment. If the RI and TCK uncover areas of the Specification that were underdefined, incomplete, or ambiguous, the Spec Lead shall work with the Expert Group to correct those deficiencies and then send a revised Specification together with a summary of the changes to the PMO. Information shall be posted to the JCP Website. The Expert Group shall continue to consider any further comments received during this time.

4.1.2 ESTABLISH A FIRST-LEVEL TCK APPEALS PROCESS

The Spec Lead is also responsible for establishing a clearly defined First Level TCK Appeals Process to address challenges to tests contained in the TCK. This process must be described in the TCK documentation. Implementors who are not satisfied with a first level decision should appeal to the EC by documenting their concerns in an email message to the PMO. The PMO will circulate the request to the EC, together with any information received from the ML concerning the rationale for the first-level decision, and initiate a 7-day Appeal Ballot.

4.1.3 UPDATE THE DELIVERABLES IN RESPONSE TO THE APPEAL BALLOT

Depending on the nature of the problem, a successful TCK challenge will require updating one or more of the TCK, the Specification, and the RI. Within 30 days of the close of a successful TCK Appeal Ballot the Maintenance Lead must update these deliverables as necessary and report the changes to the PMO when the Specification (if changed) and URLs for the updated RI and/or TCK are delivered for publication on the JCP Website.

4.2 FINAL APPROVAL BALLOT

When the Expert Group is satisfied that the TCK provides adequate test coverage, the RI correctly implements the Specification, and the RI passes the TCK, the Spec Lead shall send the Final Draft of the Specification to the PMO together with instructions on how EC members can obtain the RI and TCK for evaluation. The PMO shall circulate the materials to the EC and initiate the Final Approval Ballot. At the close of balloting, all EC comments shall be sent to the Expert Group by the PMO.

The TCK submitted as part of the Final Draft must meet the following requirements:

• Include documentation covering configuration and execution of the TCK, any other information needed to use the TCK (e.g. documentation for any supplied tools,) a definition and explanation of the First-level TCK Appeals Process, and the compatibility requirements that must be met in addition to passing the TCK tests
• The compatibility requirements at a minimum must specify that all compatible implementations
  • a) fully implement the Spec(s) including all required interfaces and functionality, and
  • b) do not modify, subset, superset, or otherwise extend the Licensor Name Space, or include any public or protected packages, classes, Java interfaces, fields or methods within the Licensor Name Space other than those required/authorized by the Specification or Specifications being implemented.
  These requirements must apply unless the Specification or TCK explicitly allows exceptions.
• Be accompanied by a test harness, scripts or other means to automate the test execution and recording of results.
• Include a TCK coverage document that will help EC members to evaluate the TCK's quality. This document should include an overview of the documentation included in the TCK, a description of means used to validate the quality of the TCK, the criteria used to measure TCK test coverage of the Specification, test coverage numbers achieved, and a justification for the adequacy of TCK quality and its test coverage.
• Provide 100% signature test coverage. These tests must ensure that all of the API signatures required by the Specification are completely implemented and that only API signatures required by the Specification are included in the JSR's namespace.

If the Final Approval Ballot fails, the Spec Lead will have 30 days to revise the Specification, RI, and TCK in response to EC concerns and to resubmit modified materials to the PMO.

If no responses are received within 30 days the original decision of the EC shall stand, the PMO shall close the JSR, and the Expert Group shall disband. If the JSR was a revision to an existing Specification, the Spec Lead shall resume the role of Maintenance Lead of the current Specification (see section 5.)

If a response is received, the PMO shall circulate it to all EC members for a Final Approval Reconsideration Ballot. At the close of balloting, all ballot comments submitted by EC members shall be circulated to the Expert Group by the PMO. If the reconsideration ballot fails, the JSR will be closed and the Expert Group will disband. If the JSR was a revision to an existing Specification, the Spec Lead will resume the role of Maintenance Lead of the current Specification.

4.3 FINAL RELEASE

Within 14 days of a successful Final Approval Ballot or Reconsideration Ballot, the PMO shall publish on the JCP Website the Specification and links to information on how to obtain the RI and TCK, and shall announce the availability of these materials to both Members and the public. The published TCK information must include a means for any interested party to obtain a copy of the TCK documentation at no charge. Upon Final Release, the Expert Group will have completed its work and disbands. The Spec Lead will typically become the Maintenance Lead and may call upon Expert Group members and others for aid in that role.

The Maintenance Lead must ensure that the links to the RI and TCK remain valid. If the links become broken or non-functional the Maintenance Lead will have 30 days following notification from the PMO to correct them. If the problems are not corrected the PMO will initiate a JSR Withdrawal Ballot (if no Maintenance Release has been completed) or a Maintenance Release Withdrawal Ballot (if a Maintenance Release has been made) to determine whether the Maintenance Lead shall be judged to have abandoned the JSR. If the ballot passes the JSR itself or the relevant Maintenance Release will be marked as withdrawn.

5. MAINTENANCE

5.1 MAINTENANCE LEAD RESPONSIBILITIES

The Maintenance Lead Member is expected to assume long term ownership of the Specification, RI, and TCK while respecting the wishes of the JCP Members with regard to evolution. A Maintenance Lead shall therefore automatically be the Spec Lead for all significant future revisions to their Specification but shall not have the exclusive right to decide when a significant revision will take place (see section 2.1.1.)

The public may submit requests for clarification, interpretation, and enhancements to the Specification by logging issues through the JSR's Issue Tracker.

The ML shall consider all requests and shall decide how and if the Specification should be updated in response. The ML is not required to perform these tasks alone, but is free to consult with the former members of the Expert Group, or any other sources, to assist with the Maintenance duties.

All changes proposed by the ML shall make their way into the Specification either through the Maintenance Release process (described below) or through a new JSR. Changes appropriate for a Maintenance Release include bug-fixes, clarifications of the Specification, changes to the implementation of existing APIs, and implementation-specific enhancements. Changes introduced in Maintenance Releases ? for example, modifications to existing APIs or the addition of new APIs - must not break binary compatibility as defined by the Java Language Specification. Changes that would break binary compatibility should therefore be deferred to a new JSR.

5.1.1 RELINQUISHING OWNERSHIP

If the Maintenance Lead decides to discontinue his or her work at any time (including discontinuing maintenance activities or declining to take on the role of Spec Lead during a significant revision initiated by a new JSR) the ML, with the assistance of the PMO, should make a reasonable effort to locate another Member who is willing to take on the task. If a replacement is identified the PMO must initiate a Transfer Ballot within 30 days to enable EC members to approve the transfer of responsibilities. If the ballot succeeds, the new ML must assume his or her responsibilities within 30 days.

If no replacement can be found, or if the Transfer Ballot fails, then the PMO shall declare the Specification to be Dormant and no further maintenance can be carried out. No further Transfer Ballots will be initiated by the PMO unless a Member volunteers as ML, in which case the PMO will again have 30 days to initiate a Transfer Ballot.

5.2 MAINTENANCE REVIEW

The Maintenance Lead shall document all proposed Specification changes through the Issue Tracker and then send a request to the PMO to initiate a Maintenance Review. This request must be accompanied by an Issue List that summarizes all formal comments that have been received and that indicates the disposition of each Issue. The Maintenance Lead must also supply a summary of the proposed Specification changes, ideally in the form of a diff between the proposed and the current Specification. The Maintenance Lead must also provide an estimate of when the final materials for the Maintenance Release will be delivered. If no estimate is provided the deadline will default to 30 days.

The PMO shall post the materials on the JCP Website for public review. The Maintenance Lead may choose to modify one or more of the proposed changes based on comments received during the review.

At the close of the Maintenance Review the PMO shall initiate a 7-day Maintenance Review Ballot. During this ballot EC members should vote 'yes' if they agree that the Maintenance Release should proceed as the Spec Lead has proposed, and 'no' if they have objections to the proposed release on one of the following grounds:

• One or more of the changes proposed by the Maintenance Lead is inappropriate for a Maintenance Release and should be deferred to a follow-on JSR.
• An issue that was referenced in a "conditional yes" vote during an earlier development stage has not been addressed.
• The proposed Maintenance Release date is too far in the future. (EC members should bear in mind that many Maintenance Releases need to be synchronized with updates to a Platform, and that a Maintenance Review may therefore need to be carried out significantly in advance of the proposed Platform release.)
• Unreasonable changes have been made to the RI or TCK licensing terms.

'No' votes on other grounds shall be rejected by the PMO and shall be considered as abstentions. All 'no' votes must be accompanied by comments explaining the reason for the vote.

If the ballot fails, the Maintenance Lead may make any necessary corrections before requesting another Maintenance Review and ballot. The process may be repeated any number of times.

5.3 MAINTENANCE RELEASE

After a successful Maintenance Review Ballot the Maintenance Lead will update the Specification, RI, TCK, and Issue List as necessary and submit them to the PMO for publication in a Maintenance Release. The PMO verifies that the necessary changes have been made, and publishes the Specification, the Issue List, and pointers to the RI and TCK on the JSR Web Page.

NOTE: until the Maintenance Release stage is reached any proposed changes should be considered preliminary and subject to change, and therefore should not be implemented in shipping products.

If the Maintenance Lead fails to deliver the final materials within the time-period specified at the beginning of the Maintenance Review process the PMO shall inform the Maintenance Lead of an impending Maintenance Renewal Ballot, and shall request the Maintenance Lead to prepare a public statement to the EC that explains the reason for the delay and provides a new deadline. 30 days after this request the PMO shall initiate a Maintenance Renewal Ballot to determine whether the deadline may be extended as requested or whether the previous Maintenance Review should be rescinded and the Maintenance Lead be required to go through another Maintenance Review.

6. EXECUTIVE COMMITTEE POLICIES AND PROCEDURES

6.1 SCOPE

The Executive Committee (EC) oversees the development and evolution of the Java technologies within the JCP.

6.2 MEMBERSHIP

The EC is composed of 25 Java Community Process Members. Oracle America, Inc. has a permanent voting seat on the EC. (Oracle's representative must not be a member of the PMO.) The EC is led by a non-voting Chair from the Program Management Office.

No Member may hold more than one seat on the EC. Therefore, should a Member on the EC acquire a majority ownership of another EC member, one of those members must resign his or her seat by the effective date of the acquisition.

6.3 EC DUTIES AND RESPONSIBILITIES

1. Select JSRs for development within the JCP.
2. Review and provide guidance on proposed licensing terms of proposed JSRs.
3. Approve draft Specifications after Public Review.
4. Ensure that publicly expressed issues/concerns with a JSR are addressed by the Expert Group.
5. Give final approval to completed Specifications and their associated RIs and TCKs.
6. Decide appeals of first-level TCK test challenges.
7. Review proposed maintenance revisions and possibly require some to be carried out in a new JSR.
8. Approve the transfer of maintenance duties between Members.
9. Decide when JSRs that have not made sufficient progress through the Process should be withdrawn.
10. Provide guidance to the PMO and JCP community to promote the efficient operation of the organization and to guide the evolution of Java platforms and technologies. Such guidance may be provided by mechanisms such as publishing white papers, reports, or comments as the EC deems appropriate to express the opinions of one or both Executive Committees.
11. Members of the Executive Committee shall be dedicated to the principles of full and open competition, in full compliance with all applicable laws, including all antitrust laws of the United States and other nations and governmental bodies as appropriate. Violations of such laws can result in criminal as well as civil penalties for individuals as well as employers, depending on the jurisdiction. In particular, any discussion related to product pricing, methods or channels of distribution, division of markets or allocation of customers, among other subjects, should be avoided.

6.4 EC SELECTION PROCESS AND LENGTH OF TERM

EC members serve two-year terms, which are staggered so that half of the seats are up for election each year.

On the EC there are two Ratified Seats for every Elected Seat (hence 16 Ratified Seats and 8 Elected Seats) plus one permanent seat held by Oracle America, Inc.

6.4.1 RESIGNATION OF EC SEATS

EC members may resign their seats at any time during their term.

EC members who fail to remain JCP Members forfeit their EC seat.

Seats may also be forfeited due to non-attendance at EC meetings, as specified in the EC Standing Rules.

Vacated seats are normally filled for the remainder of their term by a special election ballot that will be held no later than two months after the resignation (unless the resignation is less than six months before the next scheduled annual election ballot.)

6.4.2 ELECTION PROCESSES

All JCP Members are eligible to vote in ballots for Ratified and Elected Seats subject to the provision that if a Member has majority-ownership of one or more other Members, then that group of Members shall collectively have one vote, which shall be cast by the person they designate to be their representative for the ballot in question.

If the PMO has reason to believe that an organization is attempting to influence the outcome of an election by instructing its Agents how to vote the PMO should take all necessary corrective actions and then report the matter to the EC for approval.

Annual elections for Ratified and Elected Seats shall be held simultaneously. Voting in these elections shall start in the third week of October.

In the interest of promoting transparency and participation in the election process the PMO shall organize teleconferences at which the Members have an opportunity to hear from and to ask questions of the candidates. If a suitable venue such as JavaOne is available the PMO shall also organize a public meeting with the same purpose.

6.4.3 SELECTION PROCESS FOR RATIFIED SEATS

Members are selected for the Ratified Seats using a ratification ballot which is carried out as follows:

• The PMO nominates Members to fill the vacant Ratified Seats with due regard for balanced community and regional representation.
• Eligible Members will vote to ratify each nominee over a 14-day ballot period.
• A nominee is ratified by a simple majority of those who cast a vote.
• If one or more of the nominees are not ratified by the vote, the PMO shall nominate additional Members as needed and hold additional ratification ballots until the vacant seats are filled.

6.4.4 SELECTION PROCESS FOR ELECTED SEATS

Members are selected for the Elected Seats using an open election process that is carried out as follows:

• Four weeks before the voting period the PMO shall post on the public JCP site a complete description of all materials that candidates will be expected to provide (e.g. any candidate statements, position papers, etc. that will be posted during the election.)
• Four weeks before the ballot period the PMO shall accept nominations for a period of 14 days. Any Member may nominate themselves except that Agents of JCP Members cannot run for Elected Seats as individuals and the PMO shall reject such nominations.
• Eligible Members may vote for as many nominees as there are vacant Elected Seats over a 14-day ballot period.
• The nominees who receive the most votes shall fill the vacant Elected Seats.
• If there is only one nominee for an Elected Seat voters shall be given the opportunity to vote ?yes? or ?no? for that candidate. To be elected, the candidate must obtain a simple majority.
• If there is no candidate for an elected seat, the ECs may choose to hold this seat open until the next election.
• Ties shall be decided by following the procedure defined in http://www.ietf.org/rfc/rfc2777.txt and using the calculator provided by W3C in http://www.w3.org/2001/05/rfc2777.

7. EXECUTIVE COMMITTEE JSR BALLOT RULES

1. All JSR ballots shall be conducted electronically and the results made public.
2. JSR ballots last 14 days except where noted in this document.
3. EC members may cast three types of votes: "yes", "no" and ?abstain?. Explicit abstentions are strongly discouraged. In the extreme and most undesirable case, an EC member may not vote at all.
4. Only "yes" and "no" votes count in determining the result of a JSR ballot.
5. Any vote may be accompanied by comments (which are are particularly encouraged in the case of abstentions.) When comments include specific suggestions for change these should be logged in the Issue Tracker to ensure that they are addressed. "No" votes must be accompanied by references to the Issue Tracker items (if any) that if resolved would persuade the member to change the vote to "yes".
6. JSR ballots are approved if (a) a majority of the votes cast are "yes" votes, and (b) a minimum of 5 "yes" votes are cast. Ballots are otherwise rejected.
7. Ballots to approve UJSRs that define the initial version of a new Platform Edition Specification or JSRs that propose changes to the Java language are approved if (a) at least a two-thirds majority of the votes cast are "yes" votes, (b) a minimum of 5 "yes" votes are cast, and (c) Oracle casts one of the "yes" votes. Ballots are otherwise rejected.
8. When a failed JSR ballot results in the closing of a JSR, at least 30 days must pass before the JSR can be re-initiated.
9. EC ballots to override a first-level decision on a TCK challenge are approved if (a) at least a two-thirds majority of the votes cast are "yes" votes, and (b) a minimum of 5 "yes" votes are cast.

IV APPENDIX A: REVISING THE JCP AND THE JSPA

Revisions to the Java Community Process (this document) and the Java Specification Participation Agreement shall be carried out using the Java Community Process with the following changes:

1. Only EC members can initiate a JSR to revise one of these documents.
2. The EC must approve the JSR.
3. The Expert Group consists of all EC members with a member of the PMO as Spec Lead.
4. There is no Reference Implementation or Technology Compatibility Kit to be delivered and no TCK appeals process to be defined.

V APPENDIX B: TRANSITIONING TO A MERGED EC

In the previous version (2.8) of this Process Document there were two separate Executive Committees, one for Java ME and one for Java SE and Java EE combined. The single Executive Committee described in this version of the Process Document will be implemented through the following process:

• The 2012 annual elections will be held as defined in JCP 2.8, but candidates will be informed that if they are elected their term will be for only a single year, since all candidates must stand for re-election in 2013.
• Immediately after the 2012 election the two ECs will be merged. Oracle and IBM's second seats will be eliminated, resulting in a single EC with 30 members.
• All subsequent JSR ballots (even for in-progress JSRs) will then be voted on by the merged EC.
• For the 2013 annual elections three Ratified and two Elected Seats will be eliminated, thereby reducing the EC to 25 members. All 25 seats will be up for re-election in 2013.
• Members elected in 2013 will be ranked to determine whether their initial term will be one or two years. The 50% of Ratified and 50% of Elected members who receive the most votes will serve an initial two-year term, while all others will serve an initial one year term.
• All members elected in 2014 and subsequently will serve a two-year term.

For clarity, note that the provisions specified in this version of the Process Document regarding a merged EC will apply to subsequent ballots on all existing JSRs, whether or not the Spec Leads of those JSRs chose to adopt this version of the Process Document in its entirety.

FOOTNOTES

1. Transfer of ownership does not mean transfer of IP rights, only transfer of the right to start again. The new Spec Lead can, however, negotiate a transfer of IP with the old Spec Lead.

2. The EC intends to remove the Confidentiality language from the next version of the JSPA.

3. This should not be interpreted as a requirement that Expert Groups create or maintain audio or video recordings of their meetings.