Skip to main content

[JSR 358 Observer] [JSR358 EG] Re: Re: Flattening of RI/TCK IP flow: question

  • From: Steve Wolfe < >
  • To:
  • Cc:
  • Subject: [JSR 358 Observer] [JSR358 EG] Re: Re: Flattening of RI/TCK IP flow: question
  • Date: Fri, 11 Jan 2013 15:38:27 -0500
  • List-id: <experts.jsr358.java.net>

Well, I think you are raising several related outbound licensing issues.

Lets try to separate the 3 components of the output of a JSR to see where we agree and disagree:

Spec - the current license structure is largely OK.  We would need to harmonize it with whatever ends up coming out of the RI and TCK discussions.

RI - some small set of simple licenses (I proposed OSS licenses including EPL, ASL, GPL), but the EC/EG as a whole needs to weigh in on this.

TCK - setting aside Oracle's unique position, I think the EC/EG should explore whether it continues to be important the JCP maintains the ability of spec leads to monetize their JSR investments through TCK fees.  There seem to be many successful orgs where this kind of cost recovery model isn't used with no apparent ill effect.  Can the PMO give us a list of JSRs in the past 3? 5? years where the TCK included fees?

Regards,
Steve

email:
phone: (914) 766-1051


Inactive hide details for Patrick Curran ---01/11/2013 02:09:45 PM---I'm not speaking for Anish, but I have similar concerns. IPatrick Curran ---01/11/2013 02:09:45 PM---I'm not speaking for Anish, but I have similar concerns. I don't think the problem is specific to Or

From: Patrick Curran < >
To: Steve Wolfe/Somers/IBM@IBMUS,
Cc:
Date: 01/11/2013 02:09 PM
Subject: [JSR358 EG] Re: [JSR 358 Observer] Re: Flattening of RI/TCK IP flow: question





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:

    Hi Anish,

    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.

    Regards,
    Steve

    email:
    ">
    phone: (914) 766-1051



    Inactive
          hide details for Anish Karmarkar ---01/11/2013 02:18:01
          AM---At the last call SteveH suggested that we do more work
          ovAnish 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 ">< >
    To:
    "> ,
    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).

    Few points:

    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
    possibilities?

    Thanks!

    -Anish
    --

GIF image



[JSR 358 Observer] [JSR358 EG] Flattening of RI/TCK IP flow: question

Anish Karmarkar 01/11/2013

[JSR 358 Observer] [JSR358 EG] Re: Flattening of RI/TCK IP flow: question

Steve Wolfe 01/11/2013

[JSR 358 Observer] [JSR358 EG] Re: Flattening of RI/TCK IP flow: question

Werner Keil 01/11/2013

[JSR 358 Observer] [JSR358 EG] Re: Re: Flattening of RI/TCK IP flow: question

Patrick Curran 01/11/2013

[JSR 358 Observer] [JSR358 EG] Re: Re: Flattening of RI/TCK IP flow: question

Gil Tene 01/11/2013

[JSR 358 Observer] [JSR358 EG] Re: Re: Flattening of RI/TCK IP flow: question

Anish Karmarkar 01/11/2013

[JSR 358 Observer] [JSR358 EG] Re: Re: Flattening of RI/TCK IP flow: question

Scott Stark 01/11/2013

[JSR 358 Observer] [JSR358 EG] Re: Re: Flattening of RI/TCK IP flow: question

Anish Karmarkar 01/11/2013

[JSR 358 Observer] [JSR358 EG] Re: Re: Flattening of RI/TCK IP flow: question

Steve Wolfe 01/11/2013

[JSR 358 Observer] [JSR358 EG] Re: Re: Flattening of RI/TCK IP flow: question

Patrick Curran 01/11/2013
 
 
Close
loading
Please Confirm
Close