[JSR358-14] 1.4 - Remove TCK Non-compete clauses/language Created: 19/Jul/11  Updated: 06/Jul/12

Status: Reopened
Project: jsr358
Component/s: Licensing
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lincolnbaxter Assignee: pcurran
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


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.


Comment by lincolnbaxter [ 19/Jul/11 ]

Process Doc Section 1.4

Comment by lincolnbaxter [ 22/Jul/11 ]

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

Comment by karianna [ 26/Jul/11 ]

This issue is too complex for JSR-348 and will be discussed under 'JSR.next 2' where licensing and TCK issues will be thrashed out.

Comment by pcurran [ 26/Jul/11 ]

I'm not sure what "non-compete language" you're referring to (unless it's in TCK licenses.)

Comment by pcurran [ 29/Jul/11 ]

Postpone to JSR2 - make sure it's on the list in sufficient detail.

Comment by pcurran [ 04/Aug/11 ]

I've added this issue to the JSR2 list, so I'm closing it here.

Comment by pcurran [ 15/Dec/11 ]

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.)

Comment by lincolnbaxter [ 15/Dec/11 ]

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.


Comment by pcurran [ 08/Jan/12 ]

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

Comment by lincolnbaxter [ 09/Jan/12 ]

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.

Comment by starksm64 [ 10/Jan/12 ]

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.

Generated at Sun Apr 30 18:52:11 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.