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.

TCK changes

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 ExhibitB 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."