cmd/go: include .Module.LicenseFile field in output of list -json

[myitcv]

What version of Go are you using (go version)?

$ go version
go version devel +2e918c3aab Tue Mar 17 06:38:32 2020 +0000 linux/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN="/home/myitcv/dev/cuelang/bin"
GOCACHE="/home/myitcv/.cache/go-build"
GOENV="/home/myitcv/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/myitcv/gostuff"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/myitcv/gos"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/myitcv/gos/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/myitcv/dev/cuelang/cue/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build007199907=/tmp/go-build -gno-record-gcc-switches"

What did you do?

This might be somewhat beyond the remit of cmd/go list, but raising the issue for completeness in any case.

In the process of developing a module, one needs to consider the licenses of dependencies. (Noting that in https://groups.google.com/forum/#!topic/golang-nuts/VKkLK7xSX5I I'm trying to establish whether only a subset of the module graph is relevant in this respect)

I'm considering creating tooling to aid the process of dependency license review by creating a log file of the following format (expanded for all dependencies, modulo the question in https://groups.google.com/forum/#!topic/golang-nuts/VKkLK7xSX5I):

===
$module@$version
$license

Code generating this log, having CI re-generate this log and check that any given commit is "clean" will ensure that any changes to dependencies (or their licenses) get flagged in a PR/CL for review.

However a pre-requisite for creating such a log is being able to extract the license file contents.

pkg.go.dev has some internal logic for finding the license file. I'd like to propose we add this logic to cmd/go and expose the license file via a .Module.LicenseFile field, which is set to os.DevNull in case no license is found.

cc @bcmills @jayconrod @matloob

[jayconrod]

cc @julieqiu @jba What is the logic in pkg.go.dev for locating license files? What file names are recognized?

This seems useful, but we should be very cautious not to provide anything that could be considered legal advice. It would be bad if we ignored a license file because it was named LICENSE.md instead of LICENSE for example. Another issue is that packages and perhaps individual files may be licensed separately, so it's not clear that attaching this information to .Module is the right thing to do.

[jba]

What is the logic in pkg.go.dev for locating license files? What file names are recognized?

The current list is at https://pkg.go.dev/license-policy. We know it is incomplete, in the sense that people use license files with other names, but it covers the large majority of cases.

We consider any matching file in the module root to be a potential license for the module. We also separately consider package licenses by walking the tree from the module root to the package, looking for those filenames.

[bcmills]

I suspect this is better suited to an external tool, since the go command itself has no need to identify or load license files beyond preserving them in .zip files and vendor directories.

[rsc]

At least to start I agree that this should be an external tool as well. It's not hard to grab .Dir and look for names. There can be multiple license files in a given directory too.

[myitcv]

On the golang-tools call yesterday we concluded that we would close this issue in favour of adding some sort of licenses API to #36785.

Jay, Bryan and Ian all made good points to the effect that having an extra field in .Module.LicenseFile runs the very serious risk of conferring to the user that the answer is in some way authoritative and/or definitive. But in reality this is an extremely grey area. Far better, per Ian's suggestion, to get the answer from pkg.go.dev where we have jumped through all the legal hoops on the identification and presentation of license files.