[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:
is related to JSR358-9 Licensing can be withdrawn before nat... Open


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?

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.

Generated at Fri Apr 29 17:58:22 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.