 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
Executive Committee Meeting Minutes
|
| Thursday January 23 |
PMO |
|
Executive Committee |
Total attendance: 22 of 25 voting members |
| Since 75% of the EC's 25 voting members were present, the EC was quorate on this day |
| Friday January 24 |
PMO |
|
Executive Committee |
Total attendance: 21 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):
There are no changes in voting status as a result of this meeting.
See the Action Item tracking file.
Heather presented the usual EC stats. We noted the poor voting turnout for ballots that were held at the end of the year, and discussed the possibility of prohibiting ballots at this time. We reached no decision on this question but continued the discussion later in the day (see below).
Heather presented a report from the PMO covering the following topics:
Heather presented an updated report on PMO efforts to clean up the membership database. Having mostly completed processing corporate members the PMO is now focusing on individual members. They will require individual members to reconfirm their membership each year, and at that time the PMO will ensure that we have up-to-date Exhibit B's for all individual members (taking into account changes of employer). As a result of this process we expect a significant reduction in the number of "active" individual members recorded in our database. (The memberships of individuals who we cannot contact, or who decline to provide updated information, will be cancelled.)
Heather once again reported on the declining numbers of corporate members. At the peak we had about 210 paying corporate members but we are currently down to about 50 and we expect the numbers to decline further to about 30. (The decline is caused by a number of factors including acquisitions, mergers, resignations, and unwillingness to pay the membership fees.)
Mike DeNicola asked whether with only 30 paying members it was worth collecting the money. Don Deutsch answered that Oracle is considering cancelling the fees. He added that there seem to be two reasons why corporations don't join: they don't want to pay the fee, and they don't want to commit IP. He argued that if both of these obstacles are removed there would be no need to permit employed individuals to join as full members since they could instead gain access through their employer's membership.
Heather suggested that we would take up this topic again during tomorrow's discussion on Individual members. She noted that about half of current corporate members are fee-paying, but said that she expects the proportion to drop to 1/3 when the cleanup process is complete.
Mike DeNicola pointed out that most standards organizations are reporting decreased participation. Consultants are starting to say that there is less of a widespread belief in the need for standards. Steve Winkler responded that sometimes the code can be considered the standard. Mike Milinkovich agreed.
Gil Tene noted that real participation is expensive (in staff-time) whether or not there are fees involved. Mike DeNicola stated that if Fujitsu was one of the 30 fee-paying members (it is not) he would consider the situation very unfair.
Patrick noted that membership tends to be driven by active (newly-filed) JSRs. When these numbers decline so does membership. He suggested that we should gather data on participation below the level of Expert Group membership (making a comment, logging a bug, Adopt-a-JSR activities, etc.) He suggested that the JSR Review process template is the place to gather such data, and said he would add a requirement that Spec Leads estimate the number of non-EG members who participate in their JSRs. (The relevant Action Item has been updated accordingly.)
Heather reported that the Process Document specifies in detail when the election nomination process starts and when the election takes place. She suggested that if the nomination process was held a few weeks earlier it might make it easier for the PMO to gather the necessary materials from candidates and to schedule the "meet the candidates" events. She asked whether EC members would have any objections if the PMO adopted a different timetable from that specified in the Process Document.
Gil Tene asked whether we could we implement his suggestion that only those who were members a certain number of weeks or months before the election would be eligible to vote. We noted that the Process Document does not prohibit this.
Scott Jameson suggested that announcing the elections on August 1 may not have much impact since for many in Europe August is a "dead month".
Don Deutsch asked whether there would be any advantage to pushing back the date when new members take office so it coincides with the end-of-year shutdown, thereby overlapping two "dead periods". We noted that this would result in "retiring members" becoming lame-ducks.
Patrick suggested that we could address this by holding the election later in the year. Mike DeNicola noted that we are focusing on timing the elections around JavaOne, yet the dates of JavaOne are not fixed.
During further discussion on the poor turnout for the end-of-year JSR ballots we noted that these were 7-day Maintenance ballots, and suggested that if these ballots were extended to 14 days this might alleviate the problem.
EC members agreed that the PMO should have more flexibility in planning the election time line, and asked Heather to come back to the EC with a proposal.
Patrick logged two issues to track suggestions made during this discussion:
Heather presented the PMO's 2013 year-end report.
We noted that the numbers provided in this presentation are still in flux. Next year's data will look very different once all of the clean-up work is completed. Because of the number of "inactive" members in the database the graph of membership by year is difficult to interpret. Once we get to a clean baseline later this year then true year-to-year changes will be easier to determine. Gil Tene pointed out that since the election participation numbers are expressed as percentages it is difficult to interpret them (once again due to the number of inactive members). Patrick responded that once the database has been cleaned up our "true" participation rate will probably be significantly higher than it is now.
Heather pointed out that about 30 of the corporations who cancelled fell into the category of "financial reasons - chose to join as individuals instead".
Mohammed Taman asked whether people need to become JCP members in order to participate in Adopt-a-JSR. Patrick responded that membership is not necessary for smaller contributions. (The Spec Lead may eventually request a JSPA if there is a substantive IP contribution.) He admitted that this is something of a grey area and pointed out that the new Affiliate membership class will require signing a "JSPA-lite" which is more like a simple contributor agreement - that should clarify matters.
We noted that only one new JSR was started in 2013 and agreed that this is not a good sign. We discussed (as we have done each year for several years now) the fact that almost all of the Spec-Lead work is done by Oracle. We wondered why others are others not investing and asked whether the process favors Oracle, thereby discouraging others from participating.
Gil Tene responded that Azul wants to contribute to OpenJDK but can't get access to the TCK before the JSR is completed even though early drops are made available to commercial licensees. Mike Milinkovich suggested that Gil should take this up with the OpenJDK board.
Kristoffer Gronowski pointed out that there is a significant cost involved in developing the RI and TCK - not many are willing to make that investment. Patrick responded that JSR 358 will mandate open-source development processes for RIs and that many already choose to develop the RI in that way.
We noted that some of the apparent imbalance is a result of consolidation - specifically, Oracle's acquisitions of BEA and Sun, each of whom had led a significant number of JSRs when they were independent companies.
John Pampuch suggested that perhaps people don't think that money can be made from licensing technologies.
Bruno Souza and Jim Gough provided a brief update on the Oracle User Group Summit meeting. Mike DeNicola asked whether the experiment of collocating with that meeting had been successful. Bruno responded that there would not be much benefit unless we actually brought JUG members into the EC meeting. He then located three JUG leaders and brought them in to the meeting:
Bruno Souza, Jim Gough and Mohammed Taman then led a broader discussion on JUG participation in the JCP (see the presentation for details).
Patrick concluded that if we do this again next year we should schedule a full session with the JUG leaders, and ensure that this is inserted into their official schedules.
We then adjourned for the day.
Anatole Tresch, the Spec Lead for JSR 354, joined by phone for a brief discussion of the recent ballot on that JSR.
James Gough reiterated the concerns about conversion, backward-compatibility, and formatting that the LJC had expressed in their comments. He emphasized that this JSR is very important and expressed the hope that the feedback would be taken constructively.
Mike Milinkovich asked whether these problems could be fixed in a future JSR. James agreed that they could, but argued that if people develop their own conversion routines then perhaps they wouldn't adopt newly-standardized APIs. Mike responded that there are no standard routines now, so this JSR doesn't make things worse.
Anatole responded that there are many different use-cases for conversion, making it very difficult to standardize and to create an implementation. (The implementation would need access to a database of conversion values.) The EG wants to focus for now on developing something self-contained - conversion could be added later. As for backward compatibility, he agreed that the spec could eliminate references to SE6, but said that the EG is concerned that people may not adopt SE8 rapidly, and therefore wanted to maintain backward compatibility with SE7 in order to encourage widespread adoption and to get more experience. As for formatting, he said that the later version 0.8 of the spec addresses many concerns, including some formatting APIs. He agreed that the EG could discuss how these could be extended by taking advantage of Java SE8 features.
Don Deutsch and Steve Wolfe raise procedural concerns, asking why the EC is having this discussion since it is not a technical body and the vote has now been completed.
Calinel Pasteanu responded that the EC is not "not technical" and argued that there is value to discussing these issues in the open rather than simply burying them in the comments associated with the ballot results.
Gil Tene asked whether we have a procedural problem, noting that this discussion should have taken place sooner - before the ballot closed. Roger Riggs suggested that there was some confusion over whether EC members were actually reviewing the materials that were formally submitted for ballot or something else.
Patrick suggested that the EC should discuss these procedural matters at another time. He agreed to put this topic on the agenda for a future meeting. An AI has been opened to track this.
Roger Riggs and Stephen Colbourne gave a summary presentation on JSR 310: Date and Time API.
Steve Harris asked how well the collaborative test development process worked. (The presenters had pointed out that their test development process delivered both TCK tests and more general unit tests, with the TCK tests being delivered separately.) Steve asked whether this model could be used more widely.
Roger responded that future maintenance of the TCK will be part of the SE development process. If this was a standalone JSR then widespread availability of tests would be more practical. He said that he likes the idea of making tests available as part of the deliverables.
Stephen responded that if you're writing code you should be writing tests at the same time. He too was glad that the tests are available in the repository. He admitted that the TCK tests may not be as rigorously developed as other parts of the JCK. This JSR ended up in the right place, but their development process shouldn't necessarily be a model for others.
Patrick thanked the London Java Community for their participation, noting that this is the first JSR for which we've had active participation from a JUG. Stephen responded that they probably couldn't have completed this JSR without the LJC's participation.
Steve Harris argued that the way this JSR was developed could serve as a model for others. He said that a collaborative test development process and the widespread availability of tests is a good thing, and pointed out that the process still (correctly) maintained the separateness and "special" nature of the TCK.
Werner Keil asked whether there are any plans for this JSR 310 to be supported on smaller devices. Roger responded that they haven't seen much demand for this, so they haven't seriously considered it. Stephen said that he had always thought of this JSR as being focused on large-scale, server-side applications. A date-time API for smaller devices would be very different. JSR 310 will probably be part of the SE profiles.
Roger concluded by once again thanking the LJC for their participation.
Heather Vancura led a discussion on the work of the Individuals Working Group (see the presentation for details).
Heather summarized recent Working Group activities and the associated Doodle polls. Patrick noted that EC members had voted yes on the proposal for a new Affiliate membership class with limited voting rights and then after the fact said that they thought this was to be an addition to rather than a replacement for the current right of employed individuals to join as full members. He noted that the Working Group had clearly stated on several occasions that this was to be an alternative, since the WG had agreed to follow the OASIS model, where employed individuals are not permitted to join in their own right.
Don Deutsch argued strongly that the situation with regard to individual members is broken. There are no IP commitments from employers, yet employed individuals can out-vote the corporate members. No other standards body permits individual members as we do.
Mike DeNicola argued that we must ensure that genuinely independent individuals have the option to join as full members. If someone is employed, their only options should be to be an Observer, to be an Affiliate, or to participate on behalf of (in association with) their employer (who has signed the JSPA).
Gil Tene responded that had Don expressed two main concerns. With respect to IP rights he agreed with Don that the problem must be fixed. However, he disagreed with Don on voting rights. Many employed individuals will never be able to persuade their employers to sign the JSPA. The majority of the Java community's best developers have day jobs and their employers don't care about Java and the JCP. We should look to IETF for a model. Don responded that there are no corporate memberships in the IETF - everyone is an individual.
Patrick noted that we will have a simple Contributor Agreement that covers individuals. Their employers, however, don't make any IP commitment. He argued that we can separate the two benefits that JCP members have (EG participation and voting) and consider these separately.
Firstly, he proposed that we should allow employed individuals to join as full members, but only if the employer signs the JSPA. (Someone else pointed out that we could create a simpler version of the JSPA that retains the IP commitments but that strips out all of the language concerning the Spec Lead's responsibilities.) EC members agreed with this proposal.
Secondly, Patrick noted that if someone cannot persuade his/her employer to sign the JSPA then they can join as an Affiliate member by signing the simplified membership (contributor) agreement. Affiliate members will not be able to join an Expert Group or be a Spec Lead. The voting rights they would have are still undecided, but the last Doodle poll did show a reasonable consensus for permitting them (and only them) to vote for two designated "Community Seats" on the EC.
The Working Group will continue its discussions by starting from these two positions.
Scott Jameson noted that HP policies would prohibit their employees from signing up as Affiliates. Mike DeNicola responded that we shouldn't expect to get a perfect solution. We should simply try to improve on what we have today.
Patrick noted some additional (related) matters that require further discussion:
1) should employees of corporations that are full members be permitted to join as Affiliates, or even as full members?
2) If an employer signs the JSPA in order to enable its employees to join as full members then why wouldn't that employer be a full member itself, thereby eliminating the need for their employees to join in their own right (since they could simply associate themselves with the employer's membership)?
3) If multiple employees of a corporation join as full members, should they each get a vote or should they share a single vote?
Patrick led a discussion on the work of the IP Working Group (see the presentation for details).
He briefly summarized the situation, noting that the Working Group proposed that Spec Leads should choose one of three open source licenses for the RI: GPL v2, Apache, and Eclipse. However, after legal consultation it became apparent that these licenses are incompatible with each other, and also with the commercial licensing that Oracle uses for the platforms. He then introduced Jim Wright, who had met with the IP Working Group last year, and asked him to present his proposed solution to this problem.
Jim suggested that instead of the three licenses previously proposed we should use a new "universal license" that he had drafted. This license is basically MIT plus patent grants, and Jim expected to have it approved by the Open Source Initiative.
Members asked whether Oracle too would use this new license. Jim responded no - Oracle would continue to use GPL + Classpath Exception for all Oracle-led JSRs.
Steve Wolfe asked what would stop Oracle taking liberally-licensed RI code and using it outside of the Java arena. Jim agreed that this new license would not prevent that, but he pointed out that the same is true of the Eclipse and Apache licenses.
Mike Milinkovich pointed out that while under the current JSPA and the previous proposal all Spec Leads are treated equally the new proposal clearly allocates a special role to Oracle. Patrick reminded Steve Wolfe that in the original IBM proposal for a "flat IP flow" he recognized that code that goes into the platform is "special". Steve responded that he still believed this was OK. He reiterated, however, that he doesn't want people to be able to take IBM contributions and use them in ways that do not benefit the Java community.
Jim reiterated that he can't solve that problem and Gil Tene pointed out the the licenses on our current list wouldn't prohibit that either.
Gil pointed out that we've agreed we want a flat IP flow, so the inbound contribution license really ought to be the same as this new license. Mike Milinkovich said that under the Eclipse CLA that would be the case - the relationship between inbound and outbound IP is symmetrical.
Scott Stark said that this proposal would work for RedHat.
Scott Jameson said that HP is opposed to creating yet another license. Mike Milinkovich responded that he couldn't think of another license that does what we need
Patrick pointed out that Oracle's first proposed solution was to require a contributor agreement from everyone who contributes to an RI project. EC members strongly objected to that, so this proposal for a new license was the best Jim could come up with.
Don Deutsch asked whether this license should be required even for RIs that may never want to be included in the platform.
Gil Tene noted that if this license is mandated for all Java ME JSRs then the standalone (component) Java ME JSRs won't be able to use restrictive licensing as a means of monetization. Patrick noted that this requirement this won't apply to JSRs 360 and 361. He said that we have asked the ME business units to confirm this is OK with them and they said that it was. However, Jim and Patrick agreed that they would ask once more.
Steve Wolfe said that this seems to be a major change and appears to be a non-starter. He said that he didn't think he could convince IBM's management to agree to a license with such a broad patent grant. The patent grant ought to be constrained enough to prevent widespread re-use of contributions outside of the scope of the Java Community.
Jim said that he still needed to do internal reviews within Oracle, but promised to provide the actual text of the license to EC members as soon as possible.
Henrik Stahl gave a presentation on Java and the Internet of Things (IoT). See the presentation for details.
After explaining the background of this emerging industry Henrik explained Oracle's vision for the role of Java in IoT.
Java should be able to target any device of any size in any market. To that end, the divergence that we have seen between Java ME and Java SE must be corrected; the future Java ME must be, to the greatest extent possible, a subset of Java SE. The new revisions of the platform specifications will help to converge the two platforms, and Java SE profiles will also help.
Henrik explained a new concept that will be reduced in Java SE 8 and Java ME 8: Stripped Implementations. An application and the underlying platform runtime can be bundled together and then all extraneous code can be removed (stripped) so that the resulting binary is as small as possible. Changes will be needed to licensing terms and TCK rules to ensure that this process does not fragment the platforms or result in incompatible implementations.
He went on to discuss what the JCP can do to help Java to evolve to meet the needs of this new space. Firstly, Java ME and Java SE must be unified. Oracle expects to build on OSGI as an application container (no need to reinvent the wheel). At the very low end Java may not be the most suitable environment - it is still too big. Instead, we should create standard bindings to protocols that are being defined elsewhere. Then, Oracle intends to create implementations. There will be a low-level API that can be used to write device drivers (no need to write native code). Existing JSRs (BlueTooth, USB, Location) could be updated.
During the discussion that followed the following comments were made:
Werner Keil and Leonardo Lima gave a presentation proposing a new units of measurement JSR. During the brief discussion that followed EC members were generally sympathetic with the caveats that the proposed API should not be too ambitious, and that the lessons of the failed JSR 275 should be taken into consideration.
Patrick thanked Oracle for hosting the meeting and Heather for her administrative assistance. We then adjourned.
