 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
Executive Committee Meeting Minutes
|
PMO |
|
Executive Committee |
Total attendance: 23 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 Ericsson and Geir Magnusson will lose their voting rights if they miss the next meeting.
We reviewed our open AIs via the new JIRA.
Heather presented the usual EC Stats. Since several members did not vote on recent ballots Patrick reminded members that this is their minimal obligation.
Heather Vancura and Harold Ogle reported on the plans to roll out Oracle's Single Sign-on (SSO) process for JCP.org (see the PMO presentation for details). The explained that each EC member would in future need a distinct login in order to access EC-private materials such as ballots, and that the common "EC-member logins" would be abolished, thereby eliminating the need for dual logins. They said that they hoped that the new login process would be rolled out on April 17.
Werner Keil asked whether EC members who already had SSO accounts (created for access to the Oracle Technology Network or in order to attend JavaOne, for example) could be reused. Harold confirmed that they could, and asked members who have an existing SSO account to to share the email address with the PMO, particularly the address is different from the email address members use as their primary JCP contact address.
Heather presented a proposed election schedule for 2015 (see the PMO presentation for details). She noted that extra time had been allocated in between the nomination period and the election, in order to give the PMO additional time to obtain all the necessary materials from the candidates. She also pointed out that the 2015 election will be held later than usual because of the later date of JavaOne and the desire to hold a "Meet the Candidates" session during that event.
Heather presented a brief update on JSR 364 (see the presentation for details). She reported that the Public Review ballot starts "today" and that the Working Group will meet next week to review the modified workflow documents.
Patrick presented an update on JSR 358 (see the presentation for details). He reported that the Working Group had met four times since the last EC meeting, and that it had focussed on fine-tuning the IP-Flow document and on reviewing open Issues. He briefly reviewed the minutes of those meetings.
He then reviewed the open Doodle polls:
He noted that both polls were approximately evenly divided between those in favor of the proposed change and those opposing it, with a significant number of members not having voted. He suggested that in the absence of a good voting turnout and a significant majority in favor of change the default should be to make no change. Members agreed.
Patrick then proceeded to a detailed review of version 13 of the IP-Flow document.
Mike Milinkovich noted that the term "withdrawn" in section 4.1 ("Section 4D of the current JSPA says that IP related to Contributions can be withdrawn if significant changes are made to licensing terms") is probably not correct since if the RI is being developed collaboratively and IP vests immediately then previously-donated contributions will already be "out in the wild". The real question is whether the contributor is willing to relicense on the new terms.
Michael Berg wondered whether the implementation would therefore need to be modified if the license was changed.
Scott Jameson asked whether we want to retain the re-licensing language. Patrick responded that the Working Group thought so, since a change to or from GPL might be considered drastic enough for some participants to cause them to withdraw. Scott Stark agreed. John Weir and Maulin Patel disagreed. Patrick promised to put this matter to a Doodle poll.
We then discussed section 4.2 (Essential Patent grants from EG members with respect to material contributed by others). Patrick wondered whether this obligation should be extended beyond the Expert Group to all participants in the collaborative RI-development project. He asked Mike Milinkovich how Eclipse handles this situation. Mike replied that neither Eclipse nor Apache imposes this obligation. We therefore agreed not to extend the obligation beyond the Expert Group.
Calinel Pasteanu pointed out that an Expert Group member could simply withdraw without disclosing that the reason for doing so was to avoid the obligation to license Essential Patents. We agreed that this is the case today, and there's nothing we can do about it. He also pointed out that individual EG members may not know about all their company's Essential Patents - do we intend to impose an obligation to perform a patent-search? Patrick responded that we would model the new language on current language which makes it clear that only patents personally known to the participants need be disclosed.
Patrick reported that during a private discussion of the document Don Deutsch had suggested that we should indicate which sections of the document propose changes to the current JSPA and which simply state that we want to keep existing provisions.
Patrick agreed to make this and some other minor changes.
Having previosuly given notice on the EC mailing list of his intent to do so, Patrick called for a formal vote on whether the IP-flow document should be submitted to Oracle Legal with a request that they draft a revised version of the JSPA that addresses the requirements it calls out. All members present voted yes except for Software AG who abstained.
We then moved on to a review of open Issues.
Patrick pointed out that Bill Shannon had recently filed a new issue suggestion a light-weight proposal for producing errata. Such a process would be very restrictive of what could be changed. He also noted that the current Process Document language mandates that binary compatibility must not be broken. Members agreed that under these circumstances no further clarification will be needed.
After a brief discussion we agreed that there is nothing today that prevents another standards organization from endorsing or normatively referencing a JSR. We also noted that JSRs can and do implement standards developed elsewhere. However, we agreed that a collaborative development of standards (where the JCP and another standards organization work together) is unlikely to be possible due to differing IPR policies.
We therefore agreed that there is probably not much to do here but to warn (as we suggest in the IP-Flow document) that we should not introduce any language into the JSPA or the Process Document that would make it difficult or impossible for another standards organization to normatively reference a JSR.
Mike Milinkovich reported that Eclipse has a similar process and that they use the term "archiving". Archived projects are no longer current or supported. Patrick asked whether the TCK for an archived JSR should be supplied. Mike suggested yes, noting that no legal agreement lasts forever.
There was general agreement that we should define some kind of archiving process. Just as the PMO regularly reviews potentially dormant JSRs they should also perform regular reviews to ask Spec Leads whether their JSRs should be archived. Any actual change of state should only be performed after several months' public notice.
John Weir asked whether an archived JSR could come back to life. Mike responded that it should always be possible to re-start an archived JSR.
We agreed to keep this topic open and to discuss it further in the Working Group.
