[JSR348-11] 1.2.1 - Apache licence should be required or promoted for Specification RI and TCK Created: 19/Jul/11  Updated: 04/Aug/11  Resolved: 20/Jul/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

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


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

Comment by Mark Struberg [ 19/Jul/11 ]

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.

Comment by pcurran [ 20/Jul/11 ]

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)

Comment by lightguard [ 20/Jul/11 ]

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

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 lincolnbaxter [ 25/Jul/11 ]

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?

Comment by starksm64 [ 29/Jul/11 ]

The JSR2 list is the that will be addressed by the followup to JSR348, and currently contains the items given by this document:

Comment by pcurran [ 04/Aug/11 ]

Closing, since this is on the list for JSR2

Generated at Sat Jul 30 04:12:04 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.