### Objective Do research to come up with a proposal, and reasoning, for if we should replace License Finder with another OSS tool, or write it ourselves into gemnasium. ### Required features Languages and package managers - Support [languages and package managers](https://docs.gitlab.com/ee/user/compliance/license_compliance/index.html#supported-languages-and-package-managers) that are currently supported. - Can ingest some kind of SBoM or package list, and find the corresponding licenses. Licenses - Support licenses that are currently supported (SPDX licenses). - Produce SPDX identifiers for licenses. (https://spdx.org/ids) Package registries, offline support - Support private registries. Support might be limited to specific authentication methods and connection protocols. - Support running offline (air-gap), which mean that the tool can either: - Provide an offline lookup for licenses by package type, name, and version. - Connect to a local registry which mirrors public registries that can't be accessed directly. - Can fallback to querying the package manager CLI to lookup license info. (This does not apply to air-gap mode.) See [discovery issue](https://gitlab.com/gitlab-org/gitlab/issues/33727) on offline (air-gapped) support. ### Bonus features - Support package managers that are currently supported by GitLab Dependency Scanning. - Can toggle between declared license (from package registry or manifest) and found license (from license file), or provide both. - Can handle complex multi-licenses (and/or) using SPDX License expressions. Can it handle - https://gitlab.com/gitlab-org/gitlab/-/issues/280519? The following features are required, but can be implemented in a post-processor: - When the SPDX identifier is unknown, can resolve the license text to an SPDX license using the [License List Data](https://github.com/spdx/license-list-data) catalogue. - Allows for human contribution to correct errors in the catalogue. (catalogue efficacy) ### Technical requirements - Has limited dependencies. - It takes a limited time to run the tool and its dependencies. Max: 5 minutes. - If the tool and its dependencies are bundled in a Docker image, that image isn't too big. Max: 600 MB. ### FOSS Consideration For each new scanner we need to check (criteria): - Does it currently support commercial reuse? - Does it scan one level deep or deeper? - How well is the project maintained? - How responsive to bugs is the project? - Any user reviews that are red flags found easily online? ### Integration and extensibility - Provides a confidence score so that we understand how reliable the detected license is. - Provides extension points so that we can override and extend the solution. - Provides a minimal report or output that is easy for us to alter or modify as our report needs evolve. - Can accommodate languages/tools that do not have a straight forward lockfile format. Investigate the integration, from technical standpoint. We don't need working POC, but need to check whether it's reasonable. ### Examples Ideas: - https://www.fossology.org/features/ - https://github.com/oss-review-toolkit/ort - https://github.com/todogroup/awesome-oss-mgmt#licensing ### Outcome Recommendations should include: - Write ourselves? or FOSS - if FOSS which one - Next steps (more research? other?) so you can work with Product to make an estimated timeline, epics, and issues.