[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


 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



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

~Lincoln

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.





[JSR358-17] "license review" process loopholes effectively grant veto power Created: 21/Sep/11  Updated: 08/Apr/14

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

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


 Description   

Process Document review

line numbers: JCP-2.8-21SEP2011-Redlined.pdf

471-474 - too open-ended. Can only two members kick a license into Oracle legal? No timeframe for Oracle legal to make a decision. Also major problems with making this rest on Oracle legal. Should go through an independent mediator. The EC can always vote no, but it should be allowed a vote, otherwise this gives Oracle veto power.

PC> Please open an issue if you want to pursue this further.

SS> In other words, two members could call for a review and Oracle legal could simply take forever to make a decision, holding up the license until patents/copyrights revert to the public domain.

Suggestions: review requires a majority vote (2/3?) and is done by independent legal counsel.



 Comments   
Comment by sean_sheedy [ 21/Sep/11 ]

This is another issue where a choice of clearly open licenses would eliminate this problem altogether.

Comment by pcurran [ 22/Sep/11 ]

We've tried and failed to document this undocumented process to the satisfaction of all concerned.

On behalf of Steve Wolfe (IBM,) who suggested this after the September 21 Working Group meeting, I propose that we simply delete the text we added in an attempt to address this, and leave the issue unresolved (as it was when we started this JSR.)

We can take it up again in the JSR that modifies the JSPA.

Comments?

Comment by pcurran [ 29/Sep/11 ]

Agreed at the September 29 WG meeting:

Delete the sentence "The opinion of Oracle legal shall be the
final decision on the matter."

Defer this issue so we can address it in the future.

Comment by eduardo [ 30/Sep/11 ]

I have deleted the sentence in question

Comment by pcurran [ 01/Oct/11 ]

Reopening, so we can keep this on our radar as deferred





[JSR358-16] PMO should not be involved in Early Draft Review Created: 20/Sep/11  Updated: 10/Apr/14

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

Type: Improvement Priority: Major
Reporter: Bill Shannon Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by JCPNEXT4-18 PMO should not be involved in Early D... Closed

 Description   

Given the new transparency requirements, there seems to be little gained by involving
the PMO in Early Draft Review. It would be easier for the EG to publish its draft
specs on its project web site for review, whenever it wants, as often as it wants,
for as long as it wants, without having to inform the PMO.



 Comments   
Comment by pcurran [ 22/Sep/11 ]

We discussed this at the September 21 Working Group meeting, and agreed that there is value to having a formal review process. (Note also that we tie this to the time-out requirements.)

I'm closing this for now, but have added it to the JSR2 list for future consideration.

Comment by Bill Shannon [ 22/Sep/11 ]

I think it's sufficient that the formal review process start with Public Review.
Ditto the timeout.

Comment by pcurran [ 22/Sep/11 ]

I still don't want to make such an extensive change at this late stage.

I reopened, and deferred the issue. We'll look at it again later...

Comment by keilw [ 30/Jan/13 ]

As there are Renewal Ballots now actively conducted, does this still make sense, at least the "review, whenever it wants, as often as it wants, for as long as it wants, without having to inform the PMO." part?





[JSR358-20] Access to RI/TCK needs to be explicitly granted to EG and community participating in JSR review Created: 17/Jun/12  Updated: 06/Jul/12

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

Type: Bug Priority: Major
Reporter: starksm64 Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

This issue was first raised during the websocket jsr review as: http://java.net/jira/browse/WEBSOCKET_SPEC-2

Not withstanding the current claim that Section 4B of the JSPA 2 allows an "evaluation license to members of the EC", the wording of Section 4B does not explicitly name the Executive Committee:
B. Grants to Other Expert Group Members. You hereby grant to Member represented on any
Expert Group on which You are also represented under Your applicable patents, copyrights and trade secret
rights which You currently have or may acquire in the future a perpetual, non-exclusive, worldwide, royalty free,
fully paid-up, irrevocable license to use Your Contributions for research and development purposes
related to the activities of such Expert Group. Similarly, Oracle makes the same grant to You with respect to its
Contributions concerning Expert Groups on which You are represented. These grants, from You to other
Members and from Oracle to You, shall not include distribution to third parties of early access implementations
of the Spec under development by Your Expert Group until the draft Spec has been released for Public
Review.

This needs to be spelled out explicitly.

Further, in the interest of transparency, JCP members should be able to provide input on the validity of RIs and TCKs without the burden of having to become licensees of the technology.



 Comments   
Comment by pcurran [ 05/Jul/12 ]

This is out of scope for this JSR, which is not modifying the JSPA and therefore cannot fix any problems in that document.

There is no problem in practice since you can "provide input on the validity of RIs and TCKs without the burden of having to become licensees of the technology."

The Process Document states that "the Spec Lead shall send the Final Draft of the Specification to the PMO together with instructions on how EC members can obtain the RI and TCK for evaluation. The PMO shall circulate the materials to the EC and initiate the Final Approval Ballot."

As you know, we never initiate a Final Approval Ballot without giving EC members access to the RI and TCK.

So, while I agree that this should be clarified in the JSPA, that's no reason to hold up the completion of this JSR. I will therefore close this issue.

Comment by pcurran [ 05/Jul/12 ]

See my most recent comment.

Comment by pcurran [ 05/Jul/12 ]

I've just noticed that the wording of this issue states that the "community" should also be granted access to the RI and TCK. That is not required by the current version of the Process, and is therefore also out of scope for this JSR (which is limited to changes required to implement the EC merge.)

Comment by pcurran [ 06/Jul/12 ]

Although out of scope for JSR 355 this issue is obviously in-scope for JSR 358. I've reopened it, and will move it over to that project.





Generated at Sun Aug 28 13:15:14 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.