JCP.next.3 list of proposed changes

Updated March 2, 2012

Background

JSR 348 was the first of three proposed JSRs to modify the JCP's processes. That JSR deliberately focused on non-controversial changes that could be implemented within a few months. Difficult or controversial matters such as issues affecting governance or IP flow, and everything that would require a change to the JSPA, were postponed to a follow-on JSR.

The second JSR (JSR 355) is forcused solely on merging the two Executive Committees, and like JSR 348 will change only the Process Document and Standing Rules.

This document lists items that have been suggested for inclusion in the third JSR (JCP.next.3), which will modify the JSPA as well as the Process Document.

Items under consideration for JCP.next.3

Eliminate confidentiality language

The JSPA currently permits Expert Group materials to be explicitly labeled Confidential. Such items must be kept confidential until after Public Review. We propose to remove this language.
Note that there is also confidentiality language in section 4B, although the term Confidential is not used there. (Early access implementations must not be released before Public Review.)

Oracle Legal's review of license terms (Process Document change only)

The process whereby Oracle Legal reviews proposed licenses, and can hold up posting of JSRs until these are considered satisfactory (compatible with the JSPA), is undocumented.
Arbitration process?

Refactor the JSPA

Refactor the JSPA into two documents to make it simpler and less intimidating for individuals:

A simple membership agreement for those who want voting privileges and the right to serve on Expert Groups but who will not serve as Spec Leads.
A complete agreement that spells out the Spec Lead's licensing obligations

Can we eliminate Section 6: Special Patent Considerations for individuals?

Non-assertion patent covenant

Replace current patent language with a non-assertion covenant.
- Would still need supplementary language to ensure that patents transfer with IP ownership.

Enable implementations before specs are finalized

Proposals for Transplant JSRs were drafted for JSR 306. These would permit Early Commercial Implementations (with fully-vested IP rights) under certain conditions.
- The non-final implementation is delivered in a name space that is different from the name space for the final JSR (and not in java.* or javax.*.)
- IP rights are granted for products delivered no later than six months of the JSR going final, for a period up until twelve months after the JSR goes final.
- Implementor gets IP rights to continue to do so indefinitely provided a fully-compatible version of the final JSR is delivered in the same product.
- These IP grants are conditional on the implementor making a royalty free grant of its own relevant rights.

Non-Java implementations of JSRs

Proposals for Hybrid JSRs were drafted for JSR 306. These would permit non-Java implementations of JCP specifications.
- For use with the Java platform, the traditional JSPA terms would apply (IP grants only for compatible implementations).
- For use outside the Java platform, an IP grant based on the OASIS Royalty Free on Limited Terms policy would apply.
Oracle Legal requests that discussion of this item be postponed.

Allow JSRs to reach a natural end of life

Is the obligation to license IP, RI, and TCK "perpetual?"
- JSRs reach a natural end of life but there's no allowance for this in the JSPA.
- Is the Spec Lead obliged to provide a functional TCK 20 years after Final Release?

Clarify IP flow in the case of bankruptcy or Spec-Lead abandonment

Can/should IP ownership default to a neutral third-party if the Spec Lead abandons the JSR or if bankruptcy proceedings become stalledif ?
Do we need some kind of escrow process for source-code?

Must the Expert Group dissolve at Final Release?

This requirement seems to run counter to modern software development practice and to our desire that the Spec Lead and Expert Group make a long-term committment to maintain the technology.
Do we need to specify how IP flows, and when IP grants vest, during the Maintenance process?
Should people be permitted to withdraw their IP grants? At any time?
- JSPA Section 4D D. Withdrawal of Contributions due to Change in Announced License Terms says Yes.
- Review this language - make sure it's consistent with possibly-changed processes.

Licensing (new)

Define the characteristics we want in JCP licenses - what they should or should not do - but don't try to formally define RAND.
- For example: a license that is offered to one must be also offered to others, and once offered a license must continue to be offered.
- Another example: TCK licenses should offer implementors a reasonable "runway" rather than being withdraw-able on short notice. Implementors need to be able to develop multi-year product strategies.

Standardized licenses

Define a mandatory standard Spec License.
Define standard RI and TCK licenses from which Spec Lead may choose.
- Provide separate licenses for open source and commercial implementors.

Reconcile the JSPA with transparency requirements (new)

Ensure that the JSPA does not inhibit or conflict with transparency requirements specified in the Process Document.
Ensure that appropriate Terms of Use are applied when non-members participate in the work of Expert Groups.

Clarification of JSPA language

Clarify JSPA language that has led to previous disputes.
Ensure that the modified JSPA does not grant rights to one participant that others don't have.

Clarify the meaning and role of the Reference Implementation

The JSPA currently conflates two roles for the RI:
- A proof-of concept implementation that is used by implementors as an aid to testing and debugging their implementation.
- The form in which the Spec Lead licenses its implementation for the creation of derivative works.
Clarify that a binary RI must be released (the former role cannot be fulfilled without a binary.)

TCK changes

Strengthen the TCK quality requirements?
JSR 348 issue: Remove TCK non-compete clauses/language (permit competing test suites.)

Governance

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

Clarification of the roles of individuals and their employers

Does the current Exhibit B adequately ensure that IP rights are granted and that we have a level playing-field?
- Some companies encourage their employees to join as individuals.
Does Section 6: Special Patent Considerations apply when an employee joins as an individual?
- The employer's release references only a specific JSR.
Clarify the Agent relationship (who is a "duly authorized representative of Employer?")
- Restrict the number of Agents of non-member commercial organization who may join the JCP in their own right?
Implementation issues:
- People change employers.
- What about members of groups where there is no employer relationship (non-profits, Java User Groups, etc.?)

Fee structure

Modify cost structure (in JSPA) to permit PMO to charge a nominal fee for individuals if this should prove necessary.
- Eg, "fees for individuals are $250 per year... Fees may be waived at the discretion of the PMO."
Explicitly place JUGs in the same category as individuals.
Create a two-tier commercial-entity fee structure (cheaper fees for small companies)

Cleanup

Phase-out the Individual Expert Participation Agreement (IEPA) provisions - no longer used.
Do we need a formal Early Draft Review now that we have transparency requirements and EGs continuously publish work-in-progress?

Procedural issues

Define the process whereby the new JSPA will be phased in.
- 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.
Modify existing language to permit some or all of Process Doc changes to be applied to in-flight JSRs.