Service releases of previously approved major and minor releases of third party content do not require a CQ.
The actual change for those of us who have been around a while is that piggyback CQs are no longer required. If the content has been "approved" or "license_certified" previously for anybody, then your project can use it without requiring a new CQ. This is not true for "work with" CQ. Note also that there are some rare cases where an approval has limitations. There are, for example, some CQs that approve the use of content for one specific project (this usually follows a board resolution that permits it).
This is all "complicated" by the introduction of ClearlyDefined as a trusted source of license information. Check with IPZilla first, and then ClearlyDefined (there are some cases where we don't agree with the ClearlyDefined data). Notwithstanding that, when the conditions are met for content in ClearlyDefined, no CQ is required. If you're not sure whether or not you need a CQ, open a CQ and we'll sort it out.
Of course, check-this-then-check-this-then-check-this is all just plain hard. This is why we created the
Dash License Tool, which by all accounts seems to do a pretty good job of sorting it out. Note that it does account for service releases.
You might find this next bit interesting...
Several streams of work have come together and I think that we may be able to automate most the process of vetting third party content!
The
experimental-reviews branch provides "review request" functionality that creates review requests for content that is identified as "needs review". The current implementation uses APIs to create an issue against a GitLab repository for each identified library (being relatively careful to avoid duplicates). It's still very experimental. The repository is currently private, so you can't experiment today; we're going to change that next week. To use this feature, you need to get an authentication token from GitLab; you provide the token to the tool and magic just happens. It uses standard GitLab APIs (which is where my early comment about being "relatively careful to avoid duplicates" comes in).
I'm hoping to merge this into the master branch shortly (maybe as early as this weekend). My strong preference is that you will run this from the command line after you've identified that something needs review (please don't use this new feature from CI; give me and the IP Team some time to sort out how the IP Team's process changes before we get inundated).
You may have noticed that I stopped using the term "CQ" when I started talking about this feature. I'm hopeful that we're going to be able to move at least third party reviews entirely off of IPzilla in the relative short term, and we might as well use this opportunity to change the way that we talk about them.
FYI, the tool is also available as a Maven plug-in now. I'm in the process of adding it to
repo.eclipse.org. At this point, I'm trying to figure out how to do it myself as a means of testing the documentation. If it takes me more than a few days to make it work, I'll ask Fred for help.
With regard to the suggestion that we lower the ClearlyDefined score threshold... we probably will do that. Frankly, the score is actually not the most useful part of the information that we get from ClearlyDefined anyway.
Wayne
