Google Git
Sign in
fuchsia / third_party / github.com / bazelbuild / rules_license / refs/heads/pcon
commit4186f382f773db94b5cd675a1c35db0c8484cf93[log] [tgz]
authorTony Aiuto <aiuto@google.com>Sat Oct 28 10:05:33 2023 -0400
committerTony Aiuto <aiuto@google.com>Sat Oct 28 10:05:33 2023 -0400
tree815b5e14164407e540981e23e5d0f6e0cbc21729
parenteb2208ef661f9fb08aa82fa60d5f4ce1e4ce681f [diff]
refactor the crappy sbom generator as an aspect
3 files changed
tree: 815b5e14164407e540981e23e5d0f6e0cbc21729
  1. .bazelci/
  2. .github/
  3. admin/
  4. distro/
  5. doc_build/
  6. docs/
  7. examples/
  8. licenses/
  9. rules/
  10. rules_gathering/
  11. sample_reports/
  12. tests/
  13. tools/
  14. .gitignore
  15. BUILD
  16. CODEOWNERS
  17. deps.bzl
  18. LICENSE
  19. MODULE.bazel
  20. README.md
  21. version.bzl
  22. WORKSPACE
  23. WORKSPACE.bzlmod
README.md

rules_license

CI: Build status

This repository contains a set of rules and tools for

  • declaring metadata about packages, such as
    • the licenses the package is available under
    • the canonical package name and version
    • copyright information
    • ... and more TBD in the future
  • gathering license declarations into artifacts to ship with code
  • applying organization specific compliance constriants against the set of packages used by a target.
  • producing SBOMs for built artifacts.

WARNING: The code here is still in active initial development and will churn a lot.

Contact

If you want to follow along:

Roadmap

Last update: October 22, 2023

Q4 2023

  • Reference implementation for “packages used” tool
    • produce JSON output usable for SBOM generation or other compliance reporting.
  • Reference implementation for an SPDX SBOMM generator
    • Support for reading bzlmod lock file
    • Support for reading maven lock file
  • “How To” guides
    • produce a license audit
    • produce an SBOM

Q1 2024

  • Add support for other package manager lock file formats
    • ? Python
    • Golang
    • NodeJS
  • More SPDX SBOM fields
    • support for including vendor SBOMs

Beyond

  • Performance improvements

  • Sub-SBOMs for tools

  • TBD

Background reading:

These is for learning about the problem space, and our approach to solutions. Concrete specifications will always appear in checked in code rather than documents.