 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
Executive Committee Meeting Minutes
|
||||||||||
PMO |
|
|
|
ME EC |
SE/EE EC |
Total attendance: 10 |
Total attendance: 14 |
| Since 75% of the ME EC's voting members were not present,
that EC was not quorate for
this meeting Since 75% of the SE/EE EC's voting members were present, that EC was quorate for this meeting |
|
There were no personnel changes to report.
Heather Vancura delivered the EC stats presentation.
Patrick led a discussion on the plans for public teleconferences and the implications for scheduling other meetings (see the PMO Presentation.) He argued that if we scheduled separate public teleconferences interspersed among regular EC meetings then there would be times when the interval between regular EC meetings might be two months or more. After some discussion members agreed that the public teleconferences should be scheduled during the second hour of regular EC meetings. Patrick agreed to draw up an alternative 2012 meeting schedule for review.
JSR 355 (EC Merge JSR) Expert Group session
The group then convened as the JSR 355 Expert Group. Patrick reported that the JSR approval ballot had begun on the day of the EC meeting. He summarized the results of previous discussions, noting that a great deal of progress had already been made, with consensus having been achieved on most items (see the presentation.) The group discussed two items on which consensus had not yet been reached:
1) Switch from a three-year to a two-year election cycle?
After a brief discussion a straw-poll was conducted. The results showed a clear preference for a two-year cycle (17 votes to 4, with 3 abstentions.)
2) Increase the minimum number of "yes" votes required for JSR approval?
Patrick noted that the current process requires a minimum of five yes votes for JSR approval. If this were to be considered as a percentage of the number of voting members on the EC as opposed to an absolute number then this implies that on a merged EC of 25 members the minimum should be raised to eight.
Some members argued for raising the minimum to eight, on the grounds that it ought not to be "too easy" to get a JSR through the process. Others argued for caution, saying that we did not know how such a change might interact with the changes in the structure and membership of the EC - it might result in a failure to get worthy JSRs approved. Another argument for the status quo was that so long as the proposers of a JSR could get a minimum level of support they should be permitted to proceed. We then took a straw-poll, which showed a strong consensus for making no change (18 votes to 5.)
Patrick then asked whether EG members wished to make any further suggestions for changes to be incorporated into this JSR. None were made.
The group then discussed how to proceed with the JSR. We agreed that since we had such a strong consensus and had already worked out most of the details of what needed to be done, it would not be necessary to meet as a Working Group, separately from regular EC meetings. Patrick agreed to create an issue in the Issue Tracker for each of the decisions that the group had made, so that members of the public could comment if they wished. He also agreed to create a first draft of the revised Process Document (and Standing Rules, if necessary) before the next EC meeting, so that during that meeting the group could approve these documents as the submissions for Early Draft Review.
We then discussed the list of potential changes for JCP.next.3 (see notes from our last discussion.)
John Rizzo suggested that we should define what we mean by RAND (Reasonable and Non-Discriminatory) licensing terms. Patrick responded that this is a widely-used and deliberately undefined term, and that it would be very difficult (and perhaps inadvisible) to define it. Mike DeNicola noted that several other SDOs have defined different types of RAND licensing. Patrick acknowledged that OASIS, for example, defines different classes of licensing terms, but asked whether the term RAND itself had been defined. Mike responded that one of the classifications was Royalty-Free. Patrick responded that whether or not it should be permissible to charge royalties was a separate issue (though still worth discussing.) Mike agreed.
Gil Tene noted that although we have talked about the need for changes in licensing terms we have not made specific suggestions for change. He argued that an open discussion would be useful.
Steve Wolfe pointed out that this discusssion overlaps with the Standard Licensing topic that is already on the list. He noted that RAND is a pervasive legal term and that it would be dangerous to try to define it. We should instead focus on the characteristics of the kind of licensing model we want.
Gil gave as an example an issue he had raised at the previous EC meeting - the need for reliable and ongoing access to TCKs. He gave as an example the OpenJDK TCK licenses which run for one year at a time only, and which can be terminated by Oracle at the end of each term with only thirty days' notice. He noted that this made it very difficult for implementors to plan product strategies, and argued for a longer license term.
John Rizzo agreed that the approach outlined by Steve made sense. He favored Gil's proposal, and argued that the elimination of uncertainty might be one of the characteristics of licenses that we should encourage or mandate.
Patrick agreed, and suggested a couple of other characteristics: a license that is offered to one must be also offered to others, and once offered a license must continue to be offered. (We had attempted, with partial success, since these matters really require JSPA changes, to address these matters in the recent revision of the Process Document.)
We therefore agreed that a broad discussion of licensing - prior to attempting to define standardized licenses - would be useful and that we should express ourselves in terms of what licensors should or should not do rather than try to map these requirements onto a definition of RAND.
Scott Stark suggested that we needed further discussion of the relationship - and tensions - between the JSPA and Terms of Use for the participation of non-JCP members in "open and transparent" Expert Group operations. Patrick agreed that this needs clarification, but expressed the hope that this could be achieved separately from, and before the completion of, the JCP.next JSR.
Mike DeNicola suggested that Spec Leads be required to respond within a specified time to requests to join their Expert Group. Patrick noted that this would be Process Document change only, but agreed that it would be useful.
Martijn Verburg noted that the London Java Community was still gathering input. Patrick responded that we have plenty of time to discuss requirements since the JSR has not yet even been filed, and promised that ideas would not be rejected because they had missed a "deadline."
Patrick agreed to update the issues list, and suggested that because JSR 355 was going so well this would allow us to spend more time on JCP.next.3 at the next EC meeting.
