Thursday 31 October 2013, 1:00-2:00 pm PDT
Role of RI
The direction we're taking - mandating an open-source RI - should resolve most of these concerns. We should mandate that a binary be released. We should also specify the sources from which the binary RI was built, so that implementers can build for their own platform from the exact set of sources used to build the binary RI.
Sources for the RI will be available but what about the TCKs? It could be very difficult legally for us to try to define a process to deal with what would be considered potentially valuable assets in a bankruptcy proceeding, particularly world-wide. More trouble than it's worth? Should we simply ask the Spec Lead company what their escrow process is? The EC could take this into consideration when voting.
End of life
Maybe not be worth worrying about. In rare cases a Spec Lead may be asked to provide a TCK for a very old JSR. Hopefully their internal engineering processes will enable them to do so. If not - deal with the consequences...
Can we distinguish between a JSR that is considered "complete" and one which is expected to evolve? In the latter case why would we not want the EG to stay alive? In the most significant cases a new JSR will be filed and a new (reconstituted) EG, but what about Maintenance Releases?
At Final Release the Spec Lead (EG) could make a statement as to whether or not they expect to continue to work on Maintenance Releases (and possibly new JSRs to evolve it). Is there a reason why we should not permit an EG to continue under these circumstances? (Ask Legal for feedback.)
Patrick will incorporate the results of our discussions into the Issue Tracker.