 
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.
See the Action Item tracking file.
Heather presented the usual EC Stats.
Patrick provided a brief update on the annual EC elections [now concluded] and reminded members to vote.
Patrick asked members for their feedback on JavaOne. Gil Tene commented on the good turnout at the Meet the Candidates session, and congratulated Heather on organizing yet another successful party. Steve Harris commented that it had been a very good conference with lots of energy.
Patrick provided an update on the new membership agreements being drawn up by Oracle Legal (see the presentation for details). He reported that good progress is now being made on the Partner Membership Agreement.
Patrick summarized the current state of discussions around RI licensing (see the presentation for details). He noted that during each of the previous discussions EC members had tended to focus on the question of whether or not Apache-licensed code could/should be incorporated into the platform rather than on Oracle's proposal that MIT and BSD-licensed code would also be acceptable so long as the Spec Lead could provide assurance that all contributors had signed the JSPA (or the new Affiliate Membership Agreement). He proposed a discussion on this specific topic, to be led by Don Deutsch, with the "Apache license question" being off-topic. (He promised that we will return to that topic in a later meeting.)
Don started by noting that we have been trying for a long time now to reconcile the standards-setting role of the JCP with the development of RIs at external forges. Noting that the JCP and the external forge each have their own IPR policies he wondered whether these goals might be irreconcilable (he said that he didn't know of any other standards-setting organization that has solved this problem).
He pointed out that Oracle has made three different proposals to solve this problem and all have been rejected by the EC:
Don suggested that rather than focusing on the particular license that might be applied to RIs, we should instead focus on the most important matter: the commitments that contributors make, and how code contributions flow into the spec. He asked how independent implementors get the rights they need?
He noted that EC members had characterized the MIT/BSD proposal as "MIT or BSD plus an Oracle Contributor Agreement" and argued that this is an unreasonable position. The JSPA is not an "Oracle Contributor Agreement" - it's the IPR policy document for the JCP and its contents will be defined by the EC through JSR 358.
He pointed out that the purpose of this document is to ensure that all those who contribute to JSRs have made the appropriate IP commitments and that it is not unreasonable to expect that everyone who contributes to a JSR has signed it.
Before opening up the discussion Patrick noted that the first proposal (a standard contributor agreement) ought not to have been necessary since the JSPA is that agreement.
Steve Harris suggested that if Oracle studied the Eclipse IPR policy they would find it acceptable. He suggested that we allow for an exception policy for external forges that have been reviewed by Oracle Legal and approved by the EC. Eclipse would probably qualify, as would Apache (though they might not be willing to particiate).
Gil Tene agreed that what we do is fundamentally different from what most open-source organizations do, since we develop standards and enable independent implementations. While the RI might be released under an open-source license the spec is different. Going back to first principles we should consider what we want to change about the JSPA. We want to simplify it, and to "flatten" the IP flow. Licensing isn't the fundamental question.
Steve Wolfe noted that the original intent was to create an environment that is more familiar and acceptable to the new generation of programmers but now we seem to be focusing much more on IP policy. We must keep our community vital and engaged. The more constrained we are the less attractive the JCP will be to these developers.
Mike DeNicola agreed that we are getting bogged-down in licensing discussions. RI licensing should be secondary to licensing the IP in the Spec.
Bruno Souza argued that it is important to increase participation rates. The way the Spec is licensed should permit wide participation in implementations. He added that he is sympathetic to a standard inbound IPR policy.
Patrick responded that all are free to implement JCP specifications. Bruno responded by raising the Apache/Field of Use issue.
Scott Stark added that RIs are already being incorporated into the platform.
Patrick noted that a significant cause of the problems we're dealing with result from changes in the way development is done. We have evolved from a "waterfall model" where the spec is written first and the implementation is created later to an iterative model in which spec and implementation are done simultaneously, with each influencing the other. The JSPA will need to be modified to take this development model into account. In working on JSR 358 we should ensure that the JSPA (and the Affiliate Membership Agreement derived from it) makes all the IP commitments necessary to enable the development of RIs through open-source projects.
While we reached no conclusions we agreed that this discussion was helpful, and planned to continue it in future meetings.
