jsr358
  1. jsr358
  2. JSR358-14

1.4 - Remove TCK Non-compete clauses/language

    Details

    • Type: Bug Bug
    • Status: Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Component/s: Licensing
    • Labels:
      None

      Description

      Having terminology in the JCP Process Doc which states that no-competing test-suite may be implemented for any JSR is a patently horrible idea.

      Not only should open-source licences be encouraged for TCK implementations, we must remove all "Non-compete" language regarding alternative test suites such as OpenTCK. It is currently not-allowed to contribute or implement "competing" test suites for Java EE specifications. This situation is unacceptible and completely counter to the nature of open source software development, and software development itself.

      --Lincoln

        Activity

        Hide
        pcurran added a comment -

        I'm reopening this issue since I'm cleaning up the JSR3 list (where this would have been discussed) and in the process of doing so I've reconsidered...

        As I pointed out earlier, there is no language in the current or previous versions of the Process Document that resembles a non-compete clause. Nor can I find any such language in the standard TCK license that Oracle publishes with its latest JSRs.

        This seems to be a non-issue and I'd like to close it for good.

        (The more general issue of what kinds of license should be used for RI and TCK will remain on the list for the future JSR.)

        Show
        pcurran added a comment - I'm reopening this issue since I'm cleaning up the JSR3 list (where this would have been discussed) and in the process of doing so I've reconsidered... As I pointed out earlier, there is no language in the current or previous versions of the Process Document that resembles a non-compete clause. Nor can I find any such language in the standard TCK license that Oracle publishes with its latest JSRs. This seems to be a non-issue and I'd like to close it for good. (The more general issue of what kinds of license should be used for RI and TCK will remain on the list for the future JSR.)
        Hide
        lincolnbaxter added a comment -

        Hey Patrick,

        I'll re-review the docs and attempt to locate the statement for which this issue was created. Thanks so much for taking such close attention to these issues.

        ~Lincoln

        Show
        lincolnbaxter added a comment - Hey Patrick, I'll re-review the docs and attempt to locate the statement for which this issue was created. Thanks so much for taking such close attention to these issues. ~Lincoln
        Hide
        pcurran added a comment - - edited

        Bill Shannon has pointed out that there is "non-compete" language in Oracle's standard TCK license:

        In section 2.1(b)(iv) it states that Licensee may not

        (iv) develop other test suites intended to validate compatibility with the Java
        Specification(s) to which the TCK(s) licensed hereunder corresponds

        Show
        pcurran added a comment - - edited Bill Shannon has pointed out that there is "non-compete" language in Oracle's standard TCK license : In section 2.1(b)(iv) it states that Licensee may not (iv) develop other test suites intended to validate compatibility with the Java Specification(s) to which the TCK(s) licensed hereunder corresponds
        Hide
        lincolnbaxter added a comment -

        Yes! That's the statement. I got this confused with the process Doc probably because I had read them around the same time. Sorry for the confusion, but glad it has been found.

        Show
        lincolnbaxter added a comment - Yes! That's the statement. I got this confused with the process Doc probably because I had read them around the same time. Sorry for the confusion, but glad it has been found.
        Hide
        starksm64 added a comment -

        This does need to be addressed in the followup jcp process revision. Effectively every tck implementor has their own testsite that touches on compatibility issues and it is silly to have these be in conflict with the tck license.

        Show
        starksm64 added a comment - This does need to be addressed in the followup jcp process revision. Effectively every tck implementor has their own testsite that touches on compatibility issues and it is silly to have these be in conflict with the tck license.

          People

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

            Dates

            • Created:
              Updated: