I'm not speaking for
Anish, but I have similar concerns.|
I don't think the problem is specific to Oracle (or more
correctly, to the Platform Spec Lead.) Unless we're going to ban
FRAND licensing (including cost-recovery for TCK development)
entirely, then the situation could arise with any Spec Lead.
You seem to be saying that if the Spec Lead chooses to license the
RI and TCK under, for example, Apache then inbound all inbound
grants would be made under that license. If the Spec Lead chooses
Eclipse, then inbound grants would be made under Eclipse. What
would be the inbound grant if the Spec Lead chooses some kind of
FRAND grant involving license fees?
Just for the record, I'm sure we all share the goal of
On 1/11/2013 8:47 AM, Steve Wolfe wrote:
I assume your point # 1 is
specifically trying to address Oracle as a spec lead. I don't
believe all spec leads would need special rights or a more
restrictive license - they should have whatever they need
simply by the JSPA requiring inbound grants be made under the
license the spec lead has chosen are for the outbound grant,
be that ASF or EPL, etc.
As far as Oracle's special
position as the provider of platform JSRs, I believe I
addressed that issue in two ways in my presentation. First,
one of the licenses I suggested as part of the "short list"
was a GPL license consistent with what Oracle is using at
OpenJDK. That license would also be available as a choice to
other spec leads. In addition, I had indicated that in order
for Oracle to fulfill its obligations under their TLDAs,
Oracle JSR's as well as 3rd party JSRs which intended to be
incorporated into the Oracle platform JSRs would require
contributors to agree to a supplemental grant to Oracle.
As I have said before, I think
the Java ecosystem has been hampered by a JCP tied to a JSPA
which is very complex and nearly incomprehensible. The
current structure of the JSPA is clearly out of step with the
IP models being used by the current generation of industry
standards organizations. My hope was that we could create a
very simple model that would be attractive to the developers
and technologists familiar with these more modern models,
while layering on top some limited specific licensing that are
only encountered when enabling Oracle to fulfill its
obligations under its TLDAs.
Hope that helps.
phone: (914) 766-1051
---01/11/2013 02:18:01 AM---At the last call SteveH suggested
that we do more work over email rather than just relying on
From: Anish Karmarkar
Date: 01/11/2013 02:18 AM
Subject: [JSR358 EG] Flattening of RI/TCK IP
At the last call SteveH suggested that we do
more work over email rather
than just relying on the calls. So here is an attempt.
I have been thinking about flattening of RI/TCK IP flow and it
clear to me how it would work without treating the SL as
we have been trying to avoid so far).
1) Even if we agree on a set of standard licenses for RI/TCK,
such a set
would contain more restrictive (compared to ASL) licenses such
ones being used for the platform JSRs. This would require that
licensee come to the SL and sign the bilateral license.
2) I don't think we want licensees to obtain licenses from all
contributors to a JSR. That would be burdensome.
3) This means that either
a) the non-SLs contributors would have to grant an RF license
to the licensees, but allow the SL to make a grant under
b) the non-SL contributors would grant an RF license to the
with the ability to sub-license and the SL makes a FRAND grant
current hub-and-spoke model).
In either case, the SL is treated as special, but 3a) does
flatten the flow.
SteveW: is 3a) how you envision it would work? Did I miss