JCP.next JSR2 list of proposed changes

Updated March 29 2011

Transparency

Eliminate confidentiality language from the JSPA.
- We have draft language (from the JSR 306 draft)

Report what optional features are implemented?
- Too complicated? We can add this in JSR2.
Patrick: review JSR1 and extract more complex items to here for consideration.

Make the JSPA less intimidating by refactoring into three layers
- Simple Terms Of Use for non-members who wish to comment on specs in public forums.
- A simple membership agreement for those who want voting privileges and the right to serve on Expert Groups.
- The complexities of IP and compatibility obligations are required only for Spec Leads – factor these out into a separate agreement.

Enable implementations before specs are finalized, to gain real-world experience.
- Must maintain compatibility.
- See Transplant JSR proposals
- Must declare during JSR submission that this is a Transplant JSR or that it will become one if the JSR doesn't complete within 3 years.
  - The "it will become one" addition is new - need to revise the existing language.

Non-assertion patent covenant.
- We have draft language. Patrick to circulate this and ask people to get their lawyers to comment
- May need to add wording to ensure that the non-assert promise transfers with IP ownership.
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.
Fix potential issues with JSPA Exhibit B.
- Needs legal review
- TODO: Oracle to start this
- Others should feel free to offer suggestions.
- Clarify what is a "duly authorized representative of Employer."
  - Replace "Employer" with "Assignee"
- Implementation issues:
  - People change employers
    - Require individuals to "re-confirm" their membership each year and at that point to confirm that the Exhibit B is still valid or submit a new one.
    - PMO to require a current Exhibit B whenever an individual (or someone associated with a group where there is not an employer-employee relationship joins an EG.
  - What about members of groups where there is no employer relationship?
    - Eg JUG, research institution, university, open source community.
Incorporate the Hybrid and Transplant JSR proposals from JSR 306. .,
- Transplant JSRs (enable incorporation and standardization of workdeveloped outside the JCP)
- Hybrid JSRs (allowing non-Java implementations of a JSR's specification)

Define a mandatory standard Spec License.
- TODO: Patrick to circulate the "recommended" Spec License for comments.
Recommend (but do not require) standard RI and TCK licenses.
- Provide separate templates for Independent (open source) and commercial implementors.
- TODO: Patrick to circulate examples for discussion

Clarifiy the JSPA as discussed within the EC.
- Members will be asked to sign the new/revised JSPA (resulting from JSR2) - some may insist on this clarification at that point.
- Modified JSPA should not grant rights to one player that others don't have.
Address the issue of where litigation should be located. California, or elsewhere?
- California is an obstacle to Brazilian state involvement.
- According to Java Champion Douglas Jenssen this is also an issue within the US. He has said in private mail: "The issue is a legal one, where do legal disputes between Sun/Oracle and a member -- whether individual, sponsored by his employer, or corporation -- get litigated. When I last met with the JCP, the answer was it has to be in California. No public institution such as a state university is going to agree to that, and many corporations will not agree either. Hence I was told there are no members from public universities, only from private ones that choose to agree."
- The JSPA says: "Any action related to this Agreement will be governed by California law, excluding choice of law rules, provided, however that neither party has consented to the jurisdiction of any court located in the other party´s country of incorporation."

Should we change?
Add a $250 fee (which we can waive) for individuals as a recourse against mischief?

Phase-out the IEPA provisions (no longer used.)
- IEPA agreements never expire - we need to deal with this.
- Encourage existing IEPA members to "resign" or to become full members.
  - There aren't very many of them, so hopefully the PMO can handle this.
- Remove references to IEPA from JSPA.
  - Need legal approval for this.
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."

When will the changes in the JSPA take effect?
- We can not require that an existing JSR be ruled by new version of the JSPA.
- Currently there is no requirement that members upgrade to the latest JSPA.
  - Note that section 2B uses the term "expires" but it seems there is no way for a JSPA to expire (merely "terminate") - we should fix this,
- The JSPA also forbids us from applying changes to JSRs that are in-progress:
- Will the new version be version 3 (containing significant legal changes?)
  - Presumably yes - otherwise why make the effort to modify it?
  - If so, we want people to upgrade - all members should be operating under similar IP grants.
- Recommendation:
  - Specify a lengthy transition period (two years?) with a common deadline, allowing ample time for review.
  - 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.

Later (JSR2) make sure we've covered issues around withdrawing contribution