jsr358
  1. jsr358
  2. JSR358-48

A goal of RI/TCK IP working group should be access to the RI/TCK by community

    Details

      Description

      One goal we would like to see more explicitly stated is that access to both the RI and TCK is to be granted freely (as in beer) to all community members. This would not necessarily include the right to declare an implementation as compatible or use any branding right. Dealing with the separation between the right to access and use the RI/TCK versus the support, certification cost recovery and branding have to be dealt with as separate concerns.

        Activity

        Hide
        pcurran added a comment -

        We agreed on a compromise long ago: collaborative development processes and open-source licensing for RIs, and a Community TCK License for TCKs.

        Show
        pcurran added a comment - We agreed on a compromise long ago: collaborative development processes and open-source licensing for RIs, and a Community TCK License for TCKs.
        Hide
        lightguard added a comment -

        You're saying all previous JSRs and their TCKs will remain closed, but future ones will be open?

        Show
        lightguard added a comment - You're saying all previous JSRs and their TCKs will remain closed, but future ones will be open?
        Hide
        steven_g_harris added a comment -

        I suggest we push for this as a requirement for all new JSRs and grandfather-in (if the Spec Lead wants) the existing and maintenance ones. This allows Oracle to keep its existing JCK in closed source form, but forces everyone, including Oracle, to do things openly on new JSRs. Thus, as SE and EE move forward, they will become more open as component JSRs are forced to be open. And if Oracle as spec lead on SE and EE can't deal with it, then they can just not include any of the new component JSRs that are open. Choose: open or don't include it in an umbrella spec.

        Show
        steven_g_harris added a comment - I suggest we push for this as a requirement for all new JSRs and grandfather-in (if the Spec Lead wants) the existing and maintenance ones. This allows Oracle to keep its existing JCK in closed source form, but forces everyone, including Oracle, to do things openly on new JSRs. Thus, as SE and EE move forward, they will become more open as component JSRs are forced to be open. And if Oracle as spec lead on SE and EE can't deal with it, then they can just not include any of the new component JSRs that are open. Choose: open or don't include it in an umbrella spec.

          People

          • Assignee:
            Unassigned
            Reporter:
            starksm64
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: