Since 75% of the ME EC's 11 voting members were present,
that EC was quorate for this meeting
Since 75% of the SE/EE EC's 16 voting members were present, that EC was
quorate for this meeting

Attendance: Wednesday September 12

PMO

Patrick Curran

ME EC

SE/EE EC

Stefano Andreani – present

Aplix – Lakshmi Dontamsetti – present

ARM – Paul Manfrini – present

AT&T –not present(NON-VOTING
MEMBER)

Deutsche Telekom – Radomír Věncek –
present

IBM – Peter Whitehead – present

Werner Keil – present

Nokia –not present

Oracle – Calinel Pasteanu– present

RIM – not present (NON-VOTING
MEMBER)

Siemens – Marquart Franz–
present

TOTVS – David Britto– present

Vodafone –not present

Total attendance: 9 of 11 voting members

Azul Systems – Gil Tene – present

Credit Suisse – Susanne Cech Previtali – present

Victor Grazi attended by phone for Credit Suisse

Eclipse – Mike Milinkovich – present

Ericsson – excused

Fujitsu – Mike DeNicola – present

Goldman Sachs – Scot Baldry – present

Google – Van Riper – present

HP – Scott Jameson – present

IBM – Peter Whitehead – present

Steve Wolfe and Ed Lynch attended by phone for IBM

Intel – Anil Kumar – by phone

London Java Community – Ben Evans – present

Oracle – Don Deutsch – present

RedHat – David Bosschaert – present

SAP – Jutta Bindewald – present

SouJava – excused

Twitter – Chris Aniszczyk – present

Total attendance: 13 of 16 voting members

Since 75% of the ME EC's 11 voting members were present,
that EC was quorate for this meeting
Since 75% of the SE/EE EC's 16 voting members were present, that EC was
quorate for this meeting

Minutes

Changes in status as a result of non-attendance at this meeting

The EC Standing Rules
state the following penalties for non-attendance at EC meetings (note those
who participate in face-to-face meetings by phone are officially counted as
absent):

Missing two meetings in a row results in a loss of voting privileges until
two consecutive meetings have been attended.

Missing five meetings in a row, or missing two-thirds of the meetings in
any consecutive 12-month period results in loss of the EC seat.

There were no status changes following this meeting, but both AT&T and
RIM were warned that if they do not attend the October meeting they will lose
their seats (AT&T because they would have missed two thirds of the meetings
since the Standing Rules went into effect, and RIM because they would have missed
five meetings in a row.)

Note: Ericsson and SouJava were excused from attendance due to unexpected family
illnesses.

Logistics for the JSR 358 Expert Group session

Steve Wolfe from IBM had asked the EC to consider the "attendance rules"
for the JSR 358 Expert Group portion of this meeting. He argued that the EC
Standing Rules, which do not guarantee real-time two-way communications to those
who attend by phone, should not apply to the portions of the EC meeting when
the EC is in session as the Expert Group for JSR 358. Patrick agreed to raise
this for discussion at the beginning of this meeting.

After a very brief discussion members agreed with Steve's position, and promised
to open up the phone line for full two-way communication during the JSR 358
portion of the meeting.

Personnel changes

Patrick reported EC personnel changes (see the PMO
presentation for details.) Scott Jameson asked why CableLabs resigned their
seat. Patrick explained that the recent announcements of direction for Java
ME, coupled with the decision to postpone modularity from Java SE 8 to Java
SE 9, left them with no viable future path to evolve their CDC-based software.
Consequently they felt they could not justify their continued participation
in the EC. (For background on this matter see the see the minutes
of a discussion on a presentation given by Jon Courtney (The other Java
ME) at the EC's face-to-face meeting in Korea in May 2011.)

Don Deutsch asked whether those who are in jeopardy of losing their seats due
to non-attendance receive a private warning from the PMO. Patrick responded
that they did. Don suggested that it would be helpful to add such information
to the meeting minutes in the section following the roll-call. Patrick agreed
to do so, and has implemented this suggestion in these minutes (see above.)

EC stats

Patrick presented the usual EC stats
and (as usual) reminded EC members of their obligation to vote in JSR ballots.

Membership update

Patrick presented the first of several PMO reports, on the PMO's activities
to update the membership lists and to collect fees (see the PMO
report.)

He reported that although we are seeing a steady flow of new membership applications,
including some from corporations, because our membership lists have not been
"cleaned" in several years due to the transition from Sun to Oracle
and the fact that membership fees were waived during the first year after that,
the number of paying corporate members would be significantly reduced.

The reasons for this were several: many corporations who had previously paid
fees are now entitled to free membership as Java licensees. Others were unwilling
or unable to pay the yearly $5000 fee, or had ceased to exist as independent
companies due to mergers, acquisitions, or bankruptcies. Still others had joined
in order to participate in a particular JSR that was now complete, and therefore
had no further interest in participating.

Discussion focussed primarily on the difficulty of collecting fees, and on
the relatively small amount that fees bring in (less than $200K/year) relative
to the cost of running the PMO. Several members suggested that the fees be reduced
eliminated if they are inhibiting participation. (Patrick noted that in the
context of the JSR 358 work we have plans to introduce a new lower fee for small
companies.)

Gil Tene asked what benefits accrue to corporate members. Patrick responded
that recent transparency initiatives have blurred the difference between non-members
and members (since non-members can now observe the work of Expert Groups and
can even participate in an informal manner) but pointed out that membership
is still required to join an Expert Group. Don Deutsch noted that this is no
different from other standards organizations that adopt a "pay to play"
model. Scott Jameson argued that there is value in requiring fees - those who
have some "skin in the game" tend to participate more.

Gil Tene argued that it seemed unfair that only 20% of the corporate members
pay fees (the other 80% being entitled to free membership because they license
Java from Oracle.) Patrick responded that in this role they do pay substantial
sums to Oracle, and that it would be difficult and unreasonable to have them
pay more.

Don Deutsch argued that cost of running the PMO and the matter of fees is really
Oracle's problem, and need not be discussed by the EC. He was more concerned
about the cases in which corporations encourage their employees to join the
JCP as individuals in order to avoid paying fees, noting that in this way their
IP commitments are reduced. (Individuals do not make "blanket" commitments
of essential patents for all JSRs as do corporations.) Gile Tene and others
agreed that this problem needs to be fixed. (The matter was taken up again during
the JSR 358 discussions on the following day.)

In further discussion someone asked whether the list
of JUG members on jcp.org is up to date. Patrick promised to find out. (It
is, and currently lists 32 JUG members.) He also agreed to find out how many
corporate members resigned or changed status for each of the various reasons
given in the report.

Patrick then reported that the next stages of the operation would be to review
all of the licensee members (ensuring that we have up to date contact information)
and then to clean up the individual membership list. (He has reported several
times in the past that since we do not charge individuals there are many people
still listed as members who have effectively "lapsed.") The cleanup
plan will involve cancelling the memberships of those individuals we cannot
contact, and requiring all individual members to reconfirm each year through
a web-form that they wish to continue as members. The results will be a significantly
smaller but much higher-quality membership list.

JavaOne plans

Patrick reported the PMO's plans for JCP events at JavaOne (see the PMO
report.) Van Riper pointed out that the public EC meeting clashes with community
events on the Sunday, and that this would be a problem. Gil Tene said that in
general Sunday was not the best choice for this event since many people do not
attend on that day. Patrick agreed that this might be a problem (as indeed it
was - very few people attended the public EC meeting) and promised to try to
find a better time-slot next year.

JCP 2.8 scorecard

Patrick reported the status of JSRs' adoption of JCP 2.8. He noted that the
majority of in-flight JSRs have voluntarily upgraded to 2.8, and encouraged
all members to pressure the others to do so. Gil Tene asked the PMO to let EC
members know if any Spec Leads are resisting migration, and if so what their
reasons were. Patrick promised to do so. For full details and statistics see
the PMO report.

Patrick noted that we need help in tracking whether EGs that have agreed to
operate under 2.8 are actually operating transparently. He encouraged the community
to help with this.

Mike DeNicola suggested that in future JSRs that are not operating under 2.8
should be ineligible for the annual awards.

JavaOne overview

Patrick then inserted into the record a presentation
giving an overview of Oracle's plans for JavaOne.

The Open Geospatial Consortium

Werner Keil gave a presentation on the work of the
Open Geospatial Consortium. Don Deutsch asked Werner what he was asking of the
JCP since Werner had labeled his presentation Collaboration with the Open
Geospatial Consortium. Don noted that the work of the Consortium is wide-ranging,
and that they are collaborating with a large number of standards organizations.
He asked who might drive such collaboration with the JCP. Werner responded that
several of the participants in the OGC are interested in Java, and that maybe
they would do so. Calinel Pasteanu asked how OGC and JCP specs might overlap.
Mike Milinkovich responded that in the future there might well be JCP specs
in these areas. He suggested that if so the JCP should reference OGC specs rather
than reinvent the wheel.

Inactive JSRs

Patrick provided an update on the Inactive JSR situation. He noted that the
PMO has made excellent progress and that the number of JSRs labeled Inactive
has been reduced from 50 to 2. For details and statistics see the presentation.

Gil Tene asked whether we have problems with JSRs "in limbo." Patrick
responded that there are problems in these cases. If the work of an Expert Group
becomes stalled it is not usually feasible for someone else to take on the work
since it's unclear who owns the IP that has already been contributed. This is
something that should be addressed in JSR 358.

Java SE8 community involvement

Ben Evans provided a verbal update (no presentation) on the Adopt-a-JSR and
Adopt-OpenJDK programs. He noted that these were originally conceived as two
separate programs, but to the average Java developer who "just wants to
contribute to Java" there is no difference. The LJC is working to figure
out how the programs should be adjusted accordingly.

He reported that some JSRs (for example, JMS 2.0) have very little community
coverage. This is unfortunate, but since people are volunteering they will do
so in the areas that interest them, and we cannot force them to participate
in something that they do not find compelling.

Patrick asked whether any volunteers were doing non-technical work. Ben responded
that they were not - Java developers want to do technical work. He suggested
talking to Bruno Souza from SouJava and Sonya Barry (from java.net) about the
possibility of automating the process of tracking activity on public mailing
lists and issue trackers.

Ben reported that several "hack days" have been held in London, and
that these have been extremely successful, each with as many participants as
they can handle (since they need instructors.) About 50 developers have attended
each event.

Some JSRs (310, Identity) have had much more focussed participation with a
small number of developers helping out.

How the EC reviews JSRs

Gil Tene led a discussion on the topic (previously unscheduled in the agenda)
of how the EC reviews JSRs. He expressed concern about the difficulty of reviewing
the TCK, and suggested that Expert Groups should make a presentation to the
EC before the Final Approval Ballot in order to explain and justify that their
work is complete. He said he would be particularly interested in a presentation
from the developers of the JCK (the TCK for Java SE) since this is probably
the most significant and thorough of all TCKs. Patrick suggested that the state
of the Issue Tracker should also be reviewed.

Mike Milinkovich pointed out that at Eclipse they do a Release Review
for each project before it completes. (There is a template for this process.)
The review does not necessarily take the form of a meeting but is rather exception-based,
and a meeting will be called if there are significant concerns. An imporant
part of the Review is the presentation of an IP log.

Lakshmi Dontamsetti pointed out that our current processes already require
Expert Groups to provide a TCK Coverage Document summarizing the quality of
the TCK. Patrick noted that even the Oracle TCK teams now tend to produce these
by rote, using boilerplate language. He asked (as did Don Deutsch) which EC
members do detailed reviews of TCKs before voting in Final Approval Ballots.
Not many admitted to doing so. Calinel Pasteanu pointed out that those EC members
who intend to license a JSR will do a deep review, since their business will
depend on the quality of the JSR's artifacts.

Gil Tene repeated that he wants reassurance that a JSR is of high quality -
he does not simply want to "rubber-stamp" it.

Marquart Franz asked whether we really have a problem here, and noted that
improving the quality of the RI and TCK is very expensive. Don Deutsch suggested
that the whole process might be "self-auditing" and that any TCK problems
would surface through the test appeals process once the TCK was actually put
into use. Jutta Bindewald asked whether we should record who performed "deep
reviews." Don Deutsch, pointing out that Oracle is the Spec Lead for the
majority of JSRs, asked whether members trusted Oracle to do a good job. Scott
Jameson suggested that any review should be performed "offline" since
he would need to involve various technical people from HP.

Since several members seemed to feel that additional scrutiny might be unnecessary
and simply impose more process overhead, Patrick suggested that Mike Milinkovich
prepare a presentation on Eclipse's Release Review process for a future EC meeting,
and that we continue the discussion after that. Mike agreed to do so.

Spec Lead presentation - JSR 344: JavaServer Faces 2.2

Ed Burns gave a presentation on JSR 344:
JavaServer Faces 2.2. He was asked how many members of the Expert Group
are active. He responded: about 12. Ed also reported that there is a large community
of non-EG members who participate more casually. Patrick asked him how the requirements
of JSR 348 (JCP 2.8) are impacting his work, and whether we missed anything.
He responded that there were no problems, and that it was simple to "migrate"
to 2.8 since he was already meeting its transparency requirements.

Since JSF has gone through several revisions Ed was asked whether the same
EG members participated from release to release. He responded that there has
been lots of continuity, and noted that a "train model" for releases
was a good thing. He noted that because the work is carried out transparently
non-EG members have also made significant contributions. When asked how he manages
contributions from non-EG members he said that he requires that significant
contributions be made under the Oracle Contributor Agreement (OCA) but that
for more casual contributions he relies on the java.net Terms of Use.

Spec Lead presentation - JSR 353: Java API for JSON Processing

Jitendra Kotamraju gave a presentation on JSR
353: Java API for JSON Processing. Patrick asked whether he had received
feedback from non-EG members. He responded that he had received a little. Ben
Evans asked whether the Chennai Java User Group had made any contributions through
the Adopt-a-JSR program. Jita said that they had not done much. Ben promised
to follow up. Gile Tene asked how the TCK was progressing. Jita said it was
coming along fine.

We then adjourned for the day. On Wednesday we re-assembled as the JSR 358
Expert Group.

JSR 358 Expert Group session

Steve Wolfe presented a proposal
for "flattening" the IP flow as an alternative to the current
hub and spoke model whereby IP vests in the Spec Lead who in turn licenses
it to implementors. He noted that having IP vest in (flow through) the Spec
Lead, and permitting the Spec Lead to choose the licensing terms was introduced
in the early days of the JCP as an incentive to encourage organizations to take
on the Spec Lead role.

Mike DeNicola asked when IP grants would "vest" - when made, or when
a JSR went final. Steve answered "when made."

Noting that the proposal mentions special IP rights for Oracle to permit it
to fulfil its obligations under the TLDA (Technology License and Distribution
Agreement,) Patrick noted that Oracle gets no special rights now. Gil Tene asked
why this is necessary. Steve responded because Oracle is Spec Lead for the platforms.
Gil asked whether this proposal would grant rights to Oracle that they do not
have today. Mike Milinkovich pointed out that if special rights are granted
to Oracle then this proposal could not be considered "flat" - there
is still a "hub." Gil Tene noted that the proposal would decrease
transparency, since it would be necessary to decode all existing TLDAs in order
to understand what rights were being granted. David Bosschaert suggested that
all future TLDAs might also need to be considered.

Calinel asked whether licensees would need to negotiate agreements with each
contributor to a JSR. Steve responded "no" - the grants would be automatic.
Calinel asked "what about litigation situations?" Wouldn't these require
dealing with all contributors - knowing who contributed what? David suggested
that IP could be vested into a not-for-profit organization. Gil Tene responded
that this would still be a "hub" albeit no longer Oracle. Steve responded
that different kinds of IP are treated differently. Patent rights would flow
directly to end-users. Mike Milinkovich noted that this is how Eclipse works
today except for the special grants to Oracle.

Mike DeNicola pointed out that the real issue is not Oracle's TLDA obligations,
but rather that the "special grant" is needed for inclusion in the
platforms. Steve Wolfe noted that the problem is caused by existing TLDAs and
stated that we cannot introduce changes that would require these to be renegotiated.

Mike Milinkovich stated that if IP does not vest in a single owner then we
would need to standardize all Spec, RI, and TCK licenses. Steve Wolfe disagreed.
Mike said that sections 3 and 4 of the Eclipse Public License provide an example
of how this kind of proposal might be implemented.

Mike DeNicola insisted that the TLDA should not be referenced. Steve Wolfe
agreed that it would be preferable to say "you give the following supplementary
rights to Oracle to permit inclusion in the platform..." He noted that
the complexities of the IP regime and licensing models inhibit people from joining
the JCP.

Gil Tene suggested that broad essential patent grants (such as are defined
in Section 6 of the current JSPA) on Royalty Free terms would not be acceptable
to members. If such broad grants are made, they would need to be on RAND terms.

Scott Jameson pointed out that EC members need to know whether this proposal
might be acceptable to Oracle. Don Deutsch promised to provide a response at
the October EC meeting.

Anish Karmarkar asked why it is necessary to call out end-users at all, , since
they would be covered by the 'exhaustion doctrine'. Steve Wolfe responded that
he wanted to ensure that everyone in the value-chain is included. Mike Milinkovich
noted that there is (and would still be) a separate license spelling out end-user
rights.

David Bosschaert then presented Red Hat's
position on IP flow. Patrick noted that the proposal made no mention of
essential patent grants by "non contributors" (as currently defined
in Section 6 of the JSPA.) Don Deutsch noted that the requirements called out
in the first two bullets on the slide are already implemented today. David responded
that the third bullet is an endorsement of a flat rather than a hub-and-spoke
model. Gil Tene noted that the proposal only addresses the Spec license, and
ignores the RI and TCK, which must also be considered. Members agreed that the
Red Hat proposal does not add anything significant to the more detailed proposal
by IBM.

Ben Evans reported the London Java Community's position verbally (no presentation.)
He stated that the LJC agrees with Red Hat's position, but is concerned about
the broad patent grants in Section 6, which he feels might discourage people
from participating. The requirement to opt-out might be a discouragement now
that full transparency is required, since the simple act of identifying patents
might be considered a problem. He asked whether this section might be eliminated.
Gil Tene responded that doing so would eliminate rights that have been granted
up to now. Steve Wolfe asked Ben to clarify what he meant by elimination. Ben
responded that he meant only to eliminate the obligations incurred by those
who do not participate in JSRs.

David Bosschaert asked why the grants in Section 6 are so broad. Steve responded
that at the time the current version of the JSPA was drawn up there was very
little Java adoption, and that they wanted to create an environment with the
least possible uncertainty about IP rights. David asked whether it would be
risky to remove this now. Steve responded that this would introduce additional
uncertainty. David responded that non-JCP members might also have relevant patent
rights and that this issue cannot be addressed by language in the JSPA. Steve
agreed, but asserted that covering JCP members was better than nothing. He also
noted that the new transparency requirements make it easier to ascertain when
your rights might be at risk, and therefore easier to opt out of the obligation
to license them. Van Riper stated that Google supports the elimination of these
obligations for those who are not involved in a JSR.

Someone else noted that the JSPA obliges EG members to disclose relevant patents.
Patrick responded that we have no evidence that people are doing this, and that
the PMO certainly maintains no records of any such patent disclosures. Steve
Wolfe suggested that members review the recently concluded Broadcom/Qualcomm
patent litigation case.

By this point several members expressed frustration and concerns about how
we can make progress on this issue. We recognized that we cannot ask lawyers
to draft more precise language until we've agreed on what we want them to say.

Patrick noted that we conducted a Doodle poll with very precise language on
this particular issue. The question posed was "Section 6 of the JSPA obliges
members to license Essential Patents (unless they proactively opt out of doing
so) even for JSRs with which they have no involvement. Should we limit this
obligation to those who are members of the Expert Group?" Only 12 EC members
responded, and almost all of them said that they could not answer without further
discussion. An attempt to conduct a straw poll on the same question in this
meeting failed. It was suggested that we vote on this question during the next
EC meeting. Don Deutsch asked whether we could vote asynchronously, between
meetings. Steve responded that experience has shown that the Doodle polls don't
focus peoples' attention, and that people are not willing to vote on these matters
without exploring alternatives. He volunteered to do so.

Stefano Andreani asked for more details of IBM's proposal - what does "standard
terms" mean, for example? He said that all license terms must be clear
and understandable.

Patrick agreed to log an issue to track the flat IP proposal (see http://java.net/jira/browse/JSR358-41.)
Steve Wolfe promised to create another presentation on outbound licensing, which
was not addressed in this proposal.

Patrick then reviewed the content of our java.net
project and we briefly reviewed the items from our list
of proposed changes and our Issue
Tracker. We agreed to drop the Governance issue since no substantive
changes have been proposed. On essential patent grants, Steve Wolfe promised
to incorporate this item into a future presentation.

Gil Tene made a presentation on Independent
Implementations. He noted that language in the JSR 336 TCK license appears
to effectively prohibit any independent implementation of the specification.
Patrick responded that the language in question seems to have been carried over
from other licenses.

We agreed that the main issues Gil raised are:

The Added Value requirement

The requirement that disclosed licenses must be consistent with the JSPA

Werner Keil led a brief discussion of Transplant JSRs. Steve Wolfe
provided some background: this proposal originated in JSR 306, and was intended
to enable bringing into the JCP work that had been done through external standards
bodies. The main concern was how the JCP's and the external specifications could
be kept in sync. Typically some kind of "side agreement" would be
necessary to enable this. Scott Jameson reiterated what he has stated on other
occasions: that HP is opposed to "side agreements." We noted that
a fundamental problem is that the JCP ties IP rights to compatibility while
other standards bodies don't. As when we've discussed this issue in the past
we reached no agreement on whether or not we should pursue it.

Finally we discussed the role of individuals within the JCP, this being the
only substantive issue on our list that we had not yet discussed during this
meeting. Patrick restated some of the concerns: that individuals may in fact
be acting as Agents of their employers, that IP grants made by individuals
are narrower than those made by organizations (who are subject to Section 6
of the JSPA) and that the Exhibit B process is complex, error-prone, and potentially
ineffective in securing IP.

Someone asked whether an individual could join a second Expert Group without
producing a second Exhibit B addressing that JSR. Patrick responded that the
PMO does require an additional Exhibit B.

Steve Wolfe asked how other standards bodies handle this problem. He noted
that Apache makes no distinction between individuals and corporations, and suggested
that Spec Leads have an obligation to be vigilant. Mike DeNicola argued that
someone who is employed by a corporation is necessarily an Agent of
that corporation and should not be permitted to join as an individual. Van Riper
disagreed, pointing out that some corporations encourage their employees to
explore their private interests by participating in standards-setting and open-source
organizations. Roger Mahler pointed out that such a rule would effectively prohibit
employees of non-tech companies from participating in the JCP since those companies,
having no direct business interest in Java, would not be willing to join themselves.

Ben Evans suggested that we address the temporal aspect, noting that
the JSPA is signed at a particular point in time. The signee should be obliged
to inform the PMO if something has changed.

Gil Tene repeated a suggestion he had made previously, and which is recorded
in the minutes of the May EC meeting. Quoting those minutes: "Gile Tene
argued that individuals should not be treated separately from organizations.
He noted that individuals and corporations are independent legal entities, and
that individuals have many legal relationships with other entities (many corporations
and other individuals). An employment relationship is just a legal relationship
between two such entities. We cannot hope to control individuals by requiring
some agreement terms with all current, past and future employers, any more than
we could hope to require corporations to get the approval of all current, past,
and future business partners. He therefore suggested that Exhibit B be dropped,
and that instead we require that the signee of the JSPA assert that they have
the legal right to make appropriate IP grants."

Steve Wolfe argued that Spec Leads should perform due diligence before accepting
IP from an individual member where their IP rights might intersect with their
employer's. Mike DeNicola responded that if we adopt IBM's flat IP proposal
the Spec Lead would have less incentive to do so. Van Riper argued that assertions
about the right to grant IP should be made when that IP is contributed rather
than in advance.

Werner Keil pointed to the Open Geospatial Consortium's individual membership
role, noting that only those who are genuinely self-employed or contractors
are permitted to join. Don Deutsch asked whether we should adopt a similar requirement.
Van Riper responded that if we did we would need to reconsider the corporate
membership fees. Patrick pointed out that OASIS charges a $300 fee for individual
members, and asks them to assert that they have not assigned "their"
IP to others. He noted that this would effectively prohibit all US individuals
who are employted by tech companies.

Mike DeNicola asked why individuals should get the same voting rights as large
corporations. Gil Tene suggested that we review the Apache Individual Contribution
agreement. We agreed that Spec Leads need training in IPR issues.

As when we have previously discussed this issue, we reached no conclusions
other than to agree that it is important :(

Patrick then thanked Deutsche Telekom for their hospitality and for the exellent
logistical support, and the meeting adjourned.