add a check that published Go modules have a valid license

[mvdan]

It's really easy to make mistakes resulting in a Go module lacking a valid LICENSE file. For example: https://pkg.go.dev/github.com/ipld/go-car/v2@v2.0.0

Documentation not displayed due to license restrictions.

I messed up that release because the v2 module was in a sub-directory, and that sub-directory did not have a LICENSE.md file like the root directory. So the published module zip file, as described by https://golang.org/ref/mod#zip-files, was unlicensed.

This is one of those problems that's really hard for a human to foresee and prevent. In fact, I was pretty sure I did things right, as I was using a symlink like v2/LICENSE.md -> LICENSE.md. But as per https://golang.org/ref/mod#zip-path-size-constraints, the zips ignore symlinks, as they are not portable.

I think CI should perform either or both of these two checks:

1. Ensure that the repository, as a whole, has a LICENSE file that matches the common one that all PL software should have. We could even make the automation update the file as necessary, such as what I did manually here: ipld/go-car@6c87996

2. Ensure that each Go module has a valid LICENSE file when released. Only public modules would be checked, like module github.com/ipld/foobar, and not module example/foo or module test/bar.

I realise point 2 is pretty Go-specific, and I think that's fine. If/when the unified CI learns about JS, Rust, or other languages, I would hope that we could also teach it to do a similar check for their package repositories.

Now, for the specifics on how to implement this.

A) How do we check if a license file is valid?

Option A1: Ensure that it's a byte-by-byte exact copy of the PL dual-license markdown file. This assumes that all software built within PL must use this license.

Option A2: Ensure that it's a valid OSI license. We could use https://github.com/google/licensecheck for this.

B) How do we check what LICENSE or LICENSE.md file would end up in a released module zip?

Option B1: We do a go mod download of the @latest known version from proxy.golang.org, and then look in the extracted directory inside the module download cache.

Option B2: We figure out what files would end up in a zip by ourselves, via https://pkg.go.dev/golang.org/x/mod/zip. This method is slightly better than B1, since we're checking the current git tree, not the last published version from a previous commit/tag.

[mvdan]

Option B2: We figure out what files would end up in a zip by ourselves, via https://pkg.go.dev/golang.org/x/mod/zip. This method is slightly better than B1, since we're checking the current git tree, not the last published version from a previous commit/tag.

This just got a lot easier, thanks to golang/mod@98d530a.

[galargh]

This issue was transferred to ipdxco/unified-github-workflows#35 in preparation for archiving of this repository.