The PMC may push back on a CQ if the license is obviously a no-go.
However, the PMC is not expected to have expertise in licensing
matters and if there is any doubt, should just punt to the IP Team.
If there is an obvious license no-go, then perhaps the CQ filing screen could alert the submitter that they shouldn't bother if the license is XYZ?
That is, of course, assuming that a CQ has technical merit.
I'm confused on this... should the PMC be inquiring as to why a project depends on something (technically for what purpose)? I trust project committers, particularly with peer review, to not add dependencies that are of no purpose. Furthermore there is a hurdle to adding dependencies with the CQ process so adding a dependency will be avoided if the dependency won't add value.
Also, I will try and encourage a project to use a more recent
version of a library when a more recent version has already been
approved by the IP Team.
The CQ filing process already brings to one's attention other CQs for other versions. (I think you were involved in that feature; thank you). Is that not enough? Perhaps the filing screen could further explicitly encourage the submitter to simply use a pre-approved version if it's compatible.
As a separate matter; it'd be nice if it was easier to get approval for a new version of something. I'd hope for that to be a fast-tracked thing assuming no license changed.
~ David
