 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
Executive Committee Meeting Minutes
|
| Tuesday May 14 |
PMO |
|
Executive Committee |
Total attendance: 19 of 24 voting members |
| Since 75% of the EC's 24 voting members were present, the EC was quorate for this meeting |
| Wednesday May 15 |
PMO |
|
Executive Committee |
Total attendance: 24 of 24 voting members |
| Since 75% of the EC's 24 voting members were present, the EC was quorate for this meeting |
See the Action Item tracking file.
Don Deutsch presented Oracle's proposals on licensing and open-source. Scott Jameson asked whether there was any more flexibility in Oracle's proposals, or were they "take it or leave it." Don responded that the presentation made clear where Oracle's "red lines" are.
[In the interests of clarity the remainder of this section of the minutes is grouped by topic, referencing specific slide numbers, regardless of when EC members actually made the recorded responses. Some of the responses reported here were actually made later in the day on Tuesday or even during a follow-on session on Wednesday.]
Ed Lynch suggested that it was important to devise an IP-flow statement. Whether this was "flat" or "hub-and-spoke" would determine the form that many of the other proposals would take. IP flow should be as simple as possible. We would probably need to consider the IP-flow and the form of the other documents in an iterative manner. For the record, IBM strongly prefers a flat IP model (contributors should make grants directly to implementers and users rather than IP flowing via the Spec Lead).
Steve Wolfe requested that the presentation be modified to include an explicit statement that Oracle reserves the right to insert FOU restrictions in TCK licenses.
Scott Jameson suggested that the JSPA should be refactored so that all IP-related material is in one place. [Patrick: perhaps even in a separate IPR policy document.]
Gil Tene pointed out that the proposal for a standard Contributor Agreement seemed to imply a hub-and-spoke model. He noted that only one of the two grants listed in the proposal (to the Spec Lead and to Oracle) would actually be necessary, not both.
Scott Jameson suggested that all "side agreements" be prohibited once a standard Contributor Agreement is defined. Mike DeNicola suggested that we define a light-weight process to allow the Contributor Agreement to be modified. Ben Evans noted that the Contributor Agreement could serve as the "JSPA-lite" we have proposed for individual members.
Gil Tene noted that rights are revocable under current agreements and suggested that this would need to be factored into the Contributor Agreement.
Scott Jameson said that since we will not mandate where RI-development projects are hosted we would need to coordinate Contributor Agreements if they were, for example, hosted at Eclipse.
Mike Milinkovich stated that Eclipse will not accept an "asymmetric" Contributor Agreement for use by Eclipse projects that makes special grants to Oracle or to any other organization. He noted that EclipseLink serves as the RI for JSR 317: Java Persistence 2.0 and that this was developed without any kind of Contributor Agreement. (However, the result was jointly licensed under the EPL and the BSD-derived Eclipse Distribution License.) In a later email message he clarified his position, arguing that a single JCP CLA which gives special proprietary rights to the Spec Lead and Oracle will result in:
a) OpenJDK and (possibly) java.net being the only two places where anyone could ever do an RI, and
b) Oracle will be the only spec lead at the JCP.
Calinel Pasteanu noted that the Contributor Agreement might be a "container" that references or defers to a BSD or Eclipse grant.
Steve Wolfe suggested that we should not try to solve this problem ourselves. Rather, we should state the requirements: that we want to permit Open Source development through a variety of hosting environments and that Oracle needs the right to incorporate technologies in the platforms. These two requirements aren't necessarily incompatible. We should specify our goals and ask the lawyers to figure out the details.
Sacha Labourey agreed, but reiterated that we cannot impose new requirements on external organizations such as Apache and Eclipse. Mike Milinkovich repeated that we must enable RI development through a variety of open-source projects and hosting environments. He suggested that the words "open to anyone willing to sign the JSR Contributor Agreement" be deleted from slide 13.
Steve Wolfe asked why it was necessary to grant additional rights (over and above the regular open-source rights) to everyone. Special rights should be granted only to Oracle.
Sacha Labourey and Mike Milinkovich noted that although the "top-level" license for the RI must be one of the approved Open Source Licenses it is quite possible that the RI might include materials that are licensed in another way.
Steve Wolfe suggested that we define a Standard Commercial License for RIs (as we plan to do for TCKs) for the case when this is the only license offered (when Oracle takes the "umbrella JSR exception"). It was also suggested that in the case of TCKs we should note that the Spec Lead should be free to offer additional open-source or commercial licenses without the need to disclose them. (That is, the wording of these two slides should be harmonized as much as possible.)
CloudBees and RedHat argued that providing a Community TCK License to participants in the RI project discriminates against those who wish to create an alternative FOSS implementation (JBoss, for example) since participants in the alternative project would not have TCK access.
Gil Tene pointed out that the summary on this slide of the terms of the OCTLA is inaccurate. The OCTLA does not prohibit claims of compatibility, but simply prohibits comparative compatibility claims.
It was pointed out that this slide should also state that Oracle voluntarily commits to community TCK licensing for the TCKs for the Java SE and Java EE platforms.
Gil Tene suggested, and others agreed, that it might be preferable to codify Oracle's "voluntary commitment" either by incorporating it directly into the JSPA or by some other manner.
While unwilling to take a formal vote, EC members agreed that Oracle's proposals contain enough merit to move forward, and that they should form the basis for future work by the Expert Group for JSR 358.
Members then discussed what our next steps should be.
Gil Tene suggested that we need to decide whether we will continue to discuss contentious issues or just move on. Mike Milinkovich suggested that we need to continue working on these matters rather than waiting for Oracle's lawyers. Patrick asked whether we could move forward on the Essential Patents matter. (Mike Milinkovich agreed to circulate the proposal that he, Steve Wolfe, and Steve Harris had created some time ago.) Steve Wolfe agreed that this might be possible, but pointed out again that we need to resolve the flat/hub-and-spoke issue.
Mike DeNicola suggested that since we seem to have agreement on the need for a standard Spec License we could ask the lawyers to draft this. Scott Jameson cautioned that we shouldn't ask the lawyers to draft anything until we have settled the hub-and-spoke issue. Mike Milinkovich suggested that we might end up with a hub-and-spoke model for the Spec and a flat model for the RI.
Gil Tene suggested that we could ask the lawyers to draft the Community TCK License since this does not seem to be affected by the choice of IPR policy.
We agreed to re-start the IP Working Group, which will initially focus on the hub-and-spoke question and will then move on to discuss the various licensing issues. (An AI has been logged.) We agreed to continue our discussion on Contributor Agreements on Wednesday (focusing the discussion by listing various use-cases) and also to review the Oracle presentation again together with the complete list of issues from our Issue Tracker, in order to generate a list of work-items. In the process we would prioritize these items, and determine the extent to which we have agreement on their implementation.
NOTE: the Spec Leads who presented at this meeting were asked to follow the guidelines laid out in the JSR Review Process presentation as a real-world test of the proposals it contains.
Michael Lagally (joint Spec Lead for JSR 360: CLDC 8) presented an overview of this JSR. See the presentation for details.
Members asked whether there are Java SE 8 language or library features that will not be included in CLDC 8. Michael responded that many features will be left out or classes subsetted in order to meet the footprint requirements (CLDC 8 will be significantly smaller than the lowest Java ME profile.) Gil Tene asked specifically whether concurrency and InvokeDynamic will be omitted. Michael responded yes - developers will have to adjust their programming model.
Someone asked how they decided what to leave in and what to exclude. Michael responded that they had a lot of input from Product Management, but that feedback on the Early Draft will tell whether they made the right choices. Calinel Pasteanu noted that Oracle does have real experience in the M2M market.
Sacha Labourey asked how this platform will compare to the rest of the market. Will it be competitive? Will developers adopt it? Michael said that this would depend on where those developers come from. He emphasized that this platform will be focused on the embedded and M2M markets rather than on mobile phones, and noted that many of the developers in those fields program in C. He expects these developers to find the Java programming environment attractive.
Patrick noted that the JSR Review Process guidelines do not currently incorporate a request for market/competition information. He agreed to add this. (An AI has been logged.)
Patrick commented that the schedule seems aggressive. Michael responded that not much new development was needed, since the JSR will focus on incorporating features that have already been developed in Java SE.
Volker Bauche (Spec Lead for JSR 361: Java ME Embedded Profile) presented an overview of this JSR. See the presentation for details.
Patrick commented that the schedule for this JSR seems even more aggressive than that for JSR 360 (Volker had reported that it started two months later than JSR 360). Volker responded that this JSR also doesn't define any new technologies. Calinel noted that work was going on even before the EG was formally created and emphasized that this JSR will import technologies from existing JSRs. He pointed out that the RIs and TCKs for these technologies already exist. Only the optionality model is new.
Susanne Cech asked how the Expert Group for this JSR collaborates with the EG for JSR 360. Volker explained that Roger Riggs serves on both Expert Groups and acts as a liaison between them (others also serve on both EGs.) The Spec Leads meet regularly.
Patrick briefly reviewed the JSR Review Process presentation. Members agreed that the experiment of asking Spec Leads to use this presentation as a guideline for the structure of their presentations to the EC had worked well. It was suggested that the guidelines should be made available in both presentation and documement formats, and that the information provided by Spec Leads should be published online. Patrick agreed to clean up the presentation, noting that it will require additional work as we flesh out the JSR 358 requirements.
Heather Vancura and Bruno Souza reported on the work of the Working Group on individual members. (See the presentation for details.)
Our discussion first focused on the proposal for a new class of "Affiliate Member." We discussed which individuals might be eligible for full membership and whether individuals who are employed by corporations should be eligible.
Gil Tene asked what an individual would have to assert if joining as an independent contractor. He noted that even contractors have an IP relationship with their employer. It ought to be enough to assert "I am not acting as an agent of any individual or organization."
After considerable discussion we agreed that we should adopt the OASIS model whereby only those who are "self-employed, unemployed, or employed by organizations unable to join OASIS" are permitted to join as individuals. (A separate category of Individual/Associate Membership applies for those who are effectively "agents" of their employer, but only one such agent may be a member at any one time.) We agreed that individual members should have an obligation to inform the PMO when their employment circumstances change.
Ben Evans argued that the OASIS language might not be precise enough. What about individuals who are directors of their own company, for example? Werner Keil noted that the Open Geospatial Consortium (OCG) has restrictions for Individuals similar to OASIS, but treats representatives of Universities, Non-profits or companies differently, which could help flesh out the role of JUGs or other forms of organisations by the WG.
We agreed that it might be necessary to expand on or otherwise clarify the OASIS definitions, but that it would still be preferable to start from something that another standards organization has already implemented than to define our own membership policy from scratch.
Mike DeNicola noted that OASIS charges membership fees for individuals and argued that we should do the same since it is important that people have "skin in the game."
The discussion then moved on to the question of whether - and if so how - to give individual members some voting rights. Mike Milinkovich and Mike DeNicola both argued strongly that members who have not made an IP commitment should not have a vote, and they opposed the suggestion that a special EC seat be created for "Affiliates." Heather pointed out that the Working Group proposed that Affiliate Members should sign a Contributor Agreement, thereby making an IP commitment.
Bruno suggested that giving Affiliate Members the right to vote for ratified seats would be relatively safe, since the candidates for these seats have already been nominated by the PMO. Scott Jameson warned that this would potentially give large organizations multiple votes (if many of their employees joined at this membership level). Ben Evans argued against disenfranchising existing individual members (who do have votes) and supported the suggestion that Affiliate Members be permitted to vote for ratified seats.
Mike DeNicola argued that those who do not contribute should not get a vote.
We raised the question, but did not answer it, of whether Affiliate Members would be permitted to run for election to the Executive Committee.
Sacha Labourey pointed out that very few people (less than 300) actually vote in JCP elections yet there are millions of Java developers. He asked whether we could give them some way to vote. Patrick responded that if we are successful in defining the new Affiliate Membership category we may get several thousand members. Scott Jameson responded that the addition of several thousand members with even minimal voting rights would be very risky.
Ben Evens argued that the London Java Community works very hard to publicize the JCP, and that the bad publicity that would result from disenfranchising individuals would be difficult to counter.
Gil Tene noted that we are the Java Community Process and that we ought not to restrict participation to those who sign a heavy-duty IP agreement.
We concluded that we have not consensus on this issue, and asked the Working Group to continue to discuss the matter and to come back with a proposal. (The WG also needs to consider the role of Java User Groups more closely.)
Susanne Cech gave a presentation on the use of Java within Credit Suisse. EC members found this very informative, and asked many clarifying questions.
Anatole Tresch (Spec Lead for JSR 354: Money and Currency API) presented an overview of this JSR. See the presentation for details. EC members had many questions and provided Anatole with useful feedback. It was suggested that the JSR needed to define a mechanism for dealing with external data-sets (the definitions of different currency-types, for example) that would change over time in the same way that Java SE has had to define mechanisms for dealing with changes to time-zone data.
EC members agreed that because this JSR will define new fundamental data-types it is important that the Expert Group be more broadly formed than it is at the present. Goldman Sachs should be represented on the EG, and Mark Davis agreed that Google would nominate someone. We also agreed that Oracle should be represented since - like the Date and Time JSR - it is likely that this JSR will be incorporated into the platform.
On Wednesday we continued our JSR 358 discussions. We first reviewed the Oracle proposal, the Summary presentation, and the Issue List to generate a Task List. (This document will be updated as we move forward.)
In preparation for further discussion of the Contributor Agreement proposal we identified several use-cases that may be relevant to this and other JSR 358 topics:
We agreed that it must be possible for RI projects to be hosted on non-Oracle environments such as java.net and
OpenJDK (e.g., Eclipse). We recognized that other environments have their own IPR policies or contributor agreements that are vendor-neutral. They cannot/will not accept a CA that assigns license or ownership to any one corporate entity (that is - special privileges for Oracle.)
In discussing the development of the RI for JSR 317: Java Persistence 2.0 as an Eclipse project Gil Tene pointed out that although the Eclipse license grants the necessary rights to the RI it does not grant the patent rights necessary for the Spec. If - as it seems - Oracle consumes this RI under the BSD-derived Eclipse Distribution License then no patent grants are made at all. He argued strongly for a clear IPR policy that ensures that all the necessary IP rights are granted.
Others responded that Oracle already incorporates into the platforms technologies that are licensed "liberally" without requiring an OCA.
A fundamental question is whether the terms of the proposed Approved Open Source Licenses are sufficiently liberal that there would not be a need for a Contributor Agreement. (If they are not, then Oracle could always do an independent implementation.)
We considered the following questions:
We recognized that people might have to sign multiple agreements (for whichever projects/hosting environments they want to participate in.)
Alternatively we might agree that the rights that Eclipse already grants should be sufficient. (Several members argued that there is a very low risk that someone who contributes to an open-source project would later sue.)
We concluded this discussion without reaching any firm conclusions. Patrick promised to report members' concerns to Oracle Legal, and to inform the EC of their response. (An AI has been logged.)
