 
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: 9 of 11 voting members |
Total attendance: 13 of 16 voting members |
| Since 75% of the ME EC's 11 voting members were present,
that EC was quorate for this meeting Since 75% of the SE/EE EC's 16 voting members were present, that EC was quorate for this meeting |
|
PMO |
|
|
|
ME EC |
SE/EE EC |
Total attendance: 9 of 11 voting members |
Total attendance: 13 of 16 voting members |
| Since 75% of the ME EC's 11 voting members were present,
that EC was quorate for this meeting Since 75% of the SE/EE EC's 16 voting members were present, that EC was quorate for this meeting |
|
The EC Standing Rules state the following penalties for non-attendance at EC meetings (note those who participate in face-to-face meetings by phone are officially counted as absent):
There were no status changes following this meeting, but both AT&T and RIM were warned that if they do not attend the October meeting they will lose their seats (AT&T because they would have missed two thirds of the meetings since the Standing Rules went into effect, and RIM because they would have missed five meetings in a row.)
Note: Ericsson and SouJava were excused from attendance due to unexpected family illnesses.
Steve Wolfe from IBM had asked the EC to consider the "attendance rules" for the JSR 358 Expert Group portion of this meeting. He argued that the EC Standing Rules, which do not guarantee real-time two-way communications to those who attend by phone, should not apply to the portions of the EC meeting when the EC is in session as the Expert Group for JSR 358. Patrick agreed to raise this for discussion at the beginning of this meeting.
After a very brief discussion members agreed with Steve's position, and promised to open up the phone line for full two-way communication during the JSR 358 portion of the meeting.
Patrick reported EC personnel changes (see the PMO presentation for details.) Scott Jameson asked why CableLabs resigned their seat. Patrick explained that the recent announcements of direction for Java ME, coupled with the decision to postpone modularity from Java SE 8 to Java SE 9, left them with no viable future path to evolve their CDC-based software. Consequently they felt they could not justify their continued participation in the EC. (For background on this matter see the see the minutes of a discussion on a presentation given by Jon Courtney (The other Java ME) at the EC's face-to-face meeting in Korea in May 2011.)
Don Deutsch asked whether those who are in jeopardy of losing their seats due to non-attendance receive a private warning from the PMO. Patrick responded that they did. Don suggested that it would be helpful to add such information to the meeting minutes in the section following the roll-call. Patrick agreed to do so, and has implemented this suggestion in these minutes (see above.)
Patrick presented the usual EC stats and (as usual) reminded EC members of their obligation to vote in JSR ballots.
Patrick presented the first of several PMO reports, on the PMO's activities to update the membership lists and to collect fees (see the PMO report.)
He reported that although we are seeing a steady flow of new membership applications, including some from corporations, because our membership lists have not been "cleaned" in several years due to the transition from Sun to Oracle and the fact that membership fees were waived during the first year after that, the number of paying corporate members would be significantly reduced.
The reasons for this were several: many corporations who had previously paid fees are now entitled to free membership as Java licensees. Others were unwilling or unable to pay the yearly $5000 fee, or had ceased to exist as independent companies due to mergers, acquisitions, or bankruptcies. Still others had joined in order to participate in a particular JSR that was now complete, and therefore had no further interest in participating.
Discussion focussed primarily on the difficulty of collecting fees, and on the relatively small amount that fees bring in (less than $200K/year) relative to the cost of running the PMO. Several members suggested that the fees be reduced eliminated if they are inhibiting participation. (Patrick noted that in the context of the JSR 358 work we have plans to introduce a new lower fee for small companies.)
Gil Tene asked what benefits accrue to corporate members. Patrick responded that recent transparency initiatives have blurred the difference between non-members and members (since non-members can now observe the work of Expert Groups and can even participate in an informal manner) but pointed out that membership is still required to join an Expert Group. Don Deutsch noted that this is no different from other standards organizations that adopt a "pay to play" model. Scott Jameson argued that there is value in requiring fees - those who have some "skin in the game" tend to participate more.
Gil Tene argued that it seemed unfair that only 20% of the corporate members pay fees (the other 80% being entitled to free membership because they license Java from Oracle.) Patrick responded that in this role they do pay substantial sums to Oracle, and that it would be difficult and unreasonable to have them pay more.
Don Deutsch argued that cost of running the PMO and the matter of fees is really Oracle's problem, and need not be discussed by the EC. He was more concerned about the cases in which corporations encourage their employees to join the JCP as individuals in order to avoid paying fees, noting that in this way their IP commitments are reduced. (Individuals do not make "blanket" commitments of essential patents for all JSRs as do corporations.) Gile Tene and others agreed that this problem needs to be fixed. (The matter was taken up again during the JSR 358 discussions on the following day.)
In further discussion someone asked whether the list of JUG members on jcp.org is up to date. Patrick promised to find out. (It is, and currently lists 32 JUG members.) He also agreed to find out how many corporate members resigned or changed status for each of the various reasons given in the report.
Patrick then reported that the next stages of the operation would be to review all of the licensee members (ensuring that we have up to date contact information) and then to clean up the individual membership list. (He has reported several times in the past that since we do not charge individuals there are many people still listed as members who have effectively "lapsed.") The cleanup plan will involve cancelling the memberships of those individuals we cannot contact, and requiring all individual members to reconfirm each year through a web-form that they wish to continue as members. The results will be a significantly smaller but much higher-quality membership list.
Patrick reported the PMO's plans for JCP events at JavaOne (see the PMO report.) Van Riper pointed out that the public EC meeting clashes with community events on the Sunday, and that this would be a problem. Gil Tene said that in general Sunday was not the best choice for this event since many people do not attend on that day. Patrick agreed that this might be a problem (as indeed it was - very few people attended the public EC meeting) and promised to try to find a better time-slot next year.
Patrick reported the status of JSRs' adoption of JCP 2.8. He noted that the majority of in-flight JSRs have voluntarily upgraded to 2.8, and encouraged all members to pressure the others to do so. Gil Tene asked the PMO to let EC members know if any Spec Leads are resisting migration, and if so what their reasons were. Patrick promised to do so. For full details and statistics see the PMO report.
Patrick noted that we need help in tracking whether EGs that have agreed to operate under 2.8 are actually operating transparently. He encouraged the community to help with this.
Mike DeNicola suggested that in future JSRs that are not operating under 2.8 should be ineligible for the annual awards.
Patrick then inserted into the record a presentation giving an overview of Oracle's plans for JavaOne.
Werner Keil gave a presentation on the work of the Open Geospatial Consortium. Don Deutsch asked Werner what he was asking of the JCP since Werner had labeled his presentation Collaboration with the Open Geospatial Consortium. Don noted that the work of the Consortium is wide-ranging, and that they are collaborating with a large number of standards organizations. He asked who might drive such collaboration with the JCP. Werner responded that several of the participants in the OGC are interested in Java, and that maybe they would do so. Calinel Pasteanu asked how OGC and JCP specs might overlap. Mike Milinkovich responded that in the future there might well be JCP specs in these areas. He suggested that if so the JCP should reference OGC specs rather than reinvent the wheel.
Patrick provided an update on the Inactive JSR situation. He noted that the PMO has made excellent progress and that the number of JSRs labeled Inactive has been reduced from 50 to 2. For details and statistics see the presentation.
Gil Tene asked whether we have problems with JSRs "in limbo." Patrick responded that there are problems in these cases. If the work of an Expert Group becomes stalled it is not usually feasible for someone else to take on the work since it's unclear who owns the IP that has already been contributed. This is something that should be addressed in JSR 358.
Ben Evans provided a verbal update (no presentation) on the Adopt-a-JSR and Adopt-OpenJDK programs. He noted that these were originally conceived as two separate programs, but to the average Java developer who "just wants to contribute to Java" there is no difference. The LJC is working to figure out how the programs should be adjusted accordingly.
He reported that some JSRs (for example, JMS 2.0) have very little community coverage. This is unfortunate, but since people are volunteering they will do so in the areas that interest them, and we cannot force them to participate in something that they do not find compelling.
Patrick asked whether any volunteers were doing non-technical work. Ben responded that they were not - Java developers want to do technical work. He suggested talking to Bruno Souza from SouJava and Sonya Barry (from java.net) about the possibility of automating the process of tracking activity on public mailing lists and issue trackers.
Ben reported that several "hack days" have been held in London, and that these have been extremely successful, each with as many participants as they can handle (since they need instructors.) About 50 developers have attended each event.
Some JSRs (310, Identity) have had much more focussed participation with a small number of developers helping out.
Gil Tene led a discussion on the topic (previously unscheduled in the agenda) of how the EC reviews JSRs. He expressed concern about the difficulty of reviewing the TCK, and suggested that Expert Groups should make a presentation to the EC before the Final Approval Ballot in order to explain and justify that their work is complete. He said he would be particularly interested in a presentation from the developers of the JCK (the TCK for Java SE) since this is probably the most significant and thorough of all TCKs. Patrick suggested that the state of the Issue Tracker should also be reviewed.
Mike Milinkovich pointed out that at Eclipse they do a Release Review for each project before it completes. (There is a template for this process.) The review does not necessarily take the form of a meeting but is rather exception-based, and a meeting will be called if there are significant concerns. An imporant part of the Review is the presentation of an IP log.
Lakshmi Dontamsetti pointed out that our current processes already require Expert Groups to provide a TCK Coverage Document summarizing the quality of the TCK. Patrick noted that even the Oracle TCK teams now tend to produce these by rote, using boilerplate language. He asked (as did Don Deutsch) which EC members do detailed reviews of TCKs before voting in Final Approval Ballots. Not many admitted to doing so. Calinel Pasteanu pointed out that those EC members who intend to license a JSR will do a deep review, since their business will depend on the quality of the JSR's artifacts.
Gil Tene repeated that he wants reassurance that a JSR is of high quality - he does not simply want to "rubber-stamp" it.
Marquart Franz asked whether we really have a problem here, and noted that improving the quality of the RI and TCK is very expensive. Don Deutsch suggested that the whole process might be "self-auditing" and that any TCK problems would surface through the test appeals process once the TCK was actually put into use. Jutta Bindewald asked whether we should record who performed "deep reviews." Don Deutsch, pointing out that Oracle is the Spec Lead for the majority of JSRs, asked whether members trusted Oracle to do a good job. Scott Jameson suggested that any review should be performed "offline" since he would need to involve various technical people from HP.
Since several members seemed to feel that additional scrutiny might be unnecessary and simply impose more process overhead, Patrick suggested that Mike Milinkovich prepare a presentation on Eclipse's Release Review process for a future EC meeting, and that we continue the discussion after that. Mike agreed to do so.
Ed Burns gave a presentation on JSR 344: JavaServer Faces 2.2. He was asked how many members of the Expert Group are active. He responded: about 12. Ed also reported that there is a large community of non-EG members who participate more casually. Patrick asked him how the requirements of JSR 348 (JCP 2.8) are impacting his work, and whether we missed anything. He responded that there were no problems, and that it was simple to "migrate" to 2.8 since he was already meeting its transparency requirements.
Since JSF has gone through several revisions Ed was asked whether the same EG members participated from release to release. He responded that there has been lots of continuity, and noted that a "train model" for releases was a good thing. He noted that because the work is carried out transparently non-EG members have also made significant contributions. When asked how he manages contributions from non-EG members he said that he requires that significant contributions be made under the Oracle Contributor Agreement (OCA) but that for more casual contributions he relies on the java.net Terms of Use.
Jitendra Kotamraju gave a presentation on JSR 353: Java API for JSON Processing. Patrick asked whether he had received feedback from non-EG members. He responded that he had received a little. Ben Evans asked whether the Chennai Java User Group had made any contributions through the Adopt-a-JSR program. Jita said that they had not done much. Ben promised to follow up. Gile Tene asked how the TCK was progressing. Jita said it was coming along fine.
We then adjourned for the day. On Wednesday we re-assembled as the JSR 358 Expert Group.
Steve Wolfe presented a proposal for "flattening" the IP flow as an alternative to the current hub and spoke model whereby IP vests in the Spec Lead who in turn licenses it to implementors. He noted that having IP vest in (flow through) the Spec Lead, and permitting the Spec Lead to choose the licensing terms was introduced in the early days of the JCP as an incentive to encourage organizations to take on the Spec Lead role.
Mike DeNicola asked when IP grants would "vest" - when made, or when a JSR went final. Steve answered "when made."
Noting that the proposal mentions special IP rights for Oracle to permit it to fulfil its obligations under the TLDA (Technology License and Distribution Agreement,) Patrick noted that Oracle gets no special rights now. Gil Tene asked why this is necessary. Steve responded because Oracle is Spec Lead for the platforms. Gil asked whether this proposal would grant rights to Oracle that they do not have today. Mike Milinkovich pointed out that if special rights are granted to Oracle then this proposal could not be considered "flat" - there is still a "hub." Gil Tene noted that the proposal would decrease transparency, since it would be necessary to decode all existing TLDAs in order to understand what rights were being granted. David Bosschaert suggested that all future TLDAs might also need to be considered.
Calinel asked whether licensees would need to negotiate agreements with each contributor to a JSR. Steve responded "no" - the grants would be automatic. Calinel asked "what about litigation situations?" Wouldn't these require dealing with all contributors - knowing who contributed what? David suggested that IP could be vested into a not-for-profit organization. Gil Tene responded that this would still be a "hub" albeit no longer Oracle. Steve responded that different kinds of IP are treated differently. Patent rights would flow directly to end-users. Mike Milinkovich noted that this is how Eclipse works today except for the special grants to Oracle.
Mike DeNicola pointed out that the real issue is not Oracle's TLDA obligations, but rather that the "special grant" is needed for inclusion in the platforms. Steve Wolfe noted that the problem is caused by existing TLDAs and stated that we cannot introduce changes that would require these to be renegotiated.
Mike Milinkovich stated that if IP does not vest in a single owner then we would need to standardize all Spec, RI, and TCK licenses. Steve Wolfe disagreed. Mike said that sections 3 and 4 of the Eclipse Public License provide an example of how this kind of proposal might be implemented.
Mike DeNicola insisted that the TLDA should not be referenced. Steve Wolfe agreed that it would be preferable to say "you give the following supplementary rights to Oracle to permit inclusion in the platform..." He noted that the complexities of the IP regime and licensing models inhibit people from joining the JCP.
Gil Tene suggested that broad essential patent grants (such as are defined in Section 6 of the current JSPA) on Royalty Free terms would not be acceptable to members. If such broad grants are made, they would need to be on RAND terms.
Scott Jameson pointed out that EC members need to know whether this proposal might be acceptable to Oracle. Don Deutsch promised to provide a response at the October EC meeting.
Anish Karmarkar asked why it is necessary to call out end-users at all, , since they would be covered by the 'exhaustion doctrine'. Steve Wolfe responded that he wanted to ensure that everyone in the value-chain is included. Mike Milinkovich noted that there is (and would still be) a separate license spelling out end-user rights.
[A placeholder issue has been created to track this. See http://java.net/jira/browse/JSR358-41.]
David Bosschaert then presented Red Hat's position on IP flow. Patrick noted that the proposal made no mention of essential patent grants by "non contributors" (as currently defined in Section 6 of the JSPA.) Don Deutsch noted that the requirements called out in the first two bullets on the slide are already implemented today. David responded that the third bullet is an endorsement of a flat rather than a hub-and-spoke model. Gil Tene noted that the proposal only addresses the Spec license, and ignores the RI and TCK, which must also be considered. Members agreed that the Red Hat proposal does not add anything significant to the more detailed proposal by IBM.
Ben Evans reported the London Java Community's position verbally (no presentation.) He stated that the LJC agrees with Red Hat's position, but is concerned about the broad patent grants in Section 6, which he feels might discourage people from participating. The requirement to opt-out might be a discouragement now that full transparency is required, since the simple act of identifying patents might be considered a problem. He asked whether this section might be eliminated. Gil Tene responded that doing so would eliminate rights that have been granted up to now. Steve Wolfe asked Ben to clarify what he meant by elimination. Ben responded that he meant only to eliminate the obligations incurred by those who do not participate in JSRs.
David Bosschaert asked why the grants in Section 6 are so broad. Steve responded that at the time the current version of the JSPA was drawn up there was very little Java adoption, and that they wanted to create an environment with the least possible uncertainty about IP rights. David asked whether it would be risky to remove this now. Steve responded that this would introduce additional uncertainty. David responded that non-JCP members might also have relevant patent rights and that this issue cannot be addressed by language in the JSPA. Steve agreed, but asserted that covering JCP members was better than nothing. He also noted that the new transparency requirements make it easier to ascertain when your rights might be at risk, and therefore easier to opt out of the obligation to license them. Van Riper stated that Google supports the elimination of these obligations for those who are not involved in a JSR.
Someone else noted that the JSPA obliges EG members to disclose relevant patents. Patrick responded that we have no evidence that people are doing this, and that the PMO certainly maintains no records of any such patent disclosures. Steve Wolfe suggested that members review the recently concluded Broadcom/Qualcomm patent litigation case.
By this point several members expressed frustration and concerns about how we can make progress on this issue. We recognized that we cannot ask lawyers to draft more precise language until we've agreed on what we want them to say.
Patrick noted that we conducted a Doodle poll with very precise language on this particular issue. The question posed was "Section 6 of the JSPA obliges members to license Essential Patents (unless they proactively opt out of doing so) even for JSRs with which they have no involvement. Should we limit this obligation to those who are members of the Expert Group?" Only 12 EC members responded, and almost all of them said that they could not answer without further discussion. An attempt to conduct a straw poll on the same question in this meeting failed. It was suggested that we vote on this question during the next EC meeting. Don Deutsch asked whether we could vote asynchronously, between meetings. Steve responded that experience has shown that the Doodle polls don't focus peoples' attention, and that people are not willing to vote on these matters without exploring alternatives. He volunteered to do so.
Stefano Andreani asked for more details of IBM's proposal - what does "standard terms" mean, for example? He said that all license terms must be clear and understandable.
Patrick agreed to log an issue to track the flat IP proposal (see http://java.net/jira/browse/JSR358-41.) Steve Wolfe promised to create another presentation on outbound licensing, which was not addressed in this proposal.
Patrick then reviewed the content of our java.net project and we briefly reviewed the items from our list of proposed changes and our Issue Tracker. We agreed to drop the Governance issue since no substantive changes have been proposed. On essential patent grants, Steve Wolfe promised to incorporate this item into a future presentation.
Gil Tene made a presentation on Independent Implementations. He noted that language in the JSR 336 TCK license appears to effectively prohibit any independent implementation of the specification. Patrick responded that the language in question seems to have been carried over from other licenses.
We agreed that the main issues Gil raised are:
Patrick agreed to raise these issues with Oracle Legal. In the meantime, an issue has been logged to track this. See http://java.net/jira/browse/JSR358-42.
Werner Keil led a brief discussion of Transplant JSRs. Steve Wolfe provided some background: this proposal originated in JSR 306, and was intended to enable bringing into the JCP work that had been done through external standards bodies. The main concern was how the JCP's and the external specifications could be kept in sync. Typically some kind of "side agreement" would be necessary to enable this. Scott Jameson reiterated what he has stated on other occasions: that HP is opposed to "side agreements." We noted that a fundamental problem is that the JCP ties IP rights to compatibility while other standards bodies don't. As when we've discussed this issue in the past we reached no agreement on whether or not we should pursue it.
Finally we discussed the role of individuals within the JCP, this being the only substantive issue on our list that we had not yet discussed during this meeting. Patrick restated some of the concerns: that individuals may in fact be acting as Agents of their employers, that IP grants made by individuals are narrower than those made by organizations (who are subject to Section 6 of the JSPA) and that the Exhibit B process is complex, error-prone, and potentially ineffective in securing IP.
Someone asked whether an individual could join a second Expert Group without producing a second Exhibit B addressing that JSR. Patrick responded that the PMO does require an additional Exhibit B.
Steve Wolfe asked how other standards bodies handle this problem. He noted that Apache makes no distinction between individuals and corporations, and suggested that Spec Leads have an obligation to be vigilant. Mike DeNicola argued that someone who is employed by a corporation is necessarily an Agent of that corporation and should not be permitted to join as an individual. Van Riper disagreed, pointing out that some corporations encourage their employees to explore their private interests by participating in standards-setting and open-source organizations. Roger Mahler pointed out that such a rule would effectively prohibit employees of non-tech companies from participating in the JCP since those companies, having no direct business interest in Java, would not be willing to join themselves.
Ben Evans suggested that we address the temporal aspect, noting that the JSPA is signed at a particular point in time. The signee should be obliged to inform the PMO if something has changed.
Gil Tene repeated a suggestion he had made previously, and which is recorded in the minutes of the May EC meeting. Quoting those minutes: "Gile 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 is 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."
Steve Wolfe argued that Spec Leads should perform due diligence before accepting IP from an individual member where their IP rights might intersect with their employer's. Mike DeNicola responded that if we adopt IBM's flat IP proposal the Spec Lead would have less incentive to do so. Van Riper argued that assertions about the right to grant IP should be made when that IP is contributed rather than in advance.
Werner Keil pointed to the Open Geospatial Consortium's individual membership role, noting that only those who are genuinely self-employed or contractors are permitted to join. Don Deutsch asked whether we should adopt a similar requirement. Van Riper responded that if we did we would need to reconsider the corporate membership fees. Patrick pointed out that OASIS charges a $300 fee for individual members, and asks them to assert that they have not assigned "their" IP to others. He noted that this would effectively prohibit all US individuals who are employted by tech companies.
Mike DeNicola asked why individuals should get the same voting rights as large corporations. Gil Tene suggested that we review the Apache Individual Contribution agreement. We agreed that Spec Leads need training in IPR issues.
As when we have previously discussed this issue, we reached no conclusions other than to agree that it is important :(
Patrick then thanked Deutsche Telekom for their hospitality and for the exellent logistical support, and the meeting adjourned.
