Engineering & UX Discovery: Disallow merge if a blacklisted license is found

Problem to solve

As a user, I expect that if there is a blacklisted license in my code merge will be disabled. This is currently not happening. While unknown licenses are still to be discussed, blacklisted ones should not be there.

Further details

In security features we don't block the merge for security vulnerabilities, because the user should be responsible to evaluate if the impact is blocking the process or not. Impact should be an evaluation based on many different factors, and should not be automated but suggested giving all the possible details to the user in charge for the final call.

In License Management, there is no evaluation. If a license is forbidden, is forbidden. This is something more similar to the test job instead of the security jobs.

Proposal

https://gitlab.com/gitlab-org/gitlab-ee/issues/6924#note_193704556 and implementation issue: https://gitlab.com/gitlab-org/gitlab-ee/issues/13067

Past proposal

Check if the list of new licenses introduced in a specific MR is matching one of the blacklisted licenses for the project, and disallow the merge in that case if the option is turned on. This is similar to what happens when the pipeline is not green, or approval is required, or discussions are still open.

Here is an example of what it could look like:

We need to add an option to enforce this behavior in Settings > General > Merge Request, similar to the existing ones:

Only allow merge requests to be merged if the pipeline succeeds
Only allow merge requests to be merged if all discussions are resolved

Only allow merge requests to be merged if no blacklisted license is introduced

How to manage a feature branch where some test is in place and that requires a blacklisted license? Maybe disabling license management for that branch is enough.

What does success look like, and how can we measure that?

Users enable license management in their projects.