[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:
is related to JSR358-34 End of Life for JSRs Open


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.

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.

Generated at Sat Oct 01 22:26:57 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.