[I will not be able to join todays call]
I mentioned this briefly at the end of our last call: My main concern is that we include and discuss right-to-use license requirements for TCKs and RIs, and I am "less concerned" with the IP flow of patents and copyrights for those.
In practice, we would have to assume that some of the existing copyright and patent practices in the platform JSRs will need to still be allowed for JSRs under the current JSPAs. To be clear those practices (for all Java SE JSRs for example) have retained
strong ownership of the TCK by the Spec Lead, and allowed the Spec Lead to limit the way the code is used by licensees (including limitations of what code may be tested, and limitations of the field of use of the code being tested).
Regarding the GPL license note and OpenJDK: This will not serve the TCK issue. OpenJDK's Java SE source is GPLv2 (+ classpath exception). However, the OpenJDK TCK is completely closed sourced (see
), and only licensed the USE of the TCK for the very narrow purpose of testing limited scope code. There has never been an open
source Java SE platform TCK to my knowledge.
On Jan 11, 2013, at 11:09 AM, Patrick Curran <
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 simplification...
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
<Mail Attachment.gif>Anish Karmarkar ---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 the c
From: Anish Karmarkar
Date: 01/11/2013 02:18 AM
Subject: [JSR358 EG] Flattening of RI/TCK IP flow: question
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 is not
clear to me how it would work without treating the SL as special (which
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 as the
ones being used for the platform JSRs. This would require that the
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 directly
to the licensees, but allow the SL to make a grant under FRAND, OR
b) the non-SL contributors would grant an RF license to the Spec Lead
with the ability to sub-license and the SL makes a FRAND grant (the
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 other