I don't agree. We have been moving towards having both the core rules and the baseline set of tools in this same repository. That will require distinct MODULE.bazel files for the core vs. the others, as core can't depend on anything, while the tools will obviously require language rules.

We could create a second project for the tools. That may have other developer costs, since we'll normally want to test in both at once.

Are the "baseline set of tools" things that are only needed by Bazel users?

From my understanding of the tools you have in mind, they would be applicable to developers outside of Bazel who are working with sboms, and therefore I propose that they should not live in rules_license at all.

I'd be happy to do the research to find who else is working on tools that accomplish those use cases and make a connection so that we can make sure those tools are easily adoptable by Bazel users as well, or create the tools if they truly don't exist anywhere.

I think there are two reasons here:

1. The "baseline set of tools" are really meant to serve more as examples, with the expectation that organizations will make their own customized forks to support their particular use cases. Meanwhile even if they are expected to fork the core rules to e.g. add conditions to license kinds, the core rules still need to be consistent enough that a license declaration in a public repository they're depending on will still do the right thing.
2. As @aiuto mentioned, dependencies are an issue. If we want basically everything to include a license declaration (which I hope is the eventual goal), then basically everything needs to depend on rules_license. That's fine, because the core rules are pure starlark. But the "baseline set of tools" have additional dependencies such as for example python, which would lead to circular dependencies if rules_python started using rules_license. Even without the problem of circular dependencies, the more transitive dependencies rules_license has, the more having rules_license pulled in transitively will affect how your other transitive dependencies get resolved, which is harmful.

The first reason there isn't a very strong argument for splitting the repository, but the second one definitely is.