David's assertion that "non final specifications don't have Compatible Implementations" is correct by definition. That is, the EFSP defines a Compatible Implementation as "Any implementation that fulfills all requirements of a Final Specification as demonstrated by fulfilling all requirements of the associated TCK."
Patent grants flow out of a specification through the final specification. The patent license grant describes the timing of the patent grant. All Jakarta EE projects use the Compatible Patent License (you can see this on the "Governance" page in the PMI, e.g.
Jakarta Authentication) which unleashes the patent grant when an implementation becomes a Compatible Implementation (that is, when it passes the TCK of the ratified Final Specification).
Reviews manage the flow of patent rights into the specification. Patent rights flow through the committers into the specification and are "locked in" at the time a review is declared successful. The "lock in" is based on who holds committer status at the time of the review. That is, grants flow in for the patents associated with those individuals who hold committer status at the time of the review.
Theoretically, a member could get their committers to retire before a review and any grants for that member's patents associated with content added since the last successful review would not flow into the specification. Based on this, one might think that it makes sense to do as many reviews as you possibly can. Yes, there is something "legally positive that happens as the result of Progress Reviews", but we all have other things to do and can't be doing reviews all the time.
There are two reasons to do a progress review.
First, we want to make sure that the specification work is progressing, that it is progressing in manner that aligns with the approved plan, and that it is progressing in manner that will likely result in a successful release review and ratification.
Second, we want to make sure that the natural ebb and flow of committers joining and leaving the project, changing employers, etc. doesn't negatively impact the flow of patent grants.
Over a long enough period of time, both of these reasons are increasingly likely to become a problem. When we wrote the process, we decided that one year was a reasonable maximum amount of time for a specification project to run without checking in.
So, if there is reason to believe that specification work is going off on a tangent, there is some risk that committer status changes will impact the flow of patent grants, or there is some other cause for concern, the specification committee can compel a specification project to engage in a progress review. Per the EFSP, " The Specification Committee may, at their discretion, demand that the project team engage in additional Progress Reviews." If the specification committee decides that additional reviews are required for any reason, they can compel them on an ad hoc basis (the specification committee should use these powers judiciously).
IMHO, publishing a milestone (beta, alpha, nightly, ...) build does not in itself require a review. Note that milestone (beta, alpha, nightly, ...) builds must be intended for "limited distribution to demonstrate progress and solicit feedback." It must be very clear to anybody who might stumble upon milestone builds that they are not intended for general consumption, and--in particular--do not convey any patent grants. It seems natural to me that the specification page for an in-progress specification version will be updated from time-to-time.
Does that make sense?
Wayne