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