JCP.next.3 proposed changes
JCP.next.3 list of proposed changes
Updated April 4, 2012
Text in red is new since the previous version
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?)
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 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
- 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.
- 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?"
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
- 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: 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.
- 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.
in or comment on 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 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.)
- 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 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
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.
- 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
- 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.