JCP.next.3 proposed changes
JCP.next.3 list of proposed changes
Updated March 2, 2012
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
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
Can we eliminate Section 6: Special Patent Considerations for
- 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
- A complete agreement that spells out the Spec Lead's licensing obligations
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
- IP rights are granted for products delivered
no later than
six months of the JSR going final, for a period up until twelve months
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
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?"
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
- 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
- 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.
- 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
Reconcile the JSPA with transparency requirements (new)
- Ensure that the JSPA does not inhibit or conflict with transparency requirements
specified in the Process Document.
in the work of Expert Groups.
Clarification of JSPA language
- Clarify JSPA language that has led to
- 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.)
- Strengthen the TCK quality requirements?
- JSR 348 issue: Remove TCK
non-compete clauses/language (permit competing test suites.)
- 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
- 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.?)
- 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
- 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?
- 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.