Google Git
Sign in
fuchsia / third_party / github.com / bazelbuild / rules_license / d167df2e411efe26d4658315f6ad94e79402d99f
commitd167df2e411efe26d4658315f6ad94e79402d99f[log] [tgz]
authorTony Aiuto <aiuto@google.com>Fri Jun 02 15:35:24 2023 -0400
committerTony Aiuto <aiuto@google.com>Fri Jun 02 15:37:24 2023 -0400
tree488a8ab923099fcc8913dd805415b9e765dab970
parent6654b23c39d67c1413bfa619130e769ac66e4313 [diff]
Move rules/sbom.bzl to rules_gathering/generate_sbom.bzl

This is part of a continuing cleanup to make license and package
metadata declarations distinct from the rules which create SBOMs
and other reports.

That will make it easier for the declarations to have global
consistency, while individual organizations can define their
own SBOM creators based on local compliance constraints.

Forwarders for moved files are left in place. They will be deleted
by 0.1.0 at the latest.
3 files changed
tree: 488a8ab923099fcc8913dd805415b9e765dab970
  1. .bazelci/
  2. .github/
  3. admin/
  4. distro/
  5. doc_build/
  6. docs/
  7. examples/
  8. licenses/
  9. rules/
  10. rules_gathering/
  11. tests/
  12. tools/
  13. .gitignore
  14. BUILD
  15. CODEOWNERS
  16. deps.bzl
  17. LICENSE
  18. MODULE.bazel
  19. README.md
  20. version.bzl
  21. WORKSPACE
  22. 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 those license declarations into artifacts to ship with code
  • applying organization specific compliance constriants against the set of packages used by a target.
  • (eventually) producing SBOMs for built artifacts.

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

If you want to follow along:

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.