This is why several German automotive OSPOs are working together to build OSS Review Toolkit (ORT) - it kinda glues various open source tools like ScanCode but adds features like the ability to manually correct findings and a policy as code to do risk management at scale/speed. Full disclosure I one ORT maintainers.
If people have questions on SBOMs, comparing SCA/SBOM tools or ORT - feel free to reach out to me https://github.com/tsteenbe/
ORT plug below ;-)
ORT is much more than a SBOM generator though, it's a cli/library that enables you to safely use, integrate, modify and redistribute third party software including FOSS.
You can use ORT to:
1. Generate CycloneDX or SPDX SBOMs for your software project
2. Automate your FOSS policy using Policy as Code to do licensing, security vulnerabilities and engineering standards checks for your software project and its dependencies
3. Correct found invalid or missing package metadata (licensing, source location, etc.) and license findings in the sources of your software project and its dependencies
4. Overwrite scanner license findings in the sources of your software project and its dependencies
5. Mark files, directories or or package manager scopes as not included in your software project or dependency released artifacts - use it to make clear that license findings in build scripts, documentation or tests in a package sources do not apply to the release (binary) artifact
6. Create a source code archive for your software project, including its dependencies to comply with certain license or have your own copy as nothing on the internet is forever
ORT is being built by Open Source Program Offices from Bosch, EPAM, HERE and others for several years who got frustrated with the state of SCA/SBOM tools not being able to support license compliance properly and the 30+ build tools you can find in a lot of large organizations.
Thanks for this link to another project that I'd prefer.
Just a small nitpick though, both are "open source" but only one of them is "free". I know that's what you meant but wanted to point it out. Some open source software that most people like (ex. Sentry) is BSL so it's not an uncommon license.
BSL is open source software but you cannot "free"ly use it (to make money) -- GPL v2 is free software.
As someone working in the field of license compliance (leading an Open Source Program Office) and dealing with the licensing of tens of thousands of OSS dependencies on a daily basis for a large company I can tell you that license scanning / compliance is anything but a doddle. I do a lot of public speaking on this topic for a summary of the issues I recommend you to have a look at https://static.sched.com/hosted_files/ocs19/c7/OSS-Review-To...
Most modern package managers do offer project maintainers a way to declare the license for a project. However I can tell you that often the declared license does not match the licenses detected in the source code. What counts is the license stated in the source code files not what it's in the gemspec, package.json, pom.xml etc.
This is quite common issue especially for older or larger OSS projects where various contributors have added new code over time that may be licensed under an OSS license that is compatible but not the same as the main license of the projects (Think adding BSD-2-Clause in Apache-2.0 project) What happens is that this contributions get accepted but the project maintainers do not to update the declared license.
Not saying declaring a licensing in a .gemspec file is useless but just recommend you to take it as an indicator of the main license of the project - the project may include source code that licensed under a different license.
Lack of clarity around licenses and security vulnerabilities is a big issue within the OSS community especially as lack of clarity reduces engagement — that means fewer users, fewer contributors and a smaller community. Several organizations are working on a open source solution for this community problems see for further details https://clearlydefined.io/about
Full disclosure I am one of the maintainer of OSS Review Toolkit and contributor to ClearlyDefined.io
> A trivial solution would be to create a crowd-sourced dependency vetting platform.
Such a platform is already being developed by various organizations, see https://clearlydefined.io/about and it already in use by GitHub. It's still under development and the initial focus is sharing data regarding copyrights, licenses and source code location for OSS packages.
Note that ClearyDefined only scans the code repository of OSS project it does not resolve dependencies for scanned OSS project. This makes sense as not all dependencies of OSS project B are inherited by a project A which included B as a dependency (due to dependency version resolution by the package manager or dependencies only used for testing).
The idea is that you will us an tool to resolve dependencies for the package manager your project uses which then queries the ClearyDefined APIs.
