jsr348
  1. jsr348
  2. JSR348-11

1.2.1 - Apache licence should be required or promoted for Specification RI and TCK

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Component/s: Process Doc
    • Labels:
      None

      Description

      Process Doc Section 1.2.1:

      Apache license for spec license for spec license should be PROMOTED, not shunned. In addition to open TCKs, TCK licensing fees must be dropped (obviously.) - Lincoln

        Activity

        Hide
        Mark Struberg added a comment -

        That's a strong point. Opening the TCK would really be appreciated.

        There has been the argument that the restrictive TCK license has been chosen to prevent people from changing the TCK and then only passing it that way.

        In fact this argument is not true if the JCP still retain and defends the Trademarks. Anyone could fork and change the TCK code, but noone could call it the "Xxx-Tck" afterwards.

        In practice this would lead to lots of contributions from the community in form of additional tests and bugfixes in the TCK.

        Show
        Mark Struberg added a comment - That's a strong point. Opening the TCK would really be appreciated. There has been the argument that the restrictive TCK license has been chosen to prevent people from changing the TCK and then only passing it that way. In fact this argument is not true if the JCP still retain and defends the Trademarks. Anyone could fork and change the TCK code, but noone could call it the "Xxx-Tck" afterwards. In practice this would lead to lots of contributions from the community in form of additional tests and bugfixes in the TCK.
        Hide
        pcurran added a comment -

        The Apache license is unacceptable for the Spec License since it would remove all compatibility requirements (a fundamental aspect of the JCP.)

        As for the broader issue of recommended licenses, this is far too complex to be dealt with in JSR 348 (JCP.next JSR1) but is already on the list for JCP.next JSR2 (see http://java.net/downloads/jsr348/Working%20documents/JSR2-List-May23.html#Licensing)

        Show
        pcurran added a comment - The Apache license is unacceptable for the Spec License since it would remove all compatibility requirements (a fundamental aspect of the JCP.) As for the broader issue of recommended licenses, this is far too complex to be dealt with in JSR 348 ( JCP.next JSR1 ) but is already on the list for JCP.next JSR2 (see http://java.net/downloads/jsr348/Working%20documents/JSR2-List-May23.html#Licensing )
        Hide
        lightguard added a comment -

        The JSR2 list is the follow-up JSR currently tentatively scheduled for May 2012?

        Show
        lightguard added a comment - The JSR2 list is the follow-up JSR currently tentatively scheduled for May 2012?
        Hide
        lincolnbaxter added a comment -

        These ideas were drafted by an independent group reviewing the Early Draft from June 21, 2011 - apologies for out-of-date issues.

        Show
        lincolnbaxter added a comment - These ideas were drafted by an independent group reviewing the Early Draft from June 21, 2011 - apologies for out-of-date issues.
        Hide
        lincolnbaxter added a comment -

        I think our point may have been confused here. We are not suggesting we use the Apache License for the Specification itself, but our intent was rather that the TCK and Reference Implementation should be Apache Licensed.

        I also don't necessarily agree that "The Apache license is unacceptable for the Spec License since it would remove all compatibility requirements (a fundamental aspect of the JCP.)"

        I'd argue that the Apache license is fine for the Spec itself as well; it would promote innovation, and would not remove compatibility requirements because the Spec maintained by the JCP would be the spec which is certified against. It doesn't matter if there what the license is, because the JCP is the body that certifies, not the specification. Unless there are other concerns?

        Show
        lincolnbaxter added a comment - I think our point may have been confused here. We are not suggesting we use the Apache License for the Specification itself, but our intent was rather that the TCK and Reference Implementation should be Apache Licensed. I also don't necessarily agree that "The Apache license is unacceptable for the Spec License since it would remove all compatibility requirements (a fundamental aspect of the JCP.)" I'd argue that the Apache license is fine for the Spec itself as well; it would promote innovation, and would not remove compatibility requirements because the Spec maintained by the JCP would be the spec which is certified against. It doesn't matter if there what the license is, because the JCP is the body that certifies, not the specification. Unless there are other concerns?
        Hide
        starksm64 added a comment -

        The JSR2 list is the that will be addressed by the followup to JSR348, and currently contains the items given by this document:
        http://java.net/downloads/jsr348/Working%20documents/JSR2-List-May23.html

        Show
        starksm64 added a comment - The JSR2 list is the that will be addressed by the followup to JSR348, and currently contains the items given by this document: http://java.net/downloads/jsr348/Working%20documents/JSR2-List-May23.html
        Hide
        pcurran added a comment -

        Closing, since this is on the list for JSR2

        Show
        pcurran added a comment - Closing, since this is on the list for JSR2

          People

          • Assignee:
            Unassigned
            Reporter:
            lincolnbaxter
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: