On their face, the gitlab appsec ci templates are [[ https://gitlab.wikimedia.org/repos/security/gitlab-ci-security-templates/-/tree/main | just a collection of yaml include files ]] that control security-related tests within a given pipeline. Each template allows for the specification of a wikimedia docker image and then a specific security tool, e.g. [[ https://gitlab.wikimedia.org/repos/security/gitlab-ci-security-templates/-/blob/main/npm-audit/npm-audit-nodejs-ci.yml | audit-ci ]]. This repo of yaml include files is planned to be licensed under the Apache 2.0 license. For the most part, all of the security tools we've been using within these yaml files are FOSS with [[ https://opensource.org/licenses | OSI ]]-compliant licenses. But there is a bit of a grey area for python's safety-db (as used by the MIT-licensed safety cli) which is licensed under [[ https://github.com/pyupio/safety-db/blob/master/LICENSE.txt | CC-BY-NC 4.0 ]], none of the CC licenses being OSI-compliant as they aren't really targeted towards code. And some of the semgrep rules we'd like to use are apparently licensed under an OSI-non-compliant [[ https://github.com/returntocorp/semgrep-rules/blob/develop/LICENSE | Commons Clause license ]]. **Is this a potential problem?** The yaml files aren't a traditional piece of software, per se, and we aren't bundling the security tools with the code, as one might with various packages and dependencies for more traditional applications. But these yaml include files //heavily imply// a required usage of gitlab, wikimedia docker images and the //installation and running// of various security tools, in the opinionated way that they are written. **Would this imply a need for compliance in the licensing chain similar to a more traditional application? If an opportunity presented itself to, say, purchase commercial SAST/DAST software to be run within wikimedia CI, would that be a non-starter as things currently stand?**