 
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: 13 |
Total attendance: 15 |
| Since 75% of the ME EC's 13 voting members were present,
that EC was quorate on this day Since 75% of the SE/EE EC's 15 voting members were present, that EC was quorate on this day |
|
PMO |
|
|
|
ME EC |
SE/EE EC |
Total attendance: 12 |
Total attendance: 14 |
| Since 75% of the ME EC's 13 voting members were present,
that EC was quorate on this day Since 75% of the SE/EE EC's 15 voting members were present, that EC was quorate on this day |
|
Patrick reported personnel changes at Samsung (see the PMO presentation for details.)
Members discussed the problems involved in "mixed mode" meetings (where some are present in person, and others attend by phone) noting that the quality of the meeting for those in the room is reduced by the necessity of accommodating those on the phone, while it is very difficult for those on the phone to participate actively.
Several members said that having a dial-in alternative made it more difficult to obtain travel approval. Most agreed that the value of the meetings for those who attend in person is reduced by the necessity of accommodating those who call in. After much discussion members voted to to make the following changes to the Standing Rules:
Because of the difficulties involved in "mixed-mode" meetings, members are strongly encouraged to attend face-to-face meetings in person. Although WebEx and a phone bridge will be provided as a convenience for those who cannot attend in person, these facilities will be placed in "read-only mode," permitting remote attendees to observe but not to participate in the meeting. Remote observers will not be counted as present at the meeting, and their non-attendance will therefore count towards the loss of voting privileges. Members who are unable to attend any EC meeting due to extraordinary circumstances may appeal to the Chair for a waiver of the non-attendance penalty. Any such waiver may be granted purely at the Chair's discretion.
Although no formal motion was made, a vote was taken with the following results:
ME EC |
SE/EE EC |
Votes: 7 yes, 2 no, 2 abstain |
Votes: 13 yes, 0 no, 0 abstain |
Patrick agreed to make the appropriate changes to the EC Standing Rules and to initiate a revision of this document to be completed before the Prague face-to-face meeting.
Mike DeNicola suggested that we should discuss the appropriate number of face-to-face meetings. Patrick agreed, suggesting that we do this later in the year when we plan the 2013 meeting schedule.
Patrick presented the usual EC stats. Magnus Lönnroth suggested that we ask Spec Leads to provide feedback on recently completed reviews. Patrick agreed to ask the PMO to do this, and to incorporate the results into future presentations.
Bruno Souza provided an update on the JustJava conference, to be held on the Friday and Saturday after the EC meeting. He explained that there would be about 600 attendees, and that the JCP would be featured during the opening keynote. There would be 42 presentations and 9 lightning talks. Most talks would be in Portugese, but all the English talks (including several from EC members) would be on the first day. Members would have an opportunity to meet with people involved in the Adopt a JSR program on Thursday evening. He explained that JUG meetings had been scheduled in several other cities so that EC members would have an opportunity to travel and meet with them.
Bruno Souza formally thanked TOTVS for their sponsorship of the EC meeting. He then introduced Luigi Nese, the President of the National Union of Data Processing workers (SEPROSP), who provided our meeting facilities. Mr Nese welcomed us to Brazil, and explained the role of his organization (to represent the interests of IT workers.) Patrick thanked him for the use of the facilities.
Member convened for a very brief JSR 355 Expert Group session (see presentation.) (The session was brief because almost all the necessary work has been completed, and the JSR must now simply work its way through the process.) Patrick noted that it will be necessary to add wording in the Process Document to state that its provisions with respect to the EC merge will be applied retroactively to all earlier versions of the Process Document. (We agreed that it would be a waste of effort to conduct Maintenance Releases to modify all earlier versions of the Process Document.) We agreed, however, to ask for a legal review of the proposed wording.
Heather Vancura gave a presentation on inactive JSRs, noting that considerable progress has been made in cleaning up JSRs. Many have been withdrawn or declared dormant, and several have been restarted (see the presentation for details.)
Mark Little noted that the modularity JSRs (277 and 294) are both on the Inactive list, and he pointed out that no progress seems to have been made on filing their replacement, despite the fact that the Spec Lead Mark Reinhold circulated the proposed JSR text six months ago. He (Mark Little) pointed out that this is giving a very bad impression to the public. Ben Evans pointed out that even though work is continuing in OpenJDK, the "historical archives" of the Lambda and Modularity Expert Group mailing lists are still private. Mark Little expressed the concern - echoed by others - that the EC will eventually be asked to "rubber stamp" work done in OpenJDK. Ben Evans pointed out that the OpenJDK processes encourage multiple experimental implementations, which is a good thing. Bruno Souza agreed. Several members pointed out that none of the Java SE8 JSRs have yet been migrated to JCP 2.8 despite Oracle's promise to do so.
It was pointed out that it is not easy to identify all active JSRs by browsing jcp.org. Patrick responded that the JSRs by Stage displays would be modified to permit this.
Bruno Souza suggested that it ought to be possible to "screen-scrape" java.net to identify the JSRs where work is being done (and where it is not.)
Members also pointed out that the umbrella JSR for Java SE8 (JSR 337) also appears to be making little progress and that its Expert Group has only two members: Oracle and IBM. After reviewing data on jcp.org Patrick pointed out that this JSR will be flagged as Inactive when the PMO conducts the next review in July.
Patrick agreed to convey these concerns to Mark Reinhold, and to ask him to respond by email and to commit to attending the next EC meeting to provide a report.
Patrick led a lengthy discussion on JCP.next.3 (see presentation.) He noted that during previous discussions EC members had asked Oracle to inform them of its response to the various items proposed for inclusion in this JSR, particularly where that response might close off certain courses of action. (They did not wish to spend time working on possible implemenatations that Oracle would be unwilling to accept.) He suggested that they go through the presentation relatively quickly, and that Don Deutsch interject where necessary to state Oracle's position on the various items. They could then revisit each topic for a more extensive discussion. This process was followed.
For the sake of clarity, in the minutes that follow each topic is addressed only once, with Oracle's official response as relayed by Don Deutsch noted first in each section. The sections reference back to the slide deck. EC members had no comments on sections of the presentation not explicitly discussed below.
Independent Implementations (slide 5)
[Gil Tene noted that the term Field of Use (FOU) restrictions is technically incorrect, since Field of Use clauses spell out what is permitted, not what is prohibited. However, since restrictions can be derived as the inverse of what is permitted the term will be sometimes be used below.]
Don Deutsch responded that Oracle reserves the right to apply Field of Use restrictions to the Java platform JSRs but is willing to modify the JSPA to clarify that all Spec Leads have this right with respect to their own JSRs. He noted that since licensing terms must be disclosed when a JSR is submitted this would necessarily require the disclosure of FOU terms. EC members would obviously take any such restrictions into account before voting to approve the JSR, and similarly Oracle would take them into consideration when deciding whether or not to incorporate third-party JSRs into the Java platforms.
Mike Milinkovich argued that Oracle's use of FOU restrictions was a "strategic mistake" since they limit where Java technologies can be implemented. The EC should not endorse this. Ben Evans and Bruno Souza argued that the use of FOU restrictions was bad for Java. Gil Tene agreed, but responded that the EC could not do anything about this. Mike DeNicola pointed out that the role of the EC is to advise Oracle in the interests of helping Java to succeed. Mike Milinkovich promised to draft a motion that the ECs could vote on, to send a message to Oracle. He did so, and the ECs voted on it the following day. The motion and the vote results are formally reported below.
Gil Tene noted that in addition to FOU terms the Java SE7 TCK license contains language which seems to prohibit using it to test an implementation of the specification. Section 1.12 states that a Product (that which is tested with the TCK) - among other restrictions - "[must] not be marketed as a technology which replaces or substitutes for a stand-alone implementation of that specification." He argued that this meant that anybody who wanted to implement Java SE7 or Java SE8 would need to privately negotiate a separate TCK license, in order to work around this prohibition. He asked whether such language would be prohibited under the JSPA and suggested that the JSPA should contain language explicitly stating that no licenses should prohibit or restrict implementations of the specification. (Patrick noted that the compatibility requirements do restrict the terms under which specs can be implemented.) Gil argued that the JSPA should explicitly state that multiple implementations be permitted and that we should start by clarifying the intention that the JSPA should convey.
Resolution on Field of Use restrictionsMike Milinkovich (Eclipse) proposed and Ben Evans (London Java Community) seconded the following motion:
"It is the opinion of the Executive Committee that field of use (FOU) restrictions are a detriment to the Java ecosystem, as they lessen the ability of Java to compete with alternative technologies. The Executive Committee recommends that FOU restrictions be precluded in future versions of the Java platform."
The motion was passed by both ECs. The results of the vote were as follows:
ME EC |
SE/EE EC |
Votes: 8 yes, 0 no, 3 abstain |
Votes: 12 yes, 0 no, 1 abstain |
Compatibility (slide 6)
Don Deutsch responded that Oracle continues to believes that strong compatibility requirements are essential to the success of the Java platform and that the integrity of the platform is best maintained if these requirements are absolute and unambiguous – all implementations must be compatible at all times and under all circumstances.
Several other members expressed their agreement with this position
and it seemed there was general consensus.
With regard to the requirement of compatibility at all times, it was pointed out this could not apply to "pre-release" OpenJDK implementations.
Licensing and Open Source (slides 7-9)
Don Deutsch responded that Oracle believes strongly that compatibility must be maintained. For this reason, he argued, all JSRs should use the “Oracle standard Spec license” that includes strong compatibility requirements. Oracle supports the effort to define recommended or approved licenses for the RI and TCK, and do not oppose the use of open-source licenses for either of these components. They insist, however, that commercial TCK licenses be permitted to enable Spec Leads to recover the sometimes-substantial costs of developing the TCK.
Gil Tene stated that the "current" TCK license is still not fully transparent since it says that there may be Field of Use restrictions that are listed in Exhibit A, which has not been disclosed. [This appears to be incorrect; the Java SE7 TCK license - reused for Java SE8 - that is disclosed on jcp.og (linked from http://jcp.org/en/jsr/detail?id=336) contains Exhibit A which clearly spells out the Field of Use terms.]
Mike DeNicola responded that licenses must be fully transparent, so that they can be examined by anyone. Gil responded that they must also be predictable; it should not be permissible to significantly alter them a year later.
Patrick and Calinel Pasteanu noted that it can be difficult to craft a single document containing language for all possible circumstances.
Ben Evans argued that specs must be freely redistributable.
Mike Milinkovich suggested that the language on slide 8 be changed from "Sun/Oracle have consistently opposed open-source licenses for the Spec, insisting on strong compatibility requirements" to "Sun/Oracle have consistently opposed the use of Spec licenses that do not impose strong compatibility requirements."
Non-Java implementations of Specs (slide 11)
Don Deutsch reported that Oracle Legal still believed that discussion of this topic should be postponed until the ongoing litigation is resolved.
Patent policy (slide 12)
Don Deutsch reported that Oracle is willing to discuss the adoption of a non-assertion patent policy and the elimination of Section 6.
Scott Jameson stated that HP has strong concerns about non-assert patent policies (they do not necessarily transfer from organization to organization.) Patrick agreed to poll EC members on their opinions by circulating to EC members the language that was drafted for JSR 306.
With regard to Section 6, Scott noted that the "carve-out" that permitted HP to withold some technologies was helpful - without it HP would have been unwilling to sign the JSPA. Mike DeNicola pointed out that there are significant differences between actively participating in a particular JSR and the broader grant of rights implied by this section.
Patrick agreed to poll EC members to determine whether this section of the JSPA is important to anybody.
The role of individuals (slide 13)
Gil Tene argued that individuals should not be treated separately from organizations. He noted that individuals and corporations are independent legal entities, and that individuals have many legal relationships with other entities (many corporations and other individuals). An employment relationship us just a legal relationship between two such entities. We cannot hope to control individuals by requiring some agreement terms with all current, past and future employers, any more than we could hope to require corporations to get the approval of all current, past, and future business partners. He therefore suggested that Exhibit B be dropped, and that instead we require that the signee of the JSPA assert that they have the legal right to make appropriate IP grants.
Werner Keil, speaking for individuals, agreed that dropping Exhibit B would be welcome.
Steve Wolfe and Scott Jameson suggested that the hub-spoke relationship between JCP members and Oracle could be addressed by standard inbound and outbound licenses.
Governance (slide 16)
Gil Tene agreed that a more extensive review of JSRs by technically-savvy people would be helpful to EC members. It was suggested that the Adopt-a-JSR program could help in this area. Someone warned against adding additional phases or delays to the JSR lifecycle.
Refactor the JSPA (slide 22)
Patrick noted that in practice we need three separate agreements: one for casual contributions to online discussions, one for Expert Group membership, and one for Spec Leads. He suggested that the first level could be met by simple Terms of Use for each JSR.
Scott Jameson warned against any solution that would result in separate agreements for each JSR, which would require multiple reviews of each JSR. He suggested re-factoring the JSPA into three rather rather than two agreements, with the lowest-level agreement being defined and enforced by the Process Document rather than on a case-by-case basis for each JSR. This agreement should be a simple click-through. Patrick agreed to reword this section of the document accordingly.
Calinel Pasteanu gave an update on Oracle's plans for Java ME (see presentation.) Jon Courtney expressed concerns about the apparent lack of plans for an evolution of CDC for applications such as set-top boxes and Blu-ray players. Calinel expressed the hope that Java SE itself (in embedded form) could form the basis of these applications, and conceded that there are no plans to evolve CDC although it will continue to be supported.
Gil Tene asked whether Java ME APIs would be migrated to Java SE. Calinel responded that while new and updated ME APIs must be designed to run on both platforms it might be some time before existing ME APIs are ported to ME. Agiunaldo asked whether the future of CDC is a "downgraded" profile of Java SE. Calinel responded that it would not be downgraded, but rather a proper subset based on modules.
Gil pointed out that CDC has many APIs that are not available in Java SE, and suggested that they should be ported to that platform so that CDC does not become "orphaned."
Calinel responded that ultimately the community must decide which APIs should be ported, and with what priorities.
Jon Courtney pointed out that he needs to develop new products today, and asked what APIs he shoul build these on. He said that embedded Java SE would require too many resources to be practical.
Gil asked whether code written for Java SE7 would run on Java ME7. Roger Riggs responded that there is some work to do on the libraries but mostly the answer is "yes." Gil pointed out that there are assumed features of the platform that are not directly expressed in the language (atomics and concurrency for example.) Roger responded that Oracle plans to address these issues in Java ME8, while noting that Java ME7 will tackle the Java VM2 specification. He conceded that there will be a necessary trade-off between footprint and functionality. Gil suggested that Oracle focus on the needs of the programmer. Ben Evans agreed.
Calinel pointed out that Sun was not concerned about aligning Java ME and Java SE, while Oracle is. He asked for time. John Rizzo said that Aplix is working closely with Oracle in this are. He argued that revolutionary changes are required if Java ME is to be saved.
Ben Evans provided an update on the AdoptAJSR and AdoptOpenJDK programs. Details can be found at the AdoptAJSR website and the AdoptOpenJDK website. Patrick congratulated the London Java Community and SouJava on their initiatives in these areas.
Aguinaldo Boquimpani provided an update on the Ginga-J standard (see presentation.) He said that the use of Java within the standard is being questioned due to Oracle's "monopoly" on parts of the standard. He noted that several manufacturers, unwilling to pay fees to Oracle, were exploring the possibility of developing a clean-room (royalty-free) implementation of the entire stack.
Aguinaldo Boquimpani discussed efforts by the ITU to normatively reference Java specifications (see presentation.) Patrick suggested that Aguinaldo repeat this presentation in a phone conference with for Don Deutsch (Oracle's standards expert) since Don was not present for this portion of the meeting. That phone conference has since happened, and Patrick is working with the ITU to obtain the necessary accreditation.
Patrick thanked SouJava and TOTVS for hosting, and the meeting adjourned.
