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






Generated at Tue Jul 26 22:14:47 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.