License Management 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 Management as part of the standard development process. This means that License Management is executed every time a new commit is pushed to a branch. We also include License Management 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 Management 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 management.
The License Management 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.
We should make sure that we can address the entire category even if we consider these two features as independent, and to leverage the single application nature of GitLab to provide a consistent experience in both of them.