License Compliance analyses your application to track which licenses are used by third-party components, like libraries and external dependencies, and check that they are compatible with the licensing model.
Licenses can be incompatible with the chosen license model for the application, for example because of their redistribution rights.
Our goal is to provide License Compliance as part of the standard development process. This means that License Compliance is executed every time a new commit is pushed to a branch. We also include License Compliance as part of Auto DevOps.
Maintainers can define the set of approved and blacklisted licenses for their application, so developers can validate their changes against the existing policy.
License Compliance results can be consumed in the merge request, where only users can see which new license is introduced by the new code, and which are the libraries that are licensed in that way. A full report is available in the pipeline details page.
Licenses should also be included in a bill of materials (BOM), where all the components are listed with their licenses. See this issue for additional details.
License policies are often shared between multiple projects in the same group/organization. That's why it is important to share the allowed/blacklisted policies for all the projects in the same group.
The next MVC is to implement group-level license compliance.
The License Compliance topic is often coupled with Dependency Scanning in Software Composition Analysis (SCA). This is what analysts evaluate, and how it is bundled in other products. As defined in our Solutions, GitLab includes Container Scanning as part of Software Composition Analysis.
We should make sure that we can address the entire solution even if we consider these features as independent, and to leverage the single application nature of GitLab to provide a consistent experience in all of them.
