JCP.next.3 list of proposed changes

Updated April 4, 2012
Text in red is new since the previous version

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 focused 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. Please note that EC members have not committed to making any of the changes listed below. This is purely a list of items for discussion, and it is likely that some of the suggestions will not be implemented.

Items under consideration for JCP.next.3

Eliminate confidentiality language

The JSPA currently states that Expert Group materials that are explicitly labeled Confidential 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.)
Note also that similar language is contained in some Oracle (and other companies?) licenses

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.
- Implementer 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 Implementer making a royalty free grant of its own relevant rights.
This is particularly important for Open Source projects. Make sure they have the necessary rights to create and implement their versions of a spec before it's Final.

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 stalled ?
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 commitment 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

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: the license that is disclosed during JSR development must be available to everyone, and once offered a license must continue to be offered. (Additional licenses, which might be not be available to all implementers, would be permitted.)
- Another example: TCK licenses should offer implementers a reasonable "runway" rather than being withdraw-able on short notice. Implementers need to be able to develop multi-year product strategies.

Clarify Open Source policy

Ensure that we have a clear policy re open-source projects and that language in the JSPA (for example, the language on Independent Implementations) is consistent with that policy.

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 implementers

Reconcile the JSPA with transparency requirements

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 or comment on 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 implementers 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 implementers, 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.?)
Do we need policies to protect against a concerted effort by a group of individuals to steer the organization in a direction we disapprove of?

Clarify Compatibility policy

Ensure that we have a clear policy on compatibility and that this is unambiguously addressed in the JSPA and in any recommended or required licenses.
For example, is compatibility binary? Are incompatible implementations permitted under any circumstances?

Collaboration with other SDOs

Facilitate collaboration with other SDOs.

Fee structure

Since membership fees are defined in the JSPA, if we wish to change them this is our opportunity.
Some possible changes:
- 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.