[JSR358-96] create errata process, separate from the MR process Created: 13/Apr/15  Updated: 13/Apr/15

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

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


 Description   

As I describe here, there are two JCP processes (JSR, MR) that we use for two different kinds of changes (new spec version, errata). Unfortunately, the processes don't match the kinds of changes we make, which leads to confusion.

Having a lightweight process for creating a new version of a spec (the MR process) is important, but it would reduce confusion if there were a separate process for correcting errors in existing specifications (errata).

In the simplest case, errata might fix typographical and formatting errors in a specification document. They are also use to fix inconsistencies in a specification, improve the description of requirements, etc. There are some key differences between an errata and an MR or JSR:

  • Errata do not create a new version of a spec. If the spec was version "Wombat 1.1" before the errata, the spec is still version "Wombat 1.1" after the errata.
  • Errata update a spec by introducing a new "rev level" of the specification document, e.g., updating "Wombat 1.1" to "Wombat 1.1 rev A". Both documents are specifications for the "Wombat 1.1" API.
  • Errata apply to existing licensees of a spec, they do not create a new spec that can be licensed, or that existing licensees can choose to upgrade to. Thus, errata can not change the licensing terms for a spec.
  • Errata do not introduce new requirements, although they may clarify existing requirements.
  • Errata do not change API signatures except to correct inconsistencies between the specification and the reference implementation, or to correct incompatibilities with previous versions of the specification.
  • Errata do not change functional requirements except to correct inconsistencies between the specification and the reference implementation, or to correct incompatibilities with previous versions of the specification.
  • In general, errata will not require changes to the reference implementation or the TCK, except to correct inconsistencies or incompatibilities as described above.

A separate errata process with limitations of this sort will make it clear what sort of change is being proposed, and will distinguish these changes from the MR process, which becomes only a lightweight form of the JSR process used to introduce new versions of a spec.






[JSR358-94] Patrick: Assign specific issues for review Created: 18/Mar/15  Updated: 18/Mar/15

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

Type: Task 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   

Patrick should review all the open issues, and assign the "low-hanging fruit" to specific individuals for review.






[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-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-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-89] Mike Milinkovich: review JSPA for language preventing release of interim implementations prior to Final Release Created: 06/Mar/15  Updated: 01/Apr/15

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

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


 Comments   
Comment by mmilinkov [ 01/Apr/15 ]

This is a duplicate of JSR358-85.





[JSR358-88] Provide non-normative guidelines on RI license selection Created: 27/Feb/15  Updated: 27/Feb/15

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

Type: Bug Priority: Major
Reporter: pcurran Assignee: pcurran
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-87 Define a standard list of open-source... Open

 Description   

The choice of RI license will affect the possibility of a JSR being included in the Java platform. We decided to provide some non-normative guidelines on this matter in the Spec Lead Guide.



 Comments   
Comment by pcurran [ 27/Feb/15 ]

The guidelines should:

  • Warn Spec Leads of their responsibility to ensure that the terms under which they accept IP grants from contributors must be sufficient to ensure that they can make the necessary grants (including patent grants) to all implementors of the JSR, including those who implement in "clean-room" fashion directly from the Spec (that is, who do not derive their implementation from the RI).
    • A good way to do this is to ensure that they accept RI contributions only from those who have signed either the JSPA or the JCP's Associate Membership Agreement.
  • Advise Spec Leads that the license they choose and the IP rights granted by whatever contribution agreement applies to those who participate in developing the RI will affect the possibility of having their JSR included in the Java platform. If this is a goal they should consult with the relevant business team in Oracle before selecting a license.




[JSR358-87] Define a standard list of open-source RI licenses Created: 27/Feb/15  Updated: 27/Feb/15

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

Type: Bug Priority: Major
Reporter: pcurran Assignee: pcurran
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-88 Provide non-normative guidelines on R... Open

 Description   

We decided to mandate that all RIs (with the exception of those associated with the Java ME "platform JSRs") must be released under one of a short-list of "approved" open-source licenses.

We need to decide what's on that list.



 Comments   
Comment by pcurran [ 27/Feb/15 ]

Our current list is:

  • Apache
  • BSD
  • Eclipse
  • GPL
  • MIT
  • UPL

Note, however, that the choice of RI license will affect the possibility of a JSR being included in the platform. See the linked issue 88





[JSR358-85] IP should vest as soon as granted rather than when the JSR goes final Created: 24/Feb/15  Updated: 01/Apr/15

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

Type: Bug 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   

Many people interpret the current version of the JSPA as specifying that IP "vests" only when the JSR is completed rather than when the contribution is made. We should fix this.



 Comments   
Comment by pcurran [ 24/Feb/15 ]

A suggestion made several years ago by a Sun lawyer:
Change the definition of Output from:

"the Specification and associated Reference Implementation and Technology Compatibility Kit generated by an Expert Group with respect to the JSR for which that Expert Group is formed."

to:

"the Specification and associated Reference Implementation and Technology Compatibility Kit generated by an Expert Group, in any pre-final as well as final forms, with respect to the JSR for which that Expert Group is formed."

Comment by mmilinkov [ 01/Apr/15 ]

Caveat: I am not a lawyer, and the final wording of this will need to be validated by counsel.

That said:

(a) I am not particularly happy with the term "pre-final", as I really don't know what that means. Actually, I am not even sure it's a word.

(b) It has some interesting implications for when rights vest. So, for example, this new definition would mean that the grants in Section 4. would vest immediately, rather than when the spec went final.

(c) Even with the definition, the JSPA will require further editing. For example, see Section 6.A which says "...With respect to the Output of JSRs for which You are not the Spec Lead, You ...hereby agree to grant under each patent claim that You and/or such party own, will own or have the authority to license, **after adoption of the Spec**...".

So I think that the idea is helpful, but it is not the complete solution.





[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-82] Suggested language to help track changes in employment status Created: 26/Jun/14  Updated: 06/Mar/15

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

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

Issue Links:
Cloners
is cloned by JCPNEXT4-61 CLONE - Suggested language to help tr... Open

 Description   

The OpenStack membership agreement contains the following language:

"You agree to notify the Project Manager of any facts or circumstances of which you become aware that would make these representations inaccurate in any respect."

It might be helpful to add similar language to the JSPA and Affiliate Membership Agreement to help us to track members' changes in employment status.






[JSR358-66] Modify Process Document to simplify the transition of a JSR from one Spec Lead (or Maintenance Lead) to another Created: 08/Apr/14  Updated: 01/Apr/15

Status: Open
Project: jsr358
Component/s: Process Document
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   

Sections 2.1.1 and Section 5.1.1 address the transfer of JSRs from one Spec Lead (or Maintenance Lead) to another. Can we add anything here to make the transition simpler?

Should we insert language encouraging the outgoing SL or ML to transfer IP to the new lead since without this it will effectively be impossible for someone else to take over? (Whether or not this is necessary will depend on how the output of the JSR is licensed.)



 Comments   
Comment by pcurran [ 01/Apr/15 ]

If IP vests immediately it is contributed and we have a flat IP-flow whereby rights are passed directly from the contributor to whoever is developing the JSR then we may not need anything else.





[JSR358-64] Add requirement for collaborative ("open source") development process for RI to the Process Document Created: 08/Apr/14  Updated: 08/Apr/14

Status: Open
Project: jsr358
Component/s: Participation
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   

The Process Document must be modified to add the requirement for collaborative ("open source") development processes for RI.

We should require that the Spec Lead provide a pointer to the collaboration project's "home page".

We should define at a high level the characteristics we require of the collaboration project (should this be in the Process Document or separated out from it in something that can more easily be modified?)






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






[JSR358-45] Reciprocity should be mandated Created: 07/Dec/12  Updated: 07/Dec/12

Status: Open
Project: jsr358
Component/s: Intellectual Property
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   

Gil Tene to provide details.






[JSR358-44] Ensure that implementers are granted the right to incorporate IP into future as well as current implementations of a JSR Created: 07/Dec/12  Updated: 07/Dec/12

Status: Open
Project: jsr358
Component/s: Intellectual Property
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   

We need to ensure that rights granted for version 1 of a technology (defined in the JSR x) will also permit the Spec Lead to incorporate the IP into version 2 of the technology (defined in JSR y.)

Section 4.A.I.a of the JSPA states that copyrights and trade secrets are granted for inclusion "into current and future versions of the Output," which seems to take care of this issue. However, there is no equivalent language in section 4.A.II which covers patent grants. Here, rights are only granted for the Output (the artifacts generated by the current JSR and for compatible implementations of the Spec. By definition, implementations of a later Spec (generated by a different JSR that builds on the current JSR) are not compatible, since they subset the current JSR.

So - this appears to be broken now. Whether or not it is, we must make sure that it is not broken in the new version of the JSPA.






[JSR358-42] Language in the JSR 336 TCK license appears to prohibit implementations of the Spec Created: 13/Oct/12  Updated: 12/Feb/13

Status: Open
Project: jsr358
Component/s: Independent Implementations
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   

The TCK license for JSR 336 contains the following language in the definition of Product:

"In addition, to be a Product, a Licensee product that implements a Java Environment Specification must: (a) have a principal purpose which is substantially different from a stand-alone implementation of that specification, while the value-added portion of the product operates in conjunction with the portion that implements the Java Environment Specification; (b) represent a significant functional and value enhancement over any stand-alone implementation of that specification; and (c) not be marketed as a technology which replaces or substitutes for a stand-alone implementation of that specification."

This appears to prohibit any implementation of the spec!

[Later: insert pointer to Gil Tene's presentation given at the Prague f2f meeting.]



 Comments   
Comment by ebresie [ 12/Dec/12 ]

Is this the presentation in question?

http://jcp.org/aboutJava/communityprocess/ec-public/materials/2012-09-1112/JCP_Sep2012_IndependentImplementation.pdf

Comment by gtene [ 12/Feb/13 ]

This "newer" language appears as part of the stated TCK license terms of Platform JSRs filed after Dec. 2010:

  • SE 7 under JSR 336
  • SE 8 under JSR 337
  • EE 7 under JSR 342

It should be noted that these newer TCK license terms stand in strong contrast to the license terms communicated for previous versions of the same platforms. They expand restrictions far beyond the field-of-use and commercial terms license issues of previous platform versions. At face value, the new terms basically prevent the creation and testing of a compatible implementation of the platform specifications without securing a separately negotiated license from the spec lead with terms that are unkown-at-time-of-JSR-approval.

See previous license language in older platform versions:

  • SE 6 under JSR 270
  • EE 6 under JSR 313




[JSR358-41] Flatten the current "hub and spoke" IP model Created: 13/Oct/12  Updated: 13/Oct/12

Status: Open
Project: jsr358
Component/s: Intellectual Property
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   

IBM proposes to modify the IP-flow, replacing the current "hub-and-spoke" model - whereby IP flows through the Spec Lead - with direct grants from contributors to implementers.

Insert pointer to their presentation when it's posted publicly.






[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-39] Remove confidentiality language from the JSPA Created: 01/Aug/12  Updated: 23/Aug/12

Status: Open
Project: jsr358
Component/s: 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   

Delete the definition of Confidential Information in section 1.3 and the entirety of section 9 (Confidentiality.)



 Comments   
Comment by starksm64 [ 23/Aug/12 ]

Likewise, isn't section 11. on publicity obsolete and should be deleted?

Comment by pcurran [ 23/Aug/12 ]

Yes. I don't know how I missed that





[JSR358-38] Define standard Terms of Use for participation in JSR collaboration projects Created: 31/Jul/12  Updated: 10/Apr/14

Status: Open
Project: jsr358
Component/s: Intellectual Property
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

Issue Links:
Duplicate
is duplicated by JCPNEXT4-22 Define standard Terms of Use for part... Open
Related
is related to JCPNEXT4-20 Clarify the role of individuals Closed

 Description   

Define standard Terms of Use to cover "casual" contributions made through comments on a public mailing list, suggested bug fixes, and similar collaborative means.

See presentation



 Comments   
Comment by pcurran [ 01/Aug/12 ]

Suggestions from a discussion during the July 31 Expert Group meeting.

When implemented, Spec Leads should be advised to prominently remind participants in their work that they are bound by the Terms of Use. Two ways of doing so are by a prominent notice on the project's home page and by posting periodic reminders to the public mailing list.

Comment by pcurran [ 01/Aug/12 ]

How we resolve http://java.net/jira/browse/JSR358-38 may affect this. Specifically, if we decide that we need to address the matter of employer's claims on IP contributions made by their employees in the JSPA then we should also do so in the Terms of Use.





[JSR358-37] Collaboration with other Standards-Setting Organizations Created: 06/Jul/12  Updated: 06/May/15

Status: Open
Project: jsr358
Component/s: Collaboration
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   

Other standards organizations sometimes wish to reference JCP specifications.

Where reasonable, modify the JSPA so that it does not impose obstacles to such collaboration.



 Comments   
Comment by pcurran [ 06/May/15 ]

We discussed this at the April 2015 EC meeting. From the minutes:

After a brief discussion we agreed that there is nothing today that prevents another standards organization from endorsing or normatively referencing a JSR. We also noted that JSRs can and do implement standards developed elsewhere. However, we agreed that a collaborative development of standards (where the JCP and another standards organization work together) is unlikely to be possible due to differing IPR policies.

We therefore agreed that there is probably not much to do here but to warn (as we suggest in the IP-Flow document) that we should not introduce any language into the JSPA or the Process Document that would make it difficult or impossible for another standards organization to normatively reference a JSR.

I will leave this open so that we can do a final review to make sure that we aren't doing anything to impede normative references to our JSRs.





[JSR358-35] Escrow process Created: 06/Jul/12  Updated: 06/Jul/12

Status: Open
Project: jsr358
Component/s: Intellectual Property
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   

Should IP ownership default to a neutral third-party via an escrow process if the Spec Lead abandons the JSR or if bankruptcy proceedings become stalled?

NOTE: We had difficulties several years ago when JCP member company Qisda, which was Spec Lead for several critical Java ME JSRs, went bankrupt.






[JSR358-34] End of Life for JSRs Created: 06/Jul/12  Updated: 06/May/15

Status: Open
Project: jsr358
Component/s: JSR lifecycle
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

Issue Links:
Related
is related to JSR358-9 Licensing can be withdrawn before nat... Open

 Description   

All technologies reach a natural end of life but there's no allowance for this in the JSPA.

Clarify whether the obligation to license the Spec, RI, and TCK is "perpetual" and if not, the circumstances under which the obligation expires.
-
Is the Spec Lead obliged to provide a functional TCK 20 years after Final Release?



 Comments   
Comment by pcurran [ 06/May/15 ]

We discussed this at the April 2015 EC meeting. From the minutes:

Mike Milinkovich reported that Eclipse has a similar process and that they use the term "archiving". Archived projects are no longer current or supported. Patrick asked whether the TCK for an archived JSR should be supplied. Mike suggested yes, noting that no legal agreement lasts forever.

There was general agreement that we should define some kind of archiving process. Just as the PMO regularly reviews potentially dormant JSRs they should also perform regular reviews to ask Spec Leads whether their JSRs should be archived. Any actual change of state should only be performed after several months' public notice.

John Weir asked whether an archived JSR could come back to life. Mike responded that it should always be possible to re-start an archived JSR.

We agreed to keep this topic open and to discuss it further in the Working Group.





[JSR358-33] Withdrawal of IP grants Created: 06/Jul/12  Updated: 06/Jul/12

Status: Open
Project: jsr358
Component/s: Intellectual Property
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   

Should people be permitted to withdraw their IP grants? At any time?

JSPA Section 4D Withdrawal of Contributions due to Change in Announced License Terms says Yes.

Review this language - make sure it's consistent with possibly-changed processes.






[JSR358-32] Expert Group dissolution at Final Release Created: 06/Jul/12  Updated: 20/Jul/12

Status: Open
Project: jsr358
Component/s: JSR lifecycle
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   

The current version of the JSPA states that the Expert Group must dissolve at Final Release (because we don't fully specify how IP rights flow during the Maintenance process?)

This requirement runs counter to modern software development practices and to our desire that the Spec Lead make a long-term commitment to maintain the technology.

Modify the Process Document to permit the Expert Group to take responsibility for Maintenance?



 Comments   
Comment by lightguard [ 20/Jul/12 ]

This would be helpful. We don't have to mandate that the EG stays together, but it should at least be an option.





[JSR358-31] Strengthen TCK quality requirements Created: 06/Jul/12  Updated: 12/Dec/12

Status: Open
Project: jsr358
Component/s: TCKs
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   

The Process Document contains language intended to ensure TCK quality, but this is typically not enforced.

EC members have an obligation to review TCKs for quality before voting their Final Approval, but many do not.

Should we enforce or strengthen TCK quality requirements?



 Comments   
Comment by lightguard [ 20/Jul/12 ]

How would you propose we go about doing this? Seems like a tool would be useful. Perhaps something like what was done for CDI? http://docs.jboss.org/cdi/tck/reference/1.0.1-Final/html_single/#d0e791

Comment by ebresie [ 12/Dec/12 ]

Hope this is not out of scope...

To me Quality requirement implies a requirement is implemented as expected.

TCK seems more low level "Unit Test" level as opposed to higher level "Acceptance Test" level. Acceptance testing may have some overlap with unit test but they are still slightly different.

Maybe the Spec could better spell out the Acceptance criteria requirements.

Or maybe some form of TCK (Acceptance Test Plan) Spec with Acceptance requirements defined could help. Drawback is could potentially add extra "work" to the mix, but this could potentially allow "clean implementations" to implement there own TCK relative to the TCK Spec requirements.

Comment by ebresie [ 12/Dec/12 ]

I assume this is address by other non-implementer involvement, but there may still be some bias among participants.

Should an "independent" participant not involved in the group be considered to insure quality? Maybe a Quality EG?





[JSR358-30] Create an Architecture Council? Created: 06/Jul/12  Updated: 20/Jul/12

Status: Open
Project: jsr358
Component/s: Governance
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   

Create an Architecture Council? Council would gather input from implementers, developers, and users and to provide guidance to Platform Expert Groups on platform evolution in the interests of maintaining competitiveness, compatibility and relevance.

The membership of this group should be primarily technical, and it must operate by consensus and through negotiation with the Platform Spec Leads.

Possible deliverables:

  • Yearly survey of the community
  • Written responses to Platform JSRs.


 Comments   
Comment by pcurran [ 06/Jul/12 ]

[This is a suggestion made several years ago, by Sun.]

For the record, both Bill Shannon (Java EE Spec Lead) and Mark Reinhold (Java SE Spec Lead) oppose this idea. They believe that the platform Expert Groups are the appropriate forum for these kinds of activities.

Comment by lightguard [ 20/Jul/12 ]

I think the main issue here is working with the community and getting their feedback. This was done fairly well with Java 7, at least much better than before. Whether there's an architecture council or not, communication and transparency are key here.





[JSR358-29] The role of the Reference Implementation Created: 06/Jul/12  Updated: 14/Mar/13

Status: Open
Project: jsr358
Component/s: Reference Implementation
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   

The JSPA currently conflates two roles for the RI - these should be clarified:

  • A proof-of concept implementation that is used by implementers as an aid to testing and debugging their implementation.
  • The form in which the Spec Lead licenses its implementation for the creation of derivative works.

Mandate that a binary RI must be released (the former role cannot be fulfilled without a binary.)



 Comments   
Comment by ebresie [ 12/Dec/12 ]

Suggest clarifying role of RI relative to "Clean Room" / "Non-Derivative" Implementations.

If implementation is derived from the RI then all is well with the world.
If implementation is not derived from the RI, then confusion begins.

I assume some of this may be covered by the "proof-of concept implementations" wording, but not sure if the "proof-of concept" is clean room or derivative implementation.

This may be better addressed elsewhere.

Comment by ebresie [ 12/Dec/12 ]

Suggest clarifying role of RI relative to "Usage" concerns. If Spec Lead has provided RI then makes a commercial derived work, there may be possible confusion in usage terms

This may be better addressed elsewhere.

Comment by ebresie [ 12/Dec/12 ]

Suggest clarifying role of RI relative to relationship between RI and RI's TCK.

This may be addressed elsewhere.

Comment by ebresie [ 12/Dec/12 ]

Suggest clarifying difference between RI Source and RI Binary.

This may relate to "binary RI" mentioned in the description and the "Usage" comment mentioned previously.





[JSR358-26] Keep or eliminate the obligation to license Essential Patents on FRAND terms for JSRs in which you do not participate Created: 06/Jul/12  Updated: 01/Apr/15

Status: Open
Project: jsr358
Component/s: Intellectual Property
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 6 of the JSPA (Special Patent Considerations) requires that all JCP members, even those who do not participate in the development of a JSR, grant essential patent rights to all licensees of that JSR.

This provision may be a barrier to corporate participation.

Could it even be enforced against individuals or their employers?

Should we keep it, or can we drop it?

Note: our current processes with regard to individuals (Exhibit B) mean that these broad grants are not made by individuals or their employers (Exhibit B refers to a specific JSR only.)



 Comments   
Comment by pcurran [ 01/Aug/12 ]

For what it's worth (not much!) my interpretation of this as a non-lawyer is:

  • This section makes extremely broad IP grants to the Spec Lead (you are obliged to license your "essential patents" for any JSR - even one that you had no involvement in, and maybe didn't even know existed.)
  • We currently do not require equally broad grants from individuals as opposed to organizations (Exhibit B references only a specific JSR.)
  • I have doubts whether it would actually be enforceable in a court of law, particularly against individuals or their employers.
  • To my knowledge this has never been invoked in the history of the JCP.
  • It could be an obstacle to corporate involvement in the JCP (Apple resigned several years ago because of this section of the JSPA.)
  • If we don't eliminate this section then it will be effectively impossible to create a significantly simpler subset of the JSPA for members who do not wish to serve as a Spec Lead (something we would very much like to do.)
Comment by john_rizzo [ 01/Aug/12 ]

We are voting no for now due to two reasons first it gives Oracle special considerations (in the last subsection). Second is the use of the term FRAND which we have all agreed is problematic due to it widely varied definitions. It is vague at best, at worst it can be situationally defined. I am seeking suggested changes.

Comment by ddeutsch [ 01/Aug/12 ]

Oracle supports removal of the requirement that JCP members not engaged in an expert group must commit their essential technology but believes futher discussion is needed to consider everything specified in section 6. In particular, we want to ensure that the JSPA specifies the commitments required of expert group participants for claims on technology that they did not contribute. Unless this is addressed elsewhere in the JSPA, simply deleting section 6 may not be appropriate. A "Term Sheet" should be agreed specifying patent commitments for at least the following situations:

  • Spec Lead
  • Member of expert group
    • their contributions
    • contributions of others
  • members of the JCP not in the expert group
Comment by pcurran [ 01/Aug/12 ]

(In response to Don's comment...)

Agreed. It's too simplistic to say we should just delete this section. There's other stuff in it (for example, it explains your rights to withhold a patent grant under certain circumstances.

We really need to take a comprehensive look at the whole IP-flow/IP-grant matter, understand what the current document says, and decide whether this is what we want it to say.

Comment by mmilinkov [ 13/Aug/12 ]

My concern is that deleting this section may actually cause more harm than good. As I read the JSPA, if Section 6 is deleted, then there is no obligation for any patent license grant. My preference would be to replace "FRAND" with "royalty free", which would certainly go a long way to helping enable open source implementations.

Comment by pcurran [ 23/Aug/12 ]

In response to comments here and discussion within the EG we narrowed this question down to:

Section 6 of the JSPA obliges members to license Essential Patents (unless they proactively opt out of doing so) even for JSRs with which they have no involvement. Should we limit this obligation to those who are members of the Expert Group?

The overwhelming response to a doodle poll on this question was that we need further discussion.

For the record, I will post comments made on that poll to this thread.

Comment by pcurran [ 23/Aug/12 ]

Gil Tene said in a comment on the doodle poll:

I think that this item should be discussed in the context of overall patent grant obligations, as well as reciprocity requirements. Specifically, section 6 is currently linked to from section 5.C.1, and losing that could be an issue in the overall IP picture.
We need to discuss what will be left at the end - e.g. I believe that at the very least, we need spec IP rights to be able to be licensed under terms that require non-assertion against compatible implementations of the spec...

Comment by pcurran [ 23/Aug/12 ]

Mike Milinkovich said in a comment on the doodle poll:

I would like to suggest a royalty-free patent licensing model as a potential solution to this. Both the Apache and Eclipse open source licenses have a very similar model that lays out the requirements that any patents which read on contributions must be licensed royalty-free. This model has seemingly worked very well for those communities, and I would be interested in exploring any shortcomings the model may have in the JCP context.

Comment by pcurran [ 23/Aug/12 ]

Steve Wolfe said in a comment on the doodle poll:

We are open to considering all aspects of the IP flows in the JSPA, but need to do so in the context of the complete IP picture. Having said that, we believe one of the JCP's key objectives should be making the Java ecosystem and our customers confident that Java is a safe place to invest, and to achieve that, we believe JCP members should support a model where Java investments are not at risk from unpredictable IP claims.

Comment by pcurran [ 23/Aug/12 ]

I should have read Mike Milinkovich's comment more closely when I pasted it! He said:

"I would like to suggest a royalty-free patent licensing model as a potential solution to this. Both the Apache and Eclipse open source licenses have a very similar model that lays out the requirements that any patents which read on contributions must be licensed royalty-free. This model has seemingly worked very well for those communities, and I would be interested in exploring any shortcomings the model may have in the JCP context."

This is exactly what we have today for contributions. The question is about patent rights with respect to stuff that you do not contribute (but without which someone else's JSR cannot be implemented.) Note that the Spec Lead (for everything, whether or not formally contributed) and Expert Group members (for contributions) are already obligated to license royalty-free.

The RAND obligation really is a corner case, and only covers contributions made by others and which result in the inability to implement a JSR without violating your patent. I'd be interested to know how often money changes hands in practice as a consequence of this requirement.

Comment by pcurran [ 01/Apr/15 ]

What's in question is not the elimination of Section 6 in its entirety, but rather the elimination of the obligation to license Essential Patents on FRAND terms for JSRs in which you do not participate. I will reword the issue accordingly.





[JSR358-25] Mandate non-assert Patent Covenants? Created: 06/Jul/12  Updated: 01/Apr/15

Status: Open
Project: jsr358
Component/s: Intellectual Property
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 306 included language mandating non-assertion patent policies.

Do we still wish to pursue this?



 Comments   
Comment by starksm64 [ 31/Jul/12 ]

Red Hat does not support replacement of the patent license grants in the existing JSPA with nonassert covenants.

Comment by pcurran [ 24/Feb/15 ]

Mike Milinkovich noted on the EG mailing list:

IANAL, but I think that one difference between non-assertion and royalty-free is that if we go non-assertion, the patent retaliation approach that we had previously discussed would no longer work. If royalty-free patent licenses are granted, you have something to revoke if someone sues for patent infringement. However, I personally have yet to see language that provides the equivalent if you use non-assertion.

This may not be a big deal, but I just wanted to make sure that we all understand that if we go non-assertion, then we may be losing the ability to use the termination of patent licenses as a defense against litigation.

Comment by pcurran [ 26/Feb/15 ]

Anish Karmarkar has pointed us to three IPR policies that combine non-assertion with defensive termination:





[JSR358-23] Remove from the JSPA any barriers to full compliance with JCP 2.8's transparency requirements Created: 06/Jul/12  Updated: 06/Mar/15

Status: Open
Project: jsr358
Component/s: 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 the JSPA does not inhibit or conflict with these requirements, for example by permitting or mandating confidentiality.






[JSR358-22] Clarify Compatibility policy Created: 06/Jul/12  Updated: 01/Apr/15

Status: Open
Project: jsr358
Component/s: Compatibility
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   

Sun/Oracle have consistently insisted on strong compatibility requirements that prohibit incompatible implementations.

Others argue that incompatible implementations are permissible so long as these do not use the Java name.

Ensure that the JSPA defines a clear policy on compatibility and that this is addressed in any recommended or required licenses.

Should we continue to insist that compatibility is binary, or should we permit incompatible implementations under some circumstances? (E.g. the Transplant JSR proposal from JSR 306.)






[JSR358-21] Clarify whether Field of Use restrictions are permissible Created: 06/Jul/12  Updated: 06/Jul/12

Status: Open
Project: jsr358
Component/s: Independent Implementations
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   

The JSPA explicitly grants the right to create Independent Implementations (not derived from the RI.)

Many believe that the Field Of Use language in the SE7 TCK license restricted this right by preventing Apache from releasing their implementation of Java SE.

The JSPA should be modified to clarify whether Field of Use restrictions are permitted.

If FOU restrictions are not prohibited they should be permitted to all.






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





[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-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-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-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-7] Changes to Terms of Use associated with collaboration tools Created: 21/Sep/11  Updated: 02/Apr/15

Status: Open
Project: jsr358
Component/s: None
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

205-207 - are contradictory. 205 requires Terms of Use to be provided so that "prospective EG members can judge whether they are compatible with the JSPA" but 207 allows the EG to change its collaboration tools after the EC begins. An EC member who believes the new tools' Terms of Use are not compatible with the JSPA has no recourse - after the IP cow is out of the barn - if they are in a minority (in fact no rules are provided for deciding how an EG can switch tools. Without rules the spec lead could do this dictatorially.

PC> What are you suggesting? That EGs must be locked into their original choice of collaboration tools - and that moreover the terms of use for these tools must be cast in stone - for the possibly multiple-year lifetime of the JSR? This isn't reasonable. Please make a specific suggestion in a separate issue.

SS> Suggest adding clause requiring unanimous vote of EC and past/present EG members to approve changes in licenses.



 Comments   
Comment by pcurran [ 22/Sep/11 ]

As with http://java.net/jira/browse/JSR348-137 it's too late to resolve this. I've marked it Deferred.

Comment by pcurran [ 02/Apr/15 ]

This is not about licenses (as JSR358-8 was), but instead refers to the terms of use associated with the tools used to collaboratively develop the RI. Tools change over time. Requiring votes before adopting a new tool is unreasonable.

We will need to define some processes to ensure that the collaborative development is happening "appropriately". Terms of Use and the choice of tools/platform can be addressed there.

Comment by pcurran [ 02/Apr/15 ]

Following up on my last comment, the wording of this issue is extremely misleading (referring to "license" rather than "terms of use". I will re-word it.





[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-28] Fee structure changes Created: 06/Jul/12  Updated: 01/Apr/15

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

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

Issue Links:
Duplicate
duplicates JCPNEXT4-21 Fee structure changes Closed
is duplicated by JCPNEXT4-21 Fee structure changes Closed

 Description   

Since membership fees are defined in the JSPA, if we wish to change them this is our opportunity.

Although our fees are low compared to other standards organizations we get significant resistance to paying them.

Some commercial organizations avoid paying fees by encouraging their employees to join as individuals.

Possible changes:

  • A lower rate for small commercial entities.
  • Lowering or eliminating the fees for non-profits.

Whatever we do, we should move the fee-structure language from the JSPA to the Process Document so we can more easily fine-tune it in the future.



 Comments   
Comment by pcurran [ 01/Apr/15 ]

JSR 364 will publicly commit to "no fees". Therefore we should simply remove any mention of fees from the JSPA.





[JSR358-18] Definition of "Profile Specification" is unclear Created: 27/Apr/12  Updated: 06/Jul/12

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

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


 Description   

I have read the definition of a "Profile Specification" (Line 146) several times and I see it is some kind of aggregation spec, but I can't quite concretize the intent.

Can we include an example of each of the 2 kinds (1." Zero" and 2. "Or more" other JSR inclusions.) I think that would help clarify the point?



 Comments   
Comment by pcurran [ 06/Jul/12 ]

Out of scope for JSR 355. I'll move this issue over to JSR 358 and we'll deal with it there.





[JSR358-13] Oracle should encourage other Spec Leads of in-flight JSRs to join them in voluntarily adopting the new Process once the JSR is finalized Created: 01/Jul/11  Updated: 08/Apr/15

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

Type: Bug Priority: Minor
Reporter: pcurran Assignee: pcurran
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by JCPNEXT4-15 Oracle should encourage other Spec Le... Open

 Comments   
Comment by weirj [ 06/Jul/11 ]

I believe it would be good to do this at the earliest possible opportunity, and embrace the mantra of a more active and involved process. Asking the Spec leads of the inflight JSR's if they would have any objections in principle to moving to the new process once it is defined, may tease out any unlerlying concerns or issues that people may have for the WG to discuss

Comment by pcurran [ 20/Jul/11 ]

Just FYI, I'm working this within Oracle, and we do hope to be able to make a public statement relatively soon.

Comment by pcurran [ 06/Jul/12 ]

This is still in progress. The PMO is actively encouraging all in-flight JSRs to upgrade to 2.8 when they submit a new draft or a Maintenance proposal. As for Oracle's JSRs, some have already converted and others will soon.

I'll keep this issue open until it's clear that we're done (or almost done.)

Even though this is not strictly-speaking a JSR 358 issue, I'm moving it over to that project so it won't get lost here. (Otherwise it would be the only remaining open issue for this now-completed project.)





[JSR358-4] The JSPA contains definitions - verify that Process Doc definitions do not conflict Created: 17/Aug/11  Updated: 10/Apr/14

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

Type: Bug Priority: Minor
Reporter: pcurran Assignee: pcurran
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-10 Verify that Process Doc definitions d... Resolved
Related
is related to JSR348-153 Licensor Name Space is not formally d... Closed
Tags: jsr364

 Description   

The summary says it all. Since we're not modifying the JSPA in this JSR we must be careful not to introduce definitions that conflict with the equivalent definitions in the JSPA.

We need to conduct a review to verify this.



 Comments   
Comment by pcurran [ 14/Sep/11 ]

Not practical, nor particularly valuable...

Comment by pcurran [ 01/Oct/11 ]

Rather than copying definitions from the JSPA to the Process Document, maybe we should say "the definitions in version x.y of the JSPA apply here."

Version x.y would be the version in effect when the Process Doc was finalized. Presumably there would never be a later version of the JSPA without a corresponding revision to the Process Doc?

Comment by pcurran [ 01/Oct/11 ]

I'll review the existing definions to make sure they don't conflict. However, I'm keeping this open (by deferring it) so we can address the broader issue in the future.

Comment by lightguard [ 06/Jul/12 ]

I think it makes sense to reference the definitions in the JSPA document which corresponds to the Process Document. There may be times we need to update them, but is that really much of an issue and push out a new Process Document point version updating the link between the two documents?





Generated at Tue Jun 02 22:29:06 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.