Add license configuration to buf.yaml

[bufdev]

[amckinney]

If we add this to buf.yaml, I imagine we'd be limited to supporting standard license types like MIT and Apache-v2.0. However, if we want users to be flexible with what license they want to use, we might need to support another file like buf.md that is recognized by buf and pushed alongside the user's module (e.g. LICENSE or buf.license).

Yet another option would be to model this as generic module metadata. We already have plans for giving users a way to specify arbitrary information like git_repository: github.com/bufbuild/buf, so we could theoretically include the license here. However, I doubt this is actually a viable option since the license would be huge, and we would still need to treat this piece of metadata more specially than others (i.e. we probably want to render the license somewhere front-and-center on the module's landing page).

[timostamm]

I've noted surfacing license info in the BSR in my previous UX Feedback and looked into it for the NPM registry.

NPM, Composer (PHP) and NuGet (C#) all allow to specify a license in the package manifest. There is tooling to list the licenses of all dependencies of a project or to enforce compliance. They all use SPDX identifiers / expressions. NPM and NuGet can reference proprietary licenses (an arbitrary text file in the package).

Related to #484, adding license information in buf.yaml would require an additional commit with (potentially) the same file content. The way the go module proxy and the NPM registry cache assets ATM, we need the incremented commit sequential ID to surface updated license information in the asset.

[bufdev]

Just a general note: I started this work a while back:

https://github.com/bufbuild/buf/blob/main/private/pkg/spdx/cmd/spdx-go-data/main.go https://github.com/bufbuild/buf/blob/main/private/gen/data/dataspdx/dataspdx.gen.go

This was meant to match what NPM does basically.

[cyinma]

completed by #1403 and #1569