What happens when the licence annotation in go.mod doesn’t match the contents of the LICENCE file in the repo? What if the LICENCE file is missing? What if the LICENSE file is present but subtley modified?

All good questions. We already have these problems (not just go - any repo) - the text in a source file might not match the LICENSE file, there might be a license in some files, but no LICENSE file, etc..

Ultimately it's incumbent on the repo owner to ensure that everything is done properly w.r.t. licensing.

But your proposing adding a go sub command which uses this non canonical information.

Not sure what you mean by "non-canonical" in this context. What's the canonical information? The LICENSE file? The license text in the source files? License information in a file called "foo license.txt"?

I don't see how what I'm proposing is any "less canonical" than any other license information the repo owner adds to their repo.

You proposed

One could even add a command to go mod (go mod licenses) to output a list of licenses used in the dependencies.

But as we've discussed there is no way to ensure that the data in go.mod matches the LICENSE file. The latter is the canonical source of information for the licence the code is released under, but your proposal suggests using the former, non canonical information from go.mod. If this proposal would be accepted, people would parse go.mod, or expect json style output from go mod licenses to feed into compliance tools; but that data could be out of sync with the actual LICENSE text in the repository.

The latter is the canonical source of information for the licence the code is released under

Is it? Just by convention? What about license information in source files?

There's no way to ensure that what's in the LICENSE file (if it exists) matches what's in the source files. It still falls on the repo owner to ensure it's consistent and correct. I don't see how this is any different.

Given it cannot be a required field, this would not obviate the need for something like go-licenses and instead makes its job more complex

Also note that, for example, pkgsite can't use SPDX identifiers alone to verify licenses. See #40586 (comment). cc @jba @julieqiu

That pkgsite discussion belongs in a different thread for sure, but it's a clear datapoint that we can't just stop looking at license files.

Ultimately it's incumbent on the repo owner to ensure that everything is done properly w.r.t. licensing.

Is that your opinion as a lawyer? Or are you just using common sense?

IANAL, but the way it was explained to me by a lawyer: imagine a file that had "SPDX identifier: MIT" at the top but contained license text that, say, restricted redistribution. Are you sure a court of law would say, "Let's just ignore all this perfectly phrased, legally appropriate, crystal-clear text and only pay attention to that tiny, cryptic notation at the top"? Maybe that's what would happen, maybe it wouldn't. Maybe they would say that the repo owner messed up, so anything goes; or maybe they would hold the other party liable because here are actual words in a file in the repo that clearly say you're not allowed to do what you did.

We have plans to provide a good license detector for Go programs.
It could even emit SPDX info.
But we're very unlikely to add SPDX tags to go.mod and assume they are correct.
It's also worth noting that SPDX tags by themselves are often meaningless.

For example suppose you say only 'SPDX MIT' (or, as you find in some READMEs on GitHub, 'License: MIT').
The MIT license says that use is permitted provided you reproduce "this notice". Where is the notice to reproduce? It doesn't exist. That makes it fairly difficult to comply with the license terms.

This is a case where a second claimed source-of-truth that will inevitably become out of sync with the underlying one would be particularly unfortunate.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

No change in consensus, so declined.
— rsc for the proposal review group