 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
Executive Committee Meeting Minutes
|
| Tuesday May 13 |
PMO |
|
Executive Committee |
Total attendance: 20 of 25 voting members |
| Since 75% of the EC's 25 voting members were present, the EC was quorate on this day |
| Wednesday May 14 |
PMO |
|
Executive Committee |
Total attendance: 19 of 25 voting members |
| Since 75% of the EC's 25 voting members were present, the EC was quorate on this day |
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):
Since SAP missed both the April and May meetings they have now lost their voting privileges.
See the Action Item tracking file.
Heather presented the usual EC stats.
Heather reminded EC members about the JCP anniversary party scheduled for June 18. An AI was logged for her to add this event to the calendar on JCP.org.
Binod PG gave an overview on JSR 359: SIP Servlet 2.0 (see the presentation for details). During the discussion that followed John Weir asked why the JSR had not been made broader, to cover additional protocols such as XMPP. Binod responded that the Expert Group had thought about this, but decided that since this is a "legacy JSR" they would stick with the original more limited scope.
Nigel Deakin presented an overview of JSR 343: Java Message Service 2.0 (see the presentation for details), focusing on community participation. Patrick commented that the statistics Nigel provided on mailing-list participation were very helpful.
Nigel expressed disappointment at the relative lack of participation from several members of the Expert Group. EC members explained that it is not unusual in the standards-development world for the majority of the work to be done by a minority of the participants.
During a discussion on participation Patrick suggested that the JSR 364 proposal to add a section to JSR pages where Affiliate members could be recognized as Contributors to the JSR could usefully be extended to Full Members. An AI has been opened to track this suggestion.
Nigel pointed out that there is a need to standardize on similar messaging APIs in languages other than Java. After a brief discussion members agreed that it would not be appropriate to attempt such standardization through the JCP - any such standards would have to be developed elsewhere.
Patrick reported (see the PMO presentation) that last month we received a JSR proposal from a JCP member (Jody Sharpe) who requested mentoring in the process of submitting and leading a JSR. The LJC volunteered to talk to him. Jim Gough reported that after reviewing the JSR proposal and talking to the submitter they recommended that rather than proceeding directly to a JSR they create an open-source project and try to build a community of support.
We then reviewed possible process changes to encourage others to ask for help. Patrick suggested that rather than introduce a formal Incubator process we adopt a more informal process whereby on receiving JSR submissions the PMO would - if these seemed to be incomplete or in need of guidance - refer them to the EC for review rather than submitting them directly for a JSR Approval Ballot. During any such EC review EC members would discuss the proposal and would assign a "mentor" to work with the submitter as the LJC had worked with Jody Sharpe. EC members supported this proposal. An AI has been filed to encourage the PMO to adopt this suggestion.
Patrick asked whether now that we have no EC members who must call-in from China or Korea we should change the regular meeting time from 7:00 am to 8:00 or 9:00 am for the convenience of those based in California. Several members pointed out that this would make the meetings less convenient for those based in Europe and after a brief discussion we decided to make no changes.
Heather reported on the activities of the Individuals Working Group (see the presentation for details).
We first discussed the proposed wording on Membership Levels that Patrick composed and posted as a comment to Issue #1: Add a section in the Process Document for Membership.
On the question of standard Terms of Use for all JSR projects Mike Milinkovich suggested that we ought to make an exception for Eclipse projects since they already have their own Terms of Use.
It was suggested that in the section on Partner Members the wording "Individual JUG members must join as Affiliates if they wish to do more than act as Observers" should be clarified since the proposal specifies that Partner Members (in their role as as "organizational members") will have more rights than Observers. Issue #1 has been commented as a reminder.
It was suggested that we need to create a simple table that that we should create a simple table t defining the different membership roles, specifying who qualifies for each, and listing the obligations and benefits that are incurred for each. Even if we don't include this table in the Process Document we could post it on JCP.org as a guide to potential members. A comment has been added to Issue #1 to track this suggestion.
Someone asked how we would track people as they change employers. We decided that we need to define a list of transitions (leave employer, join new employer, etc.) and define the notifications that should accompany these transitions. (Primarily these will be obligations that the member should inform the PMO.) We also decided that we should ask employed individuals to register with their employer's email address to make it easier for the PMO to track changes in their status. An AI has been filed for Patrick to log an issue for this.
Gil Tene suggested that we should not make universities a special case - we should simply ask professors for a "strengthened Exhibit B" just as we will ask other employed individuals who wish to join as full members. Patrick responded that he wasn't sure this would work, but agreed that we should look into it, and that a symmetric relationship would be ideal.
We then discussed the document - again prepared by Patrick - on the "strengthened Exhibit B". This was posted as a comment to Issue #23: Problems when non-member companies encourage their employees to join as individuals.
Scott Jameson warned that even if we those who sign this document to assert that they own the IP that they will contribute many developers will not necessarily understand that implications of what they are signing. Someone else responded that this situation would be no different from the cases in which developers sign contributor agreements for open-source projects.
Gil Tene argued that there should be no difference between the IP commitments made in Exhibit B and those made in the JSPA. Patrick responded that under these circumstances the Exhibit B would seem to be redundant, since the employers could just as easily sign the full JSPA and allow their employees to operate under their membership. Gil responded that Exhibit B would still be simpler than the JSPA (since it wouldn't need to cover the Spec Lead's obligations) and therefore it might be easier to sign. Bruno Souza agreed with Gil.
Scott Jameson suggested that for everyone patent grants should be royalty free (not RAND) for every JSR in which a member participates. Gil Tene agreed. Mike Milinkovich argued that "RAND is obsolete".
We discussed the problem of aligning the new Exhibit B with the expected contents of a revised JSPA which would not be completed until after we expect JSR 364 to close. Several members argued that the task of defining the contents of Exhibit B should be passed to the IP Working Group. They should try to anticipate the direction that will be taken with the new JSPA and incorporate those terms into a new Exhibit B. The default fallback position should be that Exhibit B incorporates the same IP commitments as the existing JSPA. We recognized that whatever terms are incorporated into Exhibit B these will probably need to be modified through a maintenance release of JSR 364 once JSR 358 completes and a new JSPA is introduced.
Patrick then introduced the JSR 358 Expert Group session. Jim Wright joined by phone.
Patrick stated that he had discussed the IP-Flow document with Oracle Legal and management. He explained that while they had expressed no serious concerns about the second half of the document (addressing Essential Patents) they had asked for more information ("what problem are you trying to solve?") about the proposal for a flat IP-flow.
Patrick asked Steve Wolfe, as the original author of the flat-IP proposal, to elaborate. Steve noted that we are concerned about declining membership and decreased diversity of contributors and Spec Leads. He argued that although the hub-and-spoke model was acceptable (and perhaps even advanced) in the 1990s, is not familiar nor desirable to today's developer community, which is more accustomed to a flatter, collaborative environment.
At this point Steve expressed concerns about the presence of Jim Wright - an Oracle lawyer - during a discussion at which other parties' lawyers were not present. In response Patrick suggested that we postpone further discussion on this topic until the next day (when Jim would not be present) and instead move on to discuss Jim's Universal Permissive License proposal. He cautioned Jim to restrict himself to factual rather than legal statements, and not to express opinions.
Jim summarized the current situation with the UPL proposal: the Free Software Foundation had reviewed it and agreed that it is compatible with the GPL; it had also been reviewed and discussed by others, and is pending review and approval by the OSI. Jim said he believed that all questions had been answered to the satisfaction of those who asked them.
Someone asked for a clarification of the context of this proposal - why was the original proposal (for RIs to be licensed under one of three open-source licenses: Apache, GPL, and Eclipse)
dropped? Jim responded that none of the original three licenses is compatible with re-licensing on both commercial and GPL terms. Scott Jameson said the the new proposal was unacceptable to HP because its patent grants are too broad.
Patrick asked the EC whether we there was agreement on the premise that Oracle couldn't take code licensed under any of the three originally-proposed licenses into the platform. He then specifically asked whether members agree that Eclipse-licensed code cannot be redistributed under another license. Mike Milinkovich responded Eclipse-licensed RIs have already been incorporated into the platform. Patrick responded that he know only of the EclipseLink project (which implemented the RI for JSR 338: Java Persistence 2.1) and which was dual-licensed under Eclipse and BSD specifically in order to permit its inclusion into the Java platform. Mike noted that JSR 291: Dynamic Component Support for Java SE was also released under the Eclipse license, but admitted that this was a standalone JSR (never incorporated into the platform).
Mike went on to argue that a monoculture of only one license would be unhealthy, and argued that it must be possible to develop RIs elsewhere than OpenJDK). He pointed out that Apache will never agree to license their projects under any other license and that the UPL proposal therefore excludes the possibility of RIs being developed as Apache projects. He also said that we shouldn't assume that Eclipse will be willing to adopt the UPL - the chance of this is only 50%.
Mike also pointed out that the UPL proposal would also make it impossible to incorporate previously-developed code (code already in existence today, or code derived from that) into the platform since to do so it would be necessary to contact every contributor and to persuade them to agree to dual-license the output under the original license and UPL. Innovation happens outside of the JCP and the UPL licensing proposal cannot be reconciled with that fact.
Mike concluded that if we don't fix these problems Java will become obsolete. He argued that the root cause of the problem we face is Oracle's desire to commercially relicense the source-code for the platform but agreed that he doesn't have a solution.
Steve Wolfe argued that Oracle incorporates Apache-licensed code today. He also suggested that it might be difficult to mix together different UPL-licensed code bases due to differences and potential incompatibilities between differing Larger-works.txt files are mixed
We agreed that we should continue these discussions in IP Working Group meetings when all interested parties can bring their lawyers. Patrick agreed to schedule such meetings.
We then adjourned for the day.
On Wednesday we returned to the flat-IP discussion and tackled it from the perspective of examining different use-cases in order to see how the flat-IP flow proposal would affect them (whether the proposal would simplify things or make them more complicated). We came up with several useful examples:
We agreed that this use-case-driven approach is helpful, and that we should continue the discussion in the IP Working Group.
Finally, Scott addressed a remark that Patrick had made earlier during the discussion - that we have to be careful what proposals we put on the table because of their possible effects on ongoing litigation. Patrick reminded EC members that he and Don Deutsch had raised this question at the very beginning of the JSR 358 discussions, and that they have regularly checked back with Oracle Legal, who have not so far prohibited us from pursuing our discussions. Scott responded that there would be no point in us continuing to work on JSPA changes if at the end of the day we have to put everything on hold for two or more years. Patrick responded that under those circumstances we might need to spin off yet another JSR to focus solely on Process Document changes. He agreed to check again with Oracle Legal.
Patrick concluded that we still have plenty of work to keep us busy:
He promised to start up the IP Working Group meetings again to address these topics.
Patrick presented a report on the PMO's ongoing efforts to clean up our membership database (see the presentation for details). He reported that the latest (and last) phase involves contacting all our individual members to ensure that we have up-to-date Exhibit B's from their employers. He noted that many of the individual members in our database have "lapsed" and are no longer interested in continuing their membership (many of them cannot even be contacted). When the process is completed the PMO expects that the "true" number of individual members will be about four hundred (compared with the approximately 1200 entries in our database). The PMO will then require individual members to renew their membership each year in order to ensure that our records remain accurate and up to date. In response to a query from Werner Keil Patrick confirmed that after the renewal process is completed the online membership list would be updated to reflect the new "clean" state of the database.
Donald Raab gave a detailed presentation on the The GS Collections Framework. See the presentation for details.
In the interests of time this topic was postponed to a future meeting.
Patrick briefly presented the background on this matter (see the PMO presentation for details) and suggested that we ought not to spend a lot of effort trying to solve a problem that is likely to recur only very infrequently. Mike DeNicola had previously suggested that we modify the JSR Deadlines section of the Process Document to specify a maximum amount of time between Proposed Final Draft and Final Approval Ballot and he agreed to file a JSR 358 issue to this effect. (An AI has been filed to track this.)
Patrick suggested that future occurrences of this problem could be avoided if the PMO brought things to the attention of the EC when long-dormant JSRs come back to life, initiating a discussion between the Spec Lead and the EC before any additional materials were submitted for review. He agreed to incorporate this suggestion into the PMO's procedures. (An AI has been filed to track this.)
Mohammed Taman presented a case-study of a system his company has developed for the UN to enable registered refugees in Egypt to obtain cash and food benefits electronically (see the presentation for details). EC members responded with enthusiasm to this interesting use of Java. Mohammed concluded by inviting EC members to participate in the JMaghreb conference in Casablanca later in the year.
Bruno Souza gave a presentation developed by several members of Sou Java that provided an update on the Adopt-a-JSR program in Brazil (see the presentation for details). EC members were impressed by the range of activities and congratulated Bruno and SouJava on the success of the program.
Patrick thanked Goldman Sachs for their hospitality and the meeting adjourned.
