Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: cmd/go: add SPDX license list to go.mod file #46917

Closed
asmaloney opened this issue Jun 25, 2021 · 13 comments
Closed

proposal: cmd/go: add SPDX license list to go.mod file #46917

asmaloney opened this issue Jun 25, 2021 · 13 comments
Labels
Projects
Milestone

Comments

@asmaloney
Copy link
Contributor

@asmaloney asmaloney commented Jun 25, 2021

I would like to propose that an optional list of licenses be added to the go.mod file to allow a simple way to check license dependencies programatically. It also is a great place to see what license a module uses.

SPDX allows us to specify licenses in a concise, standard, machine-readable manner.

So a go.mod file might look something like this:

module gitlab.com/foo/bar

go 1.16

license BSD-3-Clause, MIT

require (
	github.com/go-co-op/gocron v1.6.2
	github.com/solher/arangolite/v2 v2.0.6
)

Probably need a way to specify that the license isn't on the SPDX list as well.

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

$ go mod licenses
BSD-3-Clause, MIT
  github.com/go-co-op/gocron MIT
    github.com/davecgh/go-spew ISC
    github.com/robfig/cron/v3 MIT
  github.com/solher/arangolite/v2 MIT
  gitlab.com/foo/blat [no license specified]

I guess this would be a simpler form of go-licenses. This proposal avoids the problem of trying to guess license file names and parsing them to figure out the licenses.

@gopherbot gopherbot added this to the Proposal milestone Jun 25, 2021
@davecheney
Copy link
Contributor

@davecheney davecheney commented Jun 25, 2021

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?

@asmaloney
Copy link
Contributor Author

@asmaloney asmaloney commented Jun 25, 2021

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.

@davecheney
Copy link
Contributor

@davecheney davecheney commented Jun 25, 2021

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

@asmaloney
Copy link
Contributor Author

@asmaloney asmaloney commented Jun 25, 2021

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.

@davecheney
Copy link
Contributor

@davecheney davecheney commented Jun 25, 2021

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.

@asmaloney
Copy link
Contributor Author

@asmaloney asmaloney commented Jun 25, 2021

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.

@seankhliao
Copy link
Contributor

@seankhliao seankhliao commented Jun 25, 2021

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

@mvdan
Copy link
Member

@mvdan mvdan commented Jun 25, 2021

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.

@ianlancetaylor ianlancetaylor changed the title Proposal: Add SPDX license list to go.mod file proposal: cmd/go: add SPDX license list to go.mod file Jun 25, 2021
@ianlancetaylor ianlancetaylor added this to Incoming in Proposals Jun 25, 2021
@jba
Copy link
Contributor

@jba jba commented Jun 25, 2021

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.

@rsc
Copy link
Contributor

@rsc rsc commented Jul 15, 2021

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.

@rsc rsc moved this from Incoming to Active in Proposals Aug 4, 2021
@rsc
Copy link
Contributor

@rsc rsc commented Aug 4, 2021

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

@rsc rsc moved this from Active to Likely Decline in Proposals Aug 11, 2021
@rsc
Copy link
Contributor

@rsc rsc commented Aug 11, 2021

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

@rsc rsc moved this from Likely Decline to Declined in Proposals Aug 18, 2021
@rsc
Copy link
Contributor

@rsc rsc commented Aug 18, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Proposals
Declined
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants