 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
Executive Committee Meeting Minutes
|
| Tuesday January 15 |
PMO |
|
Executive Committee |
Total attendance: 22 of 24 voting members |
| Since 75% of the EC's 24 voting members were present, the EC was quorate for this meeting |
| Wednesday January 16 |
PMO |
|
Executive Committee |
Total attendance: 24 of 24 voting members |
| Since 75% of the EC's 24 voting members were present, the EC was quorate for this meeting |
The EC Standing Rules state the following penalties for non-attendance at EC meetings (note that those who participate in face-to-face meetings by phone are officially counted as absent):
There were no changes in status as a result of this meeting.
Patrick reported EC personnel changes (see the PMO Presentation for details.)
Patrick presented the usual EC stats.
Heather Vancura presented the PMO's year-end report for 2012.
Ed Lynch expressed concern about the extent to which ecosystem participation in the leadership of JSRs is polarized and dominated by Oracle (being the Spec Lead for 23 out of the 29 currently-active JSRs.) He asserted that domination by one player could be an indicator of an unhealthy ecosystem. In response to a specific question about why IBM led only one out of the 29 currently active JSRs, Ed asserted that political wrangling may have played a part. Don Deutsch asked Ed to talk to him about this (the conversation did take place). Patrick asked Ed whether he would be willing to lead a discussion on the topic at the February EC meeting. Ed agreed to do so.
EC members asked that future year-end reports add statistics on OpenJDK (for example, the number of JEPs, committers, putbacks, etc.) Ed Lynch noted that there is confusion about the relationship between JSRs and OpenJDK JEPs. Ben Evans responded that it would be helpful if OpenJDK made a distinction between implementation and spec changes. Ed stated that OpenJDK is "opening up" but that more progress needs to be made on infrastructure, issue lists, etc.
In discussing upcoming JSR Renewal Ballots we agreed that despite the fact that the Process Document states that the EC may hold a ballot when a JSR misses its deadline we will always do so (after the Spec Lead has provided a statement.) If there are indeed exceptional circumstances these will be taken into account during the vote.
In response to the report on the annual user-survey Mike DeNicola pointed out that too many people still do not understand the role of the JCP. He argued that we need more participation in JavaOne keynotes in order to get hte word out. Patrick suggested that Mike speak directly to Sharat Chander about this. Bruno Souza noted that responses to the survey are "self-selecting" since it is hosted on jcp.org. Heather responded that the survey is promoted elsewhere (eg, on java.net.)
Patrick made a brief report on the JCP's participation in Oracle's annual User-Group Summit, which started the previous day at the Conference Center in Redwood Shores. Ben Evans reported that the Adopt-a-JSR program now has many volunteers - the challenge is to turn this into real participation. Mike DeNicola reported that the leader of the Connecticut JUG (Ryan Cuprak) has asked whether we could provide a speaker to talk about the JCP. Patrick responded that we have plenty of material that people could use to make such a presentation. Ryan had also commented that the JSPA is too complex. Ben suggested that we should combine the Oracle Contributor Agreement (which participants in OpenJDK must sign) with the JSPA in order to simplify the legal reaquirements for participation. Mike Milinkovich strongly disagreed, arguing that these are two completely different processes.
We agreed that it would be helpful to hold a joint JUG/JCP summit and suggested that we might do so at Devoxx France, which Patrick will attend. Ben and Patrick agreed to work on this proposal.
Mike Milinkovich gave a presentation on the Eclipse Release Review process and walked-through an example of an actual review presentation. Members were particularly interested in the way in which Eclipse logs all contributions to ensure that there is a clear record of IP-flow. We agreed to consider this further in the context of our JSR 358 discussions the next day.
Santiago Pericas-Geertsen provided a status update on JSR 339: JAX-RS 2.0: The Java API for RESTful Web Services. He reported that the Expert Group produced three early drafts, and has received good feedback from three ongoing implementations. He also reported that the Morocco Java User Group has provided help through the Adopt-a-JSR program.
Chris Vignola provided a status update on JSR 352: Batch Applications for the Java Platform.
Werner Keil provided a status update on JSR 354: Money and Currency API. He reported that the Expert Group plans to make the initial release on whichever of the Java ME and Java SE platforms is first available.
Linda DeMichiel provided an update on the Platform Specification for Java EE 7 (see the presentation for details.) She reported that the Expert Group had received almost 1000 responses (including comments) to a public survey. Patrick noted that the interactive nature of a survey might generate more responses than a simple request for comments on a mailing-list, and suggested that other Spec Leads might usefully adopt this mechanism for obtaining feedback.
Brian Goetz reported on progress with JSR 335: Lambda Expressions for the Java Programming Language, prompting a lively discussion.
Stefano Andreani presented a proposal for a JSR to enable the development of Enhanced Hybrid Apps (applications targeting multiple mobile devices.) EC members had a variety of questions. Some expressed some doubts as to whether or not this was an appropriate matter for the JCP, since the actual Java content of the JSR would not be the majority of the effort (the bulk of the implementation would necessarily be in device-specific "drivers"). Others agreed that an approach similar to JDBC, based on the implementation specific "drivers", would solve this issue, while enabling the Java EE developers' community to become active member of the mobile developers' community.
Anthony Lai provided an update on JSR 236: Concurrency Utilities for Java EE. Several members had detailed technical questions about the implementation, and expressed concern that the approach being taken in this JSR was contrary to the direction that Brian Goetz had called out in his presentation the previous day (whereby the complexities of multi-threading are hidden in library code.)
EC members then reconvened as the JSR 358 Expert Group. Patrick provided a brief summary of the activities of the IP Working Group and discussion then focused on IBM's proposals for standard licensing terms. Steve Wolfe summarized the proposal (see the presentation for details.) He argued that the JSPA is too complex, and that modern software developers expect a simpler, "more open" licensing model. He noted that very few JSRs are led by anyone but Oracle, and suggested that this complexity is partly responsible for that disparity. He recognized that Oracle must be able to fulfil its commercial obligation and to monetize the "enormous investment" it has made in Java. He suggested that we try to craft a JSPA that builds on standard licenses while at the same time adding the necessary provisions to support Oracle's obligations. We should not start with the current JSPA and try to engineer the complexity out of it - rather we should start with something new and very simple, and add on whatever is necessary to support Oracle. He asked whether EC members generally supported the basic idea of defining standard licenses.
Several EC members expressed their support for this idea. Steve suggested that one of the standard licenses might be the OpenJDK TCK license.
Patrick noted that in the IP working group we had discussed two different approaches to matching inbound and outbound licensing terms:
He asked how the inbound license(s) could cover the case where the Spec Lead chooses a commercial outbound license for the RI or TCK?
Scott Jameson argued that the first approach is the cleanest and simplest.
Gil Tene pointed out that we must consider both patents and copyrights for each of the three artifacts: Spec, RI, and TCK. He argued that binary licenses for the RI and TCK would be sufficient for the needs of implementers, and noted that Azul is more concerned about the ability of implementers to access these binaries in a consistent manner.
Don Deutsch asked why the JSPA had been drawn up to give Spec Leads the choice of their own licenses. Steve Wolfe responded that in the early days Sun believed that the opportunity to monetize investment would encourage participation.
Steve asked whether EC members believed that such "license freedom" is still necessary.
Scott Stark argued for free access to RIs and TCKs. Steve Wolfe asked why we couldn't use the OpenJDK TCK license model. Gil responded that the license doesn't permit test results to be shared. Patrick noted that we wrote into JCP 2.8 a statement that TCK licenses must not prohibit such sharing and pointed to language in the license that explicitly permits sharing. Scott argued that this doesn't go far enough since it doesn't permit the sharing of the tests themselves. Patrick responded that this matter has been discussed within Oracle and that there is no intent to prohibit the free discussion of test results including exchanging whatever portions of the TCK might be necessary for that discussion.
Steve Harris asked why can't we simply offer a standard menu of licenses. Gil responded that this would be OK so long as provision was made for Oracle. Steve responded that we shouldn't complicate things by including a commercial license for Oracle. Gil noted that this is unrealistic, since most JSRs are led by Oracle [After the meeting Steve Harris submitted a detailed proposal to the IP Working Group, where it is under consideration.]
It was suggested that we simply include a "commercial license" as one of the options that any Spec Lead could choose. Steve Wolfe pointed out that while it is OK to predefine a list of licenses it would not be appropriate for the EC to "approve" or "disapprove" another member's choice of license.
Steve Wolfe suggested that Oracle could craft such a commercial license. Gil suggested that the license should permit "R&D" but need not necessarily permit certification of compatibility. Scott Stark replied the the license must permit "R&D" by any JSR contributor, but need not necessarily permit certification of compatibility.
EC members agreed that a small number of standard licenses will be defined. The Spec Lead must offer at least one of these. Implementers will be free to negotiate separate (additional) licenses with the Spec Lead if they wish.
Gil argued that one of the standard licenses should be modeled on the OpenJDK TCK license. Patrick pointed out that this license is in fact quite restrictive, since it permits use only on implementations derived from OpenJDK and that will be licensed under GPL. Gil responded that it should be more broadly formulated with a specific scope related to a particular body of open source work. He also reiterated his concern that licensees have continuity - a guarantee that they can continue to license the TCK. He noted that currently the license is renewable yearly and said that Azul needs more of a " runway."
We agreed that we will need a formal process for modifying the list of approved licenses. Since modifying the JSPA might be too time-consuming we might need a more lightweight process to add a license to the Addendum.
Patrick asked about the inbound grants. Scott Jameson said that this would depend on the outbound licenses. Mike Milinkovich argued that symmetry between inbound and outbound makes things very simple. Patrick asked what inbound license would correspond to an outbound commercial license. Mike suggested a commercial inbound license like the OCA that grants ownership.
Steve Wolfe asked how we should handle the additional grants necessary for inclusion in the platform? Should this be built in to the inbound license or should it be a supplemental grant? Mike Milinkovich argued that a supplemental license would be unmanagable given the number of contributors (too much paperwork.) This would prohibit hosting a project at Apache, for example.
We discussed the possibility of polling members to ask what licenses they wanted to include but agreed that this is not necessary right now since we seem to have broad agreement that these should include: GPL + classpath exception, Apache, EPL, "commercial," and "intended for inclusion in the platform."
Patrick suggested that as a next step Don Deutsch and he would talk to Oracle's lawyers to see if they could suggest/draft a list of sugggested licenses, and that they would report back to the EC at a future meeting.
Throughout this discussion we addressed, but did not resolve, the question of whether or not the Essential Patent grants defined in Section 6 of the JSPA should be preserved or whether JCP members' obligations (to grant Essential Patents even for JSRs they are not involved with) should be relaxed. In the process of the discussion we distinguished the following conditions that must be considered:
Steve Wolfe, Scott Jameson, and Mike Milinkovich agreed to get together to develop a more specific proposal on essential patents (factoring in the conditions under which grants might be terminated.)
We then moved on to a discussion of the role of individuals within the JCP and how we could ensure that all contributed IP is covered by an appropriate grant. Bruno Souza presented a summary of how several different standards organizations handle this matter. It soon became clear that although there is no consistent "industry-wide" process for handling individual memberships, the JCP's approach - whereby individuals can accrue without charge all of the benefits that commercial organizations have - is unique. Several EC members argued that we should be more concerned about ensuring that donated IP is "secure" than with encouraging large numbers of individuals to "join" the organization when they might not in fact be willing to participate in any meaningful way. Other members expressed concern that if we change the membership rules now we might undermine our recent emphasis on transparency and participation.
On the matter of individual members acting as agents of their employers we agreed that employed individuals should not be permitted to join an Expert Group unless their employer is willing to sign the JSPA. This would not necessarily amount to "free membership" for the employer since a reduced fee might be charged, and the privileges of such membership might be less than those granted to "full" members.
We suggested that we might be able to define additional categories of membership for individuals that would not involve the employer signing the JSPA (for example, an Associate Individual membership.) We decided that an ad-hoc group should be formed to work on this and to come back with suggestions. As a first step, Bruno Souza agreed to produce a summary document that could be used as a starting point for discussion.
We also agreed that - following the Eclipse model - we need an IP Provenance process to enable Spec Leads to judge the "IP quality" of contributions. We did not make any specific proposals for how to achieve this.
Ed Lynch led a brief discussion on the central role and purpose of the Executive Committee within the JCP. Among others, Mike Milinkovitch agreed it would be good to talk about what he called "EC existentialism." Ed expressed concern that some of the Spec Lead presentations during this meeting had been technically deep, which led to questions that were architectural and cross-JSR in nature. Ed suggested that the EC should be more concerned with the health of the ecosystem (indicators of health/illness, issues which may impact the ecosystem, the ways in which the Expert Group handles IP flow, and so on) and less with technical deep dives (which could position the EC as "master architect"). He asserted that JSR technical reviews should balance technology with both process and ecosystem indicators.
Several members responded that they appreciate having technical content in these presentations, and that they believed this is necessary to help them to make the appropriate judgement calls when voting on JSRs. Ed responded that he wasn't proposing to prohibit technical content, simply to ensure that it is presented at an appropriately high level. Mike Milinkovich pointed out that the first few slides in the Eclipse Project Review template do address technical questions at a high level (what is this project trying to achieve, how does it relate to other projects, and so on.)
We agreed that Mike Milinkovoch Patrick Curran and Heather Vancura would work to derive a JCP-specific template from the Eclipse document in the hope that all future Spec Lead presentations would be based on the template.
Patrick thanked Intel for hosting the meeting, and Heather Vancura for her hard work in scheduling the various Spec Lead presentations and for organizing the Tuesday evening dinner. The meeting then adjourned.
