[JSR358-9] Licensing can be withdrawn before natural expiration of copyrights/patents Created: 21/Sep/11 Updated: 02/Apr/15
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
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.