JCP.next Master List of proposed changes
Updated March 3 2011
TODO for each item
- Process Doc or JSPA change.
- Decide whether in JSR1 or JSR2.
- Do we have consensus or need more discussion?
- Do we already have draft text?
- Find volunteer to flesh out the idea
Documents to be modified
- The JSPA
- The Process Document
- The EC Members' Guide
- Non-normative: referenced from Process Document
- The Spec Lead Guide
- Non-normative: referenced from Process Document
- 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
- 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
- Presumably yes - otherwise why make the effort to modify
so, we want people to upgrade - all members should be operating
under similar IP grants.
- Specify a lengthy transition
period (two years?) with a common deadline, allowing ample
time for review.
- New JSRs must adopt the latest JSPA. This implies that the Spec
Lead and EG members must sign it.
- When will the changes in the Process Document take effect?
- The JSPA currently prohibits us from applying Process Document changes
to JSRs that are in progress:
- "The Process is described on the JCP Web Site (at http://jcp.org),
and may be revised from time to time in accordance with terms set
forth in the Process document, provided that no such revisions shall
apply to any JSR that has already been approved for development."
- Should we modify this language to give us the power to apply to in-flight
- This wouldn't require us to do so, just make it possible if we
- If so, the language should specify that at the EC's discretion,
the requirements of the Process Document will apply to all JSRs
when they next make a formal state-change through the process.
Expert Group transparency
- JSPA changes (JSR2)
- Eliminate confidentiality language from the JSPA.
- We have draft language (from the JSR 306 draft)
- Process Document changes (JSR1)
(draft language required)
- All significant business must be carried out on public mailing lists.
- EG-private mailing list may be maintained for administrative matters.
- Issues must be tracked through a publicly viewable issue tracking mechanism.
- Expert Groups must respond publicly to all comments before JSRs can
move to the next stage.
- We have language requiring comments to be published, but not requiring
responses - this must be tightened up.
Executive Committee transparency
- Process Document changes (JSR1) (draft language required)
- Add semi-annual EC meetings that all JCP members are free to attend and
where the agenda chosen from topics suggested by the membership.
- Meeting schedules are currently not specified in the
Process Document. Should they be, or does this belong in the EG Members
- Create a public alias (with archive) for members to provide feedback to
- Need some language to address Undocumented Practices.
- For example, PMO/Oracle Legal review of license terms.
TCK transparency (needs more discussion)
- Permit and encourage publication of TCK test results so users can see who's
compatible and who's not.
- Oracle TCK licenses require confidentiality - JSPA change could
explicitly mandate openness.
- TODO: Oracle should own this - draft some language
- TCK documentation (including Compatibility Requirements) must be publicly
- Should we publish the tests too?
- TODO: Oracle to review this
- Fix potential issues with JSPA Exhibit B.
- Needs legal review
- TODO: Oracle to start this
- Others should feel free to offer suggestions.
- Individual members' votes - how to avoid ballot-stuffing?
Process Doc contains this language: "All JCP Members are eligible to
vote in a ratification ballot subject to the provision that if a Member
has majority-ownership of one or more other Members, then that group
of Members will collectively have 1 vote." If we change this to
“has majority-ownership of or is the employer of one or more other
Members” then we should be covered.
- It might be difficult for the PMO to enforce this in practice, but
we would have the authority to do so if necessary.
- Modify cost section of JSPA to permit PMO to charge a nominal fee for individuals
(if this should prove necessary)
- See Wayne Carr document for justification.
- Simple change. Since JSPA, target for JSR2.
- Fees are not mentioned in either the Process Doc or the JSPA! Should
- Non-assertion patent covenant.
- We have draft language. Patrick to circulate this and ask people
to get their lawyers to comment
- IP grants flow directly to implementers, not via Spec Lead
- Justification? TODO: Patrick to circulate this.
- Require that when the license terms associated with a JSR are significantly
changed from the previous release, this is explicitly called out.
- Require change log for licensing changes.
- Process doc change, JSR1, non-controversial.
- Suggest changing
- definition - Change Log: An area accessible
from the Spec Page that lists all changes made to the Specification
after Final Release. There are three sections: PROPOSED (changes
not yet made to the Specification), ACCEPTED (changes made), and
DEFERRED (change items to be considered in a new JSR).
- definition - Change Log: An area accessible from
the Spec Page that lists all changes made to the Specification and
Licenses after Final Release. There are four sections: PROPOSED (changes
not yet made to the Specification), ACCEPTED (changes made to the Specification),
DEFERRED (changes to be considered in a new JSR) and LICENSING
(changes to licensing terms.)
- Note also that strictly speaking the change log
does not list all changes
"after Final Release" but only those since the previous release. We should
therefore change "after Final Release" to "since the
- Clarify the requirement to disclose licenses, particularly if different
licenses are available for various types of implementation or different fields
- Can we require every variant to be disclosed? No.
- Require that offered licenses must be available to anyone who is willing
- TODO: John Rizzo to check whether existing language guarantees this,
and to suggest Process Doc changes if not.
- May need to strengthen the language in the JSPA
- After discussion with John Patrick concluded that if we intend to
make changes we should do so in the JSPA rather than the Process Doc
(that's where the obligation is defined.)
- Patrick suggests changing this:
- The Spec Lead (including Sun) for a JSR approved by the JCP shall
offer to any interested party licenses concerning the RI and TCK
-- and also the TCK separately when developed under any JSR submitted
hereafter -- on terms and conditions that are non-discriminatory,
fair and reasonable.
- To this:
- The Spec Lead (including Oracle) for a JSR approved
by the JCP shall offer to any interested party licenses concerning
the RI and TCK -- and also the TCK separately when developed under
any JSR submitted hereafter -- on terms and conditions that are
non-discriminatory, fair and reasonable. RI and TCK licenses should
permit both commercial and non-commercial implementations and should
be granted to all who agree to their conditions.
- 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
- TODO: Patrick: circulate examples for discussion
- Time-outs for inactive JSRs (JSR1) (we have draft language)
- See JSR Renewal Ballot suggestion from JSR 306
- We have language
- Enable implementations before specs are finalized,
to gain real-world experience.
- Must maintain compatibility.
- See Transplant JSR proposals from JSR 306
- Look for feedback from WG members.
- What mechanism to use to gather feedback?
- If something is critical for one or two companies but not high priority
for others - may not be "on the list"
- Better procedures to remove
or replace non-responsive spec leads and to deal with bankrupt or defunct
- Have no language.
- Process doc only, or should we modify JSPA to permit withdrawal of
- TODO: Michael to review and suggest changes.
- Make the JSPA less intimidating by refactoring into three layers
in public forums.
- A simple membership agreement for those who want voting privileges
and the right to serve on Expert Groups.
- Would the IEPA be a useful starting point?
- No - it still includes all of the Spec Lead obligations - it's
no better a starting-point than the JSPA itself.
- The complexities of IP and compatibility obligations are required only
for Spec Leads – factor these out into a separate agreement.
by Expert Groups
- Should ensure sufficient IP grants, but not impose
requirements more strict than the JSPA
- See Wayne Carr document for explanation.
- How to police?
- Spec lead tells us in submission what collab software will be used
- Oracle legal to report - EC members can review the report?
- If OK - add to approved list. If not, look elsewhere
- May need to review each time, even if previously reviewed.
- Incorporate this into JSR Submission process
- TODO: Patrick to talk to Oracle Legal about this.
- JSR2? (more effort - legal work required)
- Is this a Process Doc or a JSPA change?
- Do in two stages?
- Non-controversial, but we have no draft language yet
- No barriers to participation in Expert Groups.
- Requests to join EGs and the Spec Lead's responses must be made in
- Discuss with EC again.
- Define a process for penalizing
EG members who do not participate.
- Lose voting privileges. Look at OASIS, W3C.
- Section 2.1.3: Uncooperative or unresponsive Expert Group Members seems
incomplete. It starts by talking about how to deal with EG members but the
proposed remedies then address the Spec Lead role. Clarify.
- Clarify requirements for RI and TCK to be posted within x weeks of Final
(and Maintenance Release?)
- How to "undo" if materials not posted?
- Penalties for EC members who do not attend meetings or do not vote.
- First step: lose voting privileges (which would solve the quorum problem.)
- Would need to change the definition of quorum to be "of those who
are eligible to vote."
- Suggestion from Eduardo: if you miss two meetings
in a row you lose voting privileges. Can restore by attending two
meetings in a row.
- Second step?
- Lose membership if...
- Miss x meetings in a year...
- Losing voting privileges more than x times per year...
- If people routinely miss meetings, members who attend only occasionally
- Change Process, JSPA and IEPA to wind down use of IEPA. Remove IEPA
reference in JSPA. Change IEPA to say it will no longer be offered. Leave
the ability to modify the IEPA in the Process document until there
are no IEPA members, but note it is no longer available for new members
of any EG. When the
last JSR EG disbands that has an IEPA member in it, revisit this and remove
(IEPA, JSPA – much later when there are no IEPA members, a
Process doc change finishes the
Remove the ambiguity of the term Spec Lead in the Process Document
(sometimes it refers to the Member and sometimes to the person representing
the Member and leading the EG.)
- Begin phase-out of IEPA
- IEPA is no longer used, but
it had no termination provision so those under it remain in JCP until the JSR
they joined disbands.
- Remove Process Doc section 1.1.4 J2ME building blocks
- Correct typos
and errors in JSPA.
- Correct typos and errors in Process Document.
Prohibit major Patform changes in Maintenance releases (see MR2 of JSR
Review Appendix A of Process Document (Eduardo has some concerns?)
- See Wayne Carr document for explanation
- Eduardo to review and report back (also on "lack of clarity when things
are supposed to happen")
Branding and compatibility
- Emphasize the value of compatibility & the brand and the risks of using
- Relax all-or-nothing compatibility reqiurements?
- TODO: Patrick to give the the compatibility presentation to EC...
- Publish lists of compatible implementations and report what optional features
- Publish lists of incompatible implementations.
- No JSPA or Process Doc changes required for these proposals – Oracle/PMO
commitment is sufficient?
- More formal reporting requirements for conformance claims?
- Where would the language be written? In TCK licenses?
- Too hidden?
- How to make this more public?
- What would the remedy be if someone makes a false claim?
- Oracle to drive this...
- Clarification of 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
- Enable and encourage the establishment of more formal relationships with
other standards bodies.
- Some disagreement as to whether Confidentiality is an
obstacle to liaison with other organizations. Need more discussion.
- Transplant JSRs (enable incorporation and standardization of work
developed outside the JCP.
- Need some use-cases?
- Early availability was an issue. Permitting implementations before
specs go final. IP-flow issues?
- Hybrid JSRs (allowing non-Java implementations of a JSR's specification)
- Discuss these two next week - notify EC members in advance we'll be doing
so - invite those who are interested to participate - review the actual docs/drafts
- Address the issue of where litigation should be located. California, or
- California is an obstacle to Brazilian state involvement.
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."
- Incorporate relevant portions of the EC Members' Guide (eg the sepecification
of quorum) into the Process Document.
- Increase fees?
- Deal with the Maintenance Expert Group problem
- Spec Leads want the EG to persist after Final Release. The Process
Doc states that the EG must disband.
- Solution is to replace the Expert Group with a Maintenance
- Initial membership of the MEG would be recruited (automatically?)
from the EG?
- We need to maintain the history of which members were on the EG when
it completed its work, but it should also be possible for EG to evolve.
- We really should "snapshot" the membership at every Release.
- Also clean up Maintenance Release requirements. Currently there's no absolute
requirement for the Maintenance Lead to actually deliver an updated spec,
RI, and TCK. (The process simply says "the maintenance changes will be considered
final when the RI and TCK are synchronized with the Specification. We should
require a formal Maintenance Release just as we do a Final Release.
- Legal collaboration between Oracle and others' lawyers.
- Decide on location for f2f (Redwood Shores or Santa Clara?)
- Assume 9-5 on Tusday, 9-4 on Wednesday
- Do the compatibility presentation at the March f2f
- Do this for agility purposes alone?
- Necessary for "co-development" work outside of as well as inside the JCP
- Do not permit indefinite shipment - insist that existing products be made
compatible within x months?
- On the list
- Under what conditions would we permit this to be applied to an existing JSR?
- Makes JCP more attractive - encourages interoperability with other platforms
- On the list.