GitLab checks the License Compliance report, compares the licenses between the
source and target branches, and shows the information right on the merge request.
Denied licenses will be clearly visible with an x red icon next to them
as well as new licenses which need a decision from you. In addition, you can
manually allow or deny
licenses in your project's settings.

NOTE: Note:
If the license compliance report doesn't have anything to compare to, no information
will be displayed in the merge request area. That is the case when you add the
license_scanning job in your .gitlab-ci.yml for the first time.
Consecutive merge requests will have something to compare to and the license
compliance report will be shown properly.

If you are a project or group Maintainer, you can click on a license to be given
the choice to allow it or deny it.

When GitLab detects a Denied license, you can view it in the license list.

Use cases

It helps you find what licenses your project uses in its dependencies, and decide for each of then
whether to allow it or forbid it. For example, your application is using an external (open source)
library whose license is incompatible with yours.

The included template will create a license_scanning job in your CI/CD pipeline
and scan your dependencies to find their licenses.

NOTE: Note:
Before GitLab 12.8, the license_scanning job was named license_management.
GitLab 13.0 removes the license_management job,
so you're advised to migrate to the license_scanning job and used the new
License-Scanning.gitlab-ci.yml template.

Additional arguments for the gradle executable. If not supplied, defaults to --exclude-task=test.

LICENSE_FINDER_CLI_OPTS

no

Additional arguments for the license_finder executable. For example, if your project has both Golang and Ruby code stored in different directories and you want to only scan the Ruby code, you can update your .gitlab-ci-yml template to specify which project directories to scan, like LICENSE_FINDER_CLI_OPTS: '--debug --aggregate-paths=. ruby'.

LM_JAVA_VERSION

no

Version of Java. If set to 11, Maven and Gradle use Java 11 instead of Java 8.

LM_PYTHON_VERSION

no

Version of Python. If set to 3, dependencies are installed using Python 3 instead of Python 2.7.

MAVEN_CLI_OPTS

no

Additional arguments for the mvn executable. If not supplied, defaults to -DskipTests.

PIP_INDEX_URL

no

Base URL of Python Package Index (default: https://pypi.org/simple/).

SETUP_CMD

no

Custom setup for the dependency installation (experimental).

Installing custom dependencies

The license_management image already embeds many auto-detection scripts, languages,
and packages. Nevertheless, it's almost impossible to cover all cases for all projects.
That's why sometimes it's necessary to install extra packages, or to have extra steps
in the project automated setup, like the download and installation of a certificate.
For that, a LICENSE_MANAGEMENT_SETUP_CMD environment variable can be passed to the container,
with the required commands to run before the license detection.

If present, this variable will override the setup step necessary to install all the packages
of your application (e.g.: for a project with a Gemfile, the setup step could be
bundle install).

In this example, my-custom-install-script.sh is a shell script at the root
directory of your project.

Overriding the template

CAUTION: Deprecation:
Beginning in GitLab 13.0, the use of only and except
is no longer supported. When overriding the template, you must use rules instead.

If you want to override the job definition (for example, change properties like
variables or dependencies), you need to declare a license_scanning job
after the template inclusion and specify any additional keys under it. For example:

Configuring Maven projects

The License Compliance tool provides a MAVEN_CLI_OPTS environment variable which can hold
the command line arguments to pass to the mvn install command which is executed under the hood.
Feel free to use it for the customization of Maven execution. For example:

mvn install runs through all of the build life cycle
stages prior to install, including test. Running unit tests is not directly
necessary for the license scanning purposes and consumes time, so it's skipped
by having the default value of MAVEN_CLI_OPTS as -DskipTests. If you want
to supply custom MAVEN_CLI_OPTS and skip tests at the same time, don't forget
to explicitly add -DskipTests to your options.
If you still need to run tests during mvn install, add -DskipTests=false to
MAVEN_CLI_OPTS.

Using private Maven repos

If you have a private Maven repository which requires login credentials,
you can use the MAVEN_CLI_OPTS environment variable.

Configuring Yarn projects

Using private Yarn registries

If you have a private Yarn registry you can use the
npmRegistryServer
setting to specify its location.

For example:

npmRegistryServer: "https://npm.example.com"

Custom root certificates for Yarn

You can supply a custom root certificate to complete TLS verification by using the
ADDITIONAL_CA_CERT_BUNDLEenvironment variable.

Migration from license_management to license_scanning

In GitLab 12.8 a new name for license_management job was introduced. This change was made to improve clarity around the purpose of the scan, which is to scan and collect the types of licenses present in a projects dependencies.
GitLab 13.0 drops support for license_management.
If you're using a custom setup for License Compliance, you're required
to update your CI config accordingly:

Change the CI template to License-Scanning.gitlab-ci.yml.

Change the job name to license_scanning (if you mention it in .gitlab-ci.yml).

Change the artifact name to license_scanning, and the file name to gl-license-scanning-report.json (if you mention it in .gitlab-ci.yml).

If you encounter this error, follow the instructions described in this section.

Running License Compliance in an offline environment

For self-managed GitLab instances in an environment with limited, restricted, or intermittent access
to external resources through the internet, some adjustments are required for the License Compliance job to
successfully run. For more information, see Offline environments.

NOTE: Note:
GitLab Runner has a default pull policy of always,
meaning the Runner tries to pull Docker images from the GitLab container registry even if a local
copy is available. GitLab Runner's pull_policy can be set to if-not-present
in an offline environment if you prefer using only locally available Docker images. However, we
recommend keeping the pull policy setting to always if not in an offline environment, as this
enables the use of updated scanners in your CI/CD pipelines.

The process for importing Docker images into a local offline Docker registry depends on
your network security policy. Please consult your IT staff to find an accepted and approved
process by which external resources can be imported or temporarily accessed. Note that these scanners are updated periodically
with new definitions, so consider if you are able to make periodic updates yourself.