[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-8] Licenses can change after EG member has contributed Created: 21/Sep/11  Updated: 08/Apr/14

Status: Open
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

285-287 - We just went through a big deal with TCK licensing. Strike last sentence of paragraph, and add RI & TCK to preceding sentence. The EG members must not have a moving target after joining an EG.

PC> Good luck with that. It's impractical. There can be many legitimate reasons to tweak the original license. EC members are free to express their disapproval of changes by voting no.

SS> But EG members have no such recourse. This is one reason I feel Individuals need to be very aware of what they are getting into when they join a JSR. It is things like this - licenses that can be moving targets, ability for spec lead to effectively withdraw a JSR from further licensing - which makes this platform not a truly open platform. Solution: wording that advises socialization of licenses prior to initial JSR approval, and upon approval, the license is final; the license can only be changed with unanimous approval of any EG member who contributed to the specification. Otherwise a spec lead can lead the charge to change licensing, get a lot of members to agree, and leave others out in the cold. What if those others were individuals who joined on the promise of getting an open source license, but it was later switched for one less open? This is totally plausible, because individuals are sometimes the minority in an EG, and the EG process for stuff like this is at best loosely defined, so what may work for corporations (which have a back-channel available to them via cross-licensing agreements) might not work for individuals. I understand something like this happened with an SE/EE Resources API JSR but I am not clear on the details. I can try to get them if necessary.

Again: proposal - don't change license after initial approval (and before EG formation) without unanimous past/present EG member vote.



 Comments   
Comment by sean_sheedy [ 21/Sep/11 ]

Related:

468 - Change "proposed" to "final" so that prospective EG members and the EC are not surprised by changes to the licenses. To this end, we should recommend to spec leads that they socialize their licenses well in advance of a vote.

PC> As I said above, prohibiting any changes to licenses after initial submission is impractical.

SS> Again, requesting this for fairness - someone who has contributed and who finds himself out of luck due to a license change that the majority approved has no recourse.

Comment by pcurran [ 22/Sep/11 ]

It's too late to try to resolve this. I've marked it Defer for future consideration.

We've only just introduced the modified language around license disclosure. Let's see how things work out in practice.





[JSR358-9] Licensing can be withdrawn before natural expiration of copyrights/patents Created: 21/Sep/11  Updated: 02/Apr/15

Status: Open
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

Issue Links:
Related
is related to JSR358-34 End of Life for JSRs Open

 Description   

Process Document review

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

288 - "Lifetime" is a new term that implies that a JSR can be end-of-lifed and the license revoked. Strike "During the lifetime of the JSR the"

PC> Already fixed in a later draft

SS> I see the wording has been changed to "For as long as a JSR is licensed". This still implies that there is a lifetime. Contrast this to open source licenses like Apache or GPL which do not withdraw licenses except under specific situations; licenses like BSD have no lifetime; they expire only when the original copyright expires and the work goes into the public domain. We're not talking open source even here, but open platform. Text like this that implies that there is a lifetime provides an opportunity to spec leads to withdraw licenses. This could occur, for example, if the spec lead is offering a new technology and wishes to prevent licensing of the original JSR because implementations of it would compete with them. The work would then not be available until patents expire (20 or more years) or the copyright on the RI/TCK expires (much longer, and potentially boundless if "Mickey Mouse" extensions of copyright lifetimes are legislated.)

Fix by requiring spec lead to provide license until work(s) fall under public domain. This highlights an area where the JCP deviates from open principles.



 Comments   
Comment by pcurran [ 21/Sep/11 ]

Now we're straying into JSPA territory again. As we've said in responding to related issues, the obligation of the Spec Lead to license the output of the JSR, whether this obligation expires and if so under what circumstances can only be specified in the JSPA.

We've done as much as we can to address these issues in the Process Document.

I will defer this issue to a future JSR.

Comment by pcurran [ 01/Oct/11 ]

Here's a reference that will help when we get back to this.

See 6.10. On-going Support in Ken Krechmer's The Meaning of Open Standards. We need to allow for "recission" of a JSR.





[JSR358-5] Permit free redistribution of the Process Document Created: 21/Sep/11  Updated: 02/Apr/15

Status: Open
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   

5 process doc, line 6 standing rules - Should be some form of Creative Commons license, as default copyright requires license for redistribution, modification, etc.

PC> This is a normative document. It makes no sense to use a copyright that allows people to modify it at will.

SS> not about modification, it's about being able to distribute and quote without fear of charges of copyright infringement



 Comments   
Comment by pcurran [ 21/Sep/11 ]

I've deferred this, on the grounds that all license-related matters - except for the requirement to disclose - are out of bounds for this JSR and can only be dealt with by a JSR that modifies the JSPA.

Comment by lightguard [ 06/Jul/12 ]

Pity, having them be Creative Commons licensed would be a big plus.

Comment by keilw [ 22/Jul/13 ]

This is losely related to JSR358-49, assuming, Sean referred to the "Spec License" with "doc license".
One or the other Spec Lead expressed the desire to relicense the "docs" (everything so far considered to be part of the "Spec" under different licenses if hosted by different forges or servers.

Should be possible to clarify with Oracle Legal.

Comment by pcurran [ 02/Apr/15 ]

Sean was specifically addressing the fact that the Process Document is copyrighted by Oracle, and asking whether this permitted distribution. That is something that should be clarified and if necessary addressed.

I have reworded the issue to make this clear.

His reference to "modification" was simply misleading.





[JSR358-3] Vague language in the TCK license for JSR 356 Created: 07/Mar/12  Updated: 06/Jul/12

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

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


 Description   

HP's lawyers provided the following feedback:

We have concerns about phrases such as "... (including relevant excerpts of the TCK, provided such TCK excerpts are inherently part of such results), but not the non-relevant portions of the TCK itself." Words such as relevant and non-relevant are open to differing interpretation, and the concept of TCK excerpts being part of the results doesn't make sense.



 Comments   
Comment by pcurran [ 07/Mar/12 ]

I believe that the intent of the "relevant excerpts of the TCK" phrase was to permit small extracts of source-code to be exchanged if necessary.

Comment by lightguard [ 06/Jul/12 ]

At the very least people should be able to give a classname and method if not full source for test / method in question.





[JSR358-2] The TCK license for JSR 356 prohibits the development of other compatibility tests Created: 07/Mar/12  Updated: 22/Jul/13

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

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


 Description   

Section 2.1.b.iv of the TCK license for JSR 356 prohibits the licensee from "develop[ing] other test suites intended to validate compatibility with the Java Specification(s) to which the TCK(s) licensed hereunder corresponds." As written, this appears to prohibit licensees from developing their own internal tests for compatibility supplement tests in the TCK.



 Comments   
Comment by lightguard [ 06/Jul/12 ]

This would be a huge step for the community to step up and include tests where the TCK falls short, or provide some other supplements for common use cases that come up with may not be covered in the TCK which would allow for a vendor migration test suite. Such a suite would be a very important tool for users.

Comment by lightguard [ 04/May/13 ]

Has there been any further work on this?

Comment by keilw [ 22/Jul/13 ]

JSR 356 went Final, so @patrick, could we close this or is there a reason to keep it open?





[JSR358-1] TCK license prohibition on claims of comparative compatibility inhibits open discussion Created: 07/Mar/12  Updated: 06/Jul/12

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

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


 Description   

Section 2.1.b.vi of the TCK license for JSR 356 prohibits making "claims of comparative compatibility (for example, a claim either that a Product is "90% compatible" or that the Product is "more compatible" than another implementation of the same Java Specification)."

Such claims would be appropriate during the development of an implementation and should not be prohibited.






[JSR358-40] JSPA 5.F.IV, drop or modify scope of exemption for Oracle RI/TCK licensing Created: 23/Aug/12  Updated: 23/Aug/12

Status: Open
Project: jsr358
Component/s: Licensing, TCKs, Transparency
Affects Version/s: None
Fix Version/s: None

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


 Description   

In section 5.F.IV of the JSPA from

Notwithstanding the foregoing, neither this subparagraph IV nor Section 5.F.II (concerning reciprocal patent licensing, shall be understood to require Oracle to modify license agreements for Java technology that Oracle has in place, or to modify or replace in future license agreements for Java technology provisions comparable to those currently in place, where the RI and/or TCK would be covered by such license agreements. This proviso shall not be understood to exempt Oracle, when it is the Spec Lead, from the obligation to license the TCK separate from the corresponding RI code when the Spec is developed under any JSR submitted hereafter.

I would argue this is unnecessarily broad and should be dropped in the spirit of transparency as one cannot understand that ramifications of the statement by reading the available JCP documents.



 Comments   
Comment by starksm64 [ 23/Aug/12 ]

Section 6.C makes a similar statement regarding section 6.

C. Effect on Existing Agreements. No provision of this Section 6 shall be understood to require Oracle to modify license agreements for Java technology that Oracle has in place, or to modify or replace in future license agreements for Java technology provisions comparable to those currently in place, with respect to Oracle’s granting of license for (or covenants not to assert) its patent claims where there is no technically feasible alternative that would avoid the infringement of such claims (with respect to Your exercise of the rights described in Section 6.A.[a]-[c]).





[JSR358-84] Need a complete answer on the ASLv2 incompatibility issue Created: 02/Oct/14  Updated: 02/Oct/14

Status: Open
Project: jsr358
Component/s: Compatibility, Licensing
Affects Version/s: None
Fix Version/s: None

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


 Description   

We and other EC members continue to be wonder why there is not a simple solution to the issue of inclusion of ASLv2 licensed software into Java platform JSRs. At the last Java EC face to face meeting, there was a reference to http://www.apache.org/licenses/GPL-compatibility.html, but no answers to basic followup questions.

We would like to understand why, in the Specification Lead's view, ASFv2 licensed software should not be included in Java platform JSRs under these revisions. We observe that the current GPLv2+classpath exception license used by the platforms seems to allow for the inclusion of such code. An explanation beyond referencing http://www.apache.org/licenses/GPL-compatibility.html would be appreciated. Oracle's position as copyright holder and ability to relicense the Java platform on commercial terms should be addressed in the answer.






[JSR358-93] Create a standard Spec license Created: 07/Mar/15  Updated: 07/Mar/15

Status: Open
Project: jsr358
Component/s: Compatibility, Licensing
Affects Version/s: None
Fix Version/s: None

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


 Description   

We have an "almost-standard" Spec license that is used for almost all JSRs. It's time to standardize this and to make its use compulsory.






[JSR358-91] Remove from licenses any barriers to full compliance with JCP 2.8's transparency requirements Created: 06/Mar/15  Updated: 06/Mar/15

Status: Open
Project: jsr358
Component/s: Licensing, Transparency
Affects Version/s: None
Fix Version/s: None

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


 Description   

JSR 348 mandated transparent Expert Group operations.

Ensure that license terms do not inhibit or conflict with these requirements, for example by permitting or mandating confidentiality.






[JSR358-92] Create a standard Community TCK License Created: 07/Mar/15  Updated: 07/Mar/15

Status: Open
Project: jsr358
Component/s: Licensing, Participation, TCKs
Affects Version/s: None
Fix Version/s: None

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


 Description   

Create a standard Community TCK License modeled on the OpenJDK Community TCK License Agreement (OCTLA).

This license would grant access to the TCK to all participants in a JSR's collaborative RI-development project.






[JSR358-49] Ambiguity of Specification, Content and License causes Spec Leads to ignore it or use other licenses Created: 30/Jan/13  Updated: 08/Apr/14

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

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


 Description   

The Process Document under Definitions
http://jcp.org/en/procedures/jcp2_9#DEF
defines
>Java Specification (Specification): A written specification for some aspect of the Java technology. This includes the language, virtual >machine, Platform Editions, Profiles, and application programming interfaces.

Several Spec Leads and related organizations interpret "Specification" only as the first part of that, "A written specification for some aspect of the Java technology." ignoring the remaining definition, especially "and application programming interfaces."

This first became clear, when I looked at all aspects of JSR 330, Dependency Injection, including Spec, RI and TCK prior to my vote.
While, Bob Lee may have been misinformed, and we know, 330 was rushed into Java EE 6 not to miss the Release Train and still be used by CDI, that JSR and several others, mostly EE and non-Oracle lead have applied the same practice. It also looks the same for JSR 352, Batch, all the way down to the Java sources of the Specification which say "Apache License".

This seems to be a common question of Spec Leads, e.g. one said:
>We license all software artifacts, including JavaDoc, API jars etc. under the Apache License 2. It's only the Spec text that is >licensed differently, AIUI.
So several Spec Leads assume, the Spec License was a "Shrinkwrap" license, before you download the Spec text (the "written specification for some aspect of the Java technology.") from JCP.org, but is otherwise irrelevant to their JCP or its users.

Hence, where the Spec API is "really" downloaded from in everyday life, Maven, Artifactory, Eclipse P2 or similar Software repositories, none of the specs ever even mention a Spec License. Those who do also use Apache or a respective other license, usually that of the RI. Others may not mention a license, mainly Oracle lead specs, who leave the (Maven) POM or similar metafiles empty.
With few exceptions like the Java EE 6 Web Profile, or newer JSRs by Oracle to be included in Java EE 7.

  • If the Spec License really does only apply to the written document, not any API or actual Java code, then there is no action required.
  • If this is not the case, both Process Document, and probably other resources like Spec Lead Guide should be revised and improved for a better understanding by Spec Leads and EG Members.

For most Build Tools like Maven, this could also be supported by plugins like "License Maven Plugin" to check and adjust licenses.



 Comments   
Comment by keilw [ 02/Feb/13 ]

Sonatype, the keepers of MavenCentral are just starting this "Java Application Health Check" Program:
http://www.sonatype.com/Products/Application-Health-Check
Which certainly uses information in its POM, not plain text documents accompanying a JSR.

Comment by keilw [ 09/Feb/13 ]

Even an Oracle-lead JSR, 236, Concurrency Utilities for Java EE has a discrepancy between Spec and API License.
the Spec License is mentioned on the detail page:
http://jcp.org/aboutJava/communityprocess/licenses/jsr236/JSR-236-spec-license-2_17_12.pdf

While the API is licensed under one or both of these 2
<licenses>
<license>
<name>CDDL 1.1</name>
<url>http://glassfish.java.net/public/CDDL+GPL_1_1.html</url>
<distribution>repo</distribution>
</license>
<license>
<name>GPL2 w/ CPE</name>
<url>http://glassfish.java.net/public/CDDL+GPL_1_1.html</url>
<distribution>repo</distribution>
</license>
</licenses>

This confirms the assumption, though a final assesment by either this EG or Oracle Legal could be helpful, that the "Spec License" is nothing more than "shrinkwrap" for the PDF or similar written document. And totally irrelevant to the actual API and other binaries.

Unless there is a legal requirement for this overhead, why can't it be dropped and replaced by a Single Spec License for Spec/API, RI and TCK???

The "compatibility" argument is ridiculous, given that not this PDF document, but the actual code and binary licensed totally different is running everywhere.

Comment by keilw [ 22/Feb/13 ]

Based on the Batch JSR, the Spec Lead consulted IBM legal team and they informed him all content delivered in the RI,
including the javax.batch.* files, must carry the RI license. Only the spec (paper/prosa document from their advice)
carries the spec license.

That confirms what Red Hat and at least for JSR 236 also Oracle Legal seem to agree on. As spoken in the last EC call, it makes a separate "Spec" license barely relevant and is a strong argument in favor of Scott/Red Hat's recent proposal.

Comment by keilw [ 22/Jul/13 ]

Unless there is a different statement by Oracle Legal (or i.E. Jim Wright) licenses of the API (javax.*) tend to be the identical to the RI license in a majority of JSRs, while the plain text Spec document as well as JavaDoc for this API is commonly understood as covered by the Spec License.

Note, Red Hat Spec Leads (e.g. CDI and Bean Validation, also pending JSRs like 347) expressed the intent to dual-license also the Spec documents, see below from a thread on the Spec License with Pete Muir, as well as EC Reps Mark and Scott:
===
I don't infer the same conclusion from Bill's comment as you do, I'm afraid. I will speak to our legal team to get their expert opinion on this matter, but assuming they approve, I will be publishing the Javadoc on jboss.org under the apache 2 license, effectively dual licensing the javadoc such that the version you get from the jcp page, which is behind the Oracle click through license, is licensed using the Oracle spec license, and the versions you get from maven, jboss.org or cdi-spec.org are Apache 2 licensed.

To date, I believe there are no licensing issues, as we do agree that the version of the javadoc and spec you get from jcp.org, >which are the versions you are reviewing for the Final Ballot, are both licensed under the spec license, and are adequately flagged >as such, due to the presence of the click through license agreement. The version you get from Maven is clearly Apache License, as >the POM correctly states the license. We have not yet published a version on docs.jboss.org or cdi-spec.org.
===





[JSR358-48] A goal of RI/TCK IP working group should be access to the RI/TCK by community Created: 11/Jan/13  Updated: 02/Apr/15

Status: Open
Project: jsr358
Component/s: Intellectual Property, Licensing, Participation
Affects Version/s: None
Fix Version/s: None

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


 Description   

One goal we would like to see more explicitly stated is that access to both the RI and TCK is to be granted freely (as in beer) to all community members. This would not necessarily include the right to declare an implementation as compatible or use any branding right. Dealing with the separation between the right to access and use the RI/TCK versus the support, certification cost recovery and branding have to be dealt with as separate concerns.



 Comments   
Comment by steven_g_harris [ 11/Jan/13 ]

I suggest we push for this as a requirement for all new JSRs and grandfather-in (if the Spec Lead wants) the existing and maintenance ones. This allows Oracle to keep its existing JCK in closed source form, but forces everyone, including Oracle, to do things openly on new JSRs. Thus, as SE and EE move forward, they will become more open as component JSRs are forced to be open. And if Oracle as spec lead on SE and EE can't deal with it, then they can just not include any of the new component JSRs that are open. Choose: open or don't include it in an umbrella spec.

Comment by lightguard [ 22/Feb/13 ]

You're saying all previous JSRs and their TCKs will remain closed, but future ones will be open?

Comment by pcurran [ 02/Apr/15 ]

We agreed on a compromise long ago: collaborative development processes and open-source licensing for RIs, and a Community TCK License for TCKs.





[JSR358-47] Can/Should we strengthen reciprocity to apply across JSRs? Created: 21/Dec/12  Updated: 21/Dec/12

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

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


 Description   

The reciprocity language in current JSPA provides powerful protection. In effect, it allows a Spec lead to outbound-license the inbound patent rights associated with a specification such that asserting patents against a compatible implementation of a JSR would become impractical for any company making use of the JSR technology.

Given the prevalent use of some JSRs this provides all users of those JSRs with powerful protection against patent attacks. E.g. very few companies exist that can afford to stop making any use of Java SE or Java EE.

The question here is: Should we extend this powerful reciprocity protection across JSRs, such that IP rights involved in ANY JSR technology depends on the licensee's willingness to provide reasonable license terms to patents the licensee holds on ANY JSR.






Generated at Tue Aug 23 22:05:35 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.