 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
Executive Committee Meeting Minutes
|
Tuesday January 13 |
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 for this session |
Tuesday January 13 |
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 for this session |
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 was no change in voting status as a result of this meeting, but ARM, Credit Suisse, Gemalto, and Intel will lose their voting privileges if they miss the next meeting.
See the Action Item tracking file.
Heather presented the usual EC Stats.
Heather presented the PMO's year-end report
Greg Luck led a brief discussion on PMO transparency, noting that submissions to the spec-submit mailing list sometimes receive no response for a considerable period of time, making it difficult for spec leads to know where things stand. He suggested that a public issue tracker might be a simple and useful means of tracking and publicizing these submissions. The PMO agreed to discuss this internally and to respond at a future meeting. An AI has been opened to track this.
After a brief discussion EC members endorsed the dates and locations for 2015 EC meetings (see the calendar on jcp.org). Greg Luck reported that Hazelcast could host the London meeting in June.
Doug Locke, Spec Lead for JSR 302, presented a report on the current status of JSR 302: Safety Critical Java Technology. Members expressed great interest in the technical content of this presentation and had many questions, particularly about the process whereby Safety Critical Systems are tested and certified. On the other hand, members expressed concerns about several procedural matters that came to light:
Members also suggested that the JSR should upgrade to JCP 2.9.
During a brief follow-up discussion the next day members discussed whether processes should be put in place to guard against the possibility of another Expert Group running into similar problems (working for years on their JSR while being unaware of basic JCP policies and procedures). Patrick noted that under our existing processes such a problem would be exposed - similarly to the manner in which these problems were exposed - only when the JSR "came back to life" after being dormant, and was subject to a JSR Renewal Ballot. This might well be too late.
Members agreed that it would be helpful to conduct an audit of apparently-inactive JSRs to ascertain whether they are in fact continuing to work; if so, the PMO would contact them and arrange for a review. Ben Evans volunteered to conduct these audits if the PMO provided a list of relevant JSRs. AIs have been opened to track these commitments. Patrick suggested that in addition it would be helpful if JUG members could briefly review active JSRs to determine the extent to which they are meeting the transparency requirements. Ben agreed to also take on this task. An AI has been opened.
Patrick introduced a discussion on JSR 358 (see the presentation for background), suggesting that the EC once again discuss Oracle Legal's suggestion that RIs could be licensed under MIT or BSD so long as all contributors had also signed either the JSPA or the Affiliate Membership Agreement. He asked Don Deutsch to outline Oracle's position as he had done at an earlier meeting.
Don reminded EC members that we have been struggling for a long time to reconcile the standards-setting role of the JCP with the development of RIs at external forges and wondered whether we might be trying to do the impossible. He noted that his role at Oracle is to oversee the company's engagement in more than a hundred different Standards Setting Organizations (SSOs). He reported that while some of these SSOs are working on providing open source capabilities within their own IPR regimen he didn't know of any other SSO that has successfully addressed incorporating independent open source contributions.
The key question, he argued, is how to reconcile two different IPR regimes: the JCP's and the external forge's. He noted that Oracle had made three different proposals, all of which the EC had rejected: a standard Contributor Agreement, the UPL, and MIT or BSD plus an assurance that all contributors to the RI will have signed either the JSPA or the new Affiliate Membership Agreement.
Don suggested that rather than focusing on the particular license that might be applied to RIs we should focus on the heart of the issue: the commitments that contributors make and that are necessary in order to provide the rights implementers need.
He pointed out that the JSPA (and the Affiliate Membership Agreement that will be derived from it) is the IPR policy for the JCP, and that its contents will be defined by the EC through JSR 358. Since the purpose of this policy is to ensure that all those who contribute to JSRs have made the appropriate IP commitments it is not unreasonable to expect that everyone who contributes to a JSR has signed it. This is consistent with EC members' expectations as participants in other SSOs - that everyone who contributes to a standard has made the necessary IP commitments.
Don stated that Oracle's latest MIT/BSD proposal has been characterized by EC members as "MIT or BSD plus an Oracle Contributor Agreement". This is an unfair characterization; rather, it is MIT or BSD plus an assurance that those developing the RI have made the IPR commitments needed by JSR implementers.
He argued that because contributions to the RI can "flow through" to the Specification, simply committing IP to the RI is not sufficient. We need to ensure that the IP is also granted to the Specification - only then will all implementations (including those not derived from the RI) have the necessary rights
From this perspective Don asked whether is it really is unreasonable to ask that all contributors to a JSR (both directly through the JCP and indirectly through an open source RI development process) have made the same IPR commitments by either signing the JSPA or signing a contributor agreement covering the aspects of the JSPA specifically pertaining to contributions.
Don concluded with a request for comments and feedback.
Scott Stark responded that if RIs could be licensed under Apache it would make the Oracle proposal more acceptable. Patrick responded that Apache is a separate issue, and suggested focusing specifically on the MIT/BSD plus JSPA proposal.
Mike Milinkovich made two points:
Patrick responded that it is the EC's responsibility to define the terms in the JSPA. We can permit Apache licensing if we wish (though we cannot guarantee that Apache-licensed code will be accepted into the platform). As for the innovation question this is indeed a concern and we should continue to address the matter.
Geir Magnusson gave JodaTime as an example of pre-existing open-source code that evolved into a JSR.
Patrick agreed that in practice it will be impossible to get everyone who contributed to an open-source project (or to earlier projects that flowed into such a project) to sign the JSPA.
It was pointed out that we will need to convince open-source people to contribute to the JCP since they have no significant incentive to do so.
Mike Milinkovich argued that the legal risk of not having a signed JSPA is miniscule. It is very unlikely that anyone who contributed code under an open source license would successfully sue for patent infringement when IP derived from that code is included in a spec. Patrick responded that lawyers are by nature conservative, and that any risk at all might be considered unacceptable.
Gil Tene noted that the specific patent rights we need (for independent implementations derived from the Spec) are not granted by any of the popular open source licenses.
Mike Milinkovich suggested that we might have two levels of "spec cleanliness": one where all IP is known to be covered by all necessary grants and the other where some IP grants are less comprehensive.
Patrick responded that both of Mike's suggestions (licensing under Apache, and incorporating open-source licensed code from contributors who have not signed the JSPA) can be addressed by permitting the action but recognizing that there would be no guarantee that any JSR developed in such a manner could be incorporated into the platform.
Scott Stark said that RedHat would be willing to support the requirement for signed JSPAs, but separately wants to push for permitting Apache licensing. Gil Tene also expressed his support.
Mike DeNicola pointed out the approach taken by JSR 302 (discussed earlier) was an example of the "wide-open approach". We should not write rules that prohibit them from doing what they have done. Hendrik Hoefer pointed out that although the RI is theoretically separate from the Spec, lawyers believe that it can influence the Spec. Scott Stark pointed out that many open source developers don't know or care about IP or licensing. Scott Jameson said that he couldn't see a fix that is any better than what we have today.
Mike Milinkovich suggested a minimalistic approach: we should make a simple statement in the JSPA and document best practices elsewhere. He also suggested that we ought not to specify a limited number of acceptable licenses, but instead permit the RI to be licensed under any OSI-approved license.
Patrick suggested that we conduct a straw-poll to determine whether EC members agreed or disagreed with Don's statement that requiring a signed JSPA is reasonable, but the group was unable to reach consensus on how such a poll should be phrased. After some discussion, however, Patrick suggested - and nobody disagreed - that a general consensus seemed to be emerging.
He proposed that in this area we should make minimal changes to the JSPA. It should state that the Spec Lead has the responsibility to ensure that they have all the rights necessary not only to implement the RI but also to permit others to create independent implementations (not derived from the RI). In addition to the JSPA changes we should create a non-normative document (or perhaps use the existing Spec Lead Guide) explaining that the best way to ensure you have the necessary rights is to require that everyone who contributes to the work of the EG or to the development of the RI must sign either the JSPA or the Affiliate Membership Agreement. The non-normative document might also explain the terms under which Oracle will accept JSRs into the platform.
During this discussion Patrick had also pointed out that other changes to the JSPA will be needed to ensure that it does not conflict with, inhibit, or even prohibit the practice of open-source development of RIs. (For example, the current JSPA states that IP does not vest until the JSR goes final.)Patrick provided an update on JSR 358 (see the presentation for background). He discussed the contents of the three new membership agreements. Members expressed frustration at not being able to review the actual documents, arguing that by the time they receive them (after Oracle's executive approval cycle) there might be no time to make changes. Patrick agreed to revisit the question of distribution with Oracle Legal. [After the meeting he obtained approval to release the documents for EC review on the understanding that the documents are preliminary and subject to change. EC members now have access to the documents, but these will not be released publicly until after all approvals have been obtained.)
Yara and Vinicius Senger gave an entertaining and informative presentation on Java and the Internet of Things (see the presentation for details). EC members expressed their appreciation.
Maulin Patel reported on the use of Java at Freescale. He stated the goal of enabling Java across the whole IoT space.
He expressed concerns about licensing issues, and about the possibility that licensing fees might inhibit the use of Java within very low-end (and very low-cost) devices. Nevertheless, he argued that Java would bring significant advantages (a uniform development environment, security and communication libraries) to edge devices.
Hendrik Hoefer argued that Java may not be appropriate in edge devices because of the cost of the additional RAM that would be required to support Java. Calinel Pasteanu responded that JavaCard might be a potential solution since an even smaller-footprint version is planned.
Mike Milinkovich asked why Freescale was supporting only COAP since other protocols are also important. Maulin responded that this was the initial choice and that support for other protocols could be added later. Mike then asked why they were supporting both Java and the MBED environment. Maulin explained that they are partnering with ARM, and want to capture the largest possible developer base (MBED has a large developer community).
Leonardo Lima and Werner Keil provided an update on JSR 363: Units of Measurement API (see the presentation for details).
Bruno Souza reported on SouJava's efforts to recruit corporate members in Brazil that began with Patrick Curran's visit for JCP Week (see the presentation for details). He reported that SouJava expects to be able to recruit several Brazilian corporations, but that the process takes time.
Mark Reinhold reported on current plans for Java SE 9, and then provided a detailed update on JSR 376: Java Platform Module System (see the presentation for details). EC members had many questions about the technical details of the module system.
Members asked Mark whether the OpenJDK JEP process is an alternative to the JCP. Mark responded that it is not - all API changes are eventually proposed for inclusion in JSRs. Some members expressed concerns about being presented with a fait accomplis. Mark responded that there is every expectation that changes can be introduced after a JSR has been filed. Mike Milinkovich emphasized that we all agree that prototyping in an open source project is an appropriate and effective development model.
Patrick asked whether the past conflicts between Oracle and the OSGI community have been resolved. Mark said that the feature that enables other module systems such as OSGI to locate and resolve modules seems to be satisfactory to most. He emphasized the goal of interoperation.
Werner Keil asked Mark if removing JEP 198 from Java 9 means that JSON JSRs like 374 would be used instead. Mark responded there are no plans to ship them with Java SE but they may be used with it where appropriate.
Werner also asked Mark whether new (modular) features from SE 9 could be incorporated into Java ME, which uses the traditional JAR format and class loading mechanism. Mark responded that this could be problematic since it hasn't been decided whether the module system should be applied to Java ME.
Mike Milinkovich informed the EC that the Spec license for the module system contains language that prevents "shipping" support for Java SE9 modules before the JSR is completed. This will make it impossible for Eclipse to complete the complex tooling work necessary to support modules until well after Java SE9 ships.
Patrick responded that this language is derived from the JSPA, and is an example of the need to modify the JSPA so that it does not inhibit or prevent the use of open source development processes that was mentioned during the discussion on JSR 358. He said that Oracle is aware of the problem and is working to address it in a modified license.
Patrick thanked Maulin and Freescale for their support and hospitality, and the meeting then adjourned.
