License compliance clarification for unlisted projects

[shubham1172]

Hi,

The following projects are used by software under CNCF today, but these do not comply with CNCF Allowlist License Policy and are not listed under License exceptions. We are looking to understand the status of these projects - are they going to be moved under the exception lists?

Project URL	License	Used by
https://github.com/mitchellh/cli	MPL-2.0	https://github.com/kubernetes/kubernetes
https://github.com/hashicorp/consul	MPL-2.0	https://github.com/kubernetes/kubernetes
https://github.com/bketelsen/crypt	MIT	https://github.com/kubernetes/kubernetes
https://github.com/hashicorp/go-immutable-radix	MPL-2.0	https://github.com/kubernetes/kubernetes
https://github.com/hashicorp/go-retryablehttp	MPL-2.0	https://github.com/argoproj/argo-cd
https://github.com/hashicorp/go-rootcerts	MPL-2.0	https://github.com/kubernetes/kubernetes
https://github.com/hashicorp/go-sockaddr	MPL-2.0	https://github.com/kubernetes/kubernetes
https://github.com/hashicorp/go-uuid	MPL-2.0	https://github.com/kubernetes/kubernetes
https://github.com/smartystreets/goconvey	MPL-2.0	https://github.com/kubernetes/kubernetes
https://github.com/mitchellh/gox	MPL-2.0	https://github.com/kubernetes/kubernetes
https://github.com/hashicorp/logutils	MPL-2.0	https://github.com/kubernetes/kubernetes
https://github.com/hashicorp/memberlist	MPL-2.0	https://github.com/kubernetes/kubernetes
https://github.com/hashicorp/serf	MPL-2.0	https://github.com/kubernetes/kubernetes
https://github.com/armon/consul-api	MPL-2.0	https://github.com/helm/helm

[shubham1172]

@amye I see that this was added and removed from the license exceptions project board. Will this be also addressed in the next meeting? Is there any other information that I can provide here?

[amye]

This has several requests in it which make it difficult to track, and right now I'm prioritizing project requests directly.
However, it is likely that many of these will be resolved in this next round of reviews.

[shubham1172]

Okay, please let me know if I can help sorting them in any way to make it easier for tracking. We can also track them as a part of #297 if that is easier.

[amye]

Appreciated! We're just now rolling out a more direct process for this to be able to help deal with backlog, I will leave this open as we work through this.

[shubham1172]

Thank you @amye!

[jeromeinsf]

https://github.com/hashicorp/memberlist not only used by https://github.com/kubernetes/kubernetes but also https://github.com/cortexproject/

[BenTheElder]

Where are you getting this list of packages?

We aren't using any github.com/hashicorp packages in kubernetes:
https://github.com/kubernetes/kubernetes/tree/master/vendor/github.com and we keep a very close eye on our dependencies.

[BenTheElder]

See also Kubernetes' complete dump of LICENSES for all packages we're using: https://github.com/kubernetes/kubernetes/tree/master/LICENSES

I suspect at least some of these are incorrectly listed due to looking at the entire module graph, which is NOT the set of packages actually linked into binaries.

We build releases in Go's vendor mode, from only the checked in sources under vendor/ and the in-repo sources.

That only leaves whatever else is in docker base images (which we've also shrunk to be very small distroless based), or what is only used at development time (hack/tools/go.mod, CI fetched binaries etc, none of which are built and distributed by us).

We specifically have custom tooling to catch and prevent taking these dependencies:
https://github.com/kubernetes/kubernetes/blob/ffb4172ff18ff9edc19adff9c657da81c25aaf92/hack/lint-dependencies.sh#L46

https://github.com/kubernetes/kubernetes/blob/master/cmd/dependencyverifier/dependencyverifier.go

https://github.com/kubernetes/kubernetes/blob/2ebc0cc0257b93526dac87e6d216e73909244ab2/hack/unwanted-dependencies.json#L22-L26

EDIT: see also kubernetes/kubernetes#95571 (comment)

I suspect the list above is coming from the go module graph which includes the entire transitive dependency tree even packages that will not be linked into binaries. The actual dependency set used is smaller than the module graph.

[liggitt]

For dependencies used by kubernetes, see the go.mod files and vendor directory, not the go.sum file.

[liggitt]

None of the dependencies listed in the description are in use by the kubernetes/kubernetes repo. I added them to kubernetes/kubernetes#118023 to ensure they don't get added as dependencies in the future.

[BenTheElder]

I don't think helm is using github.com/armon/consul-api either, again it's in go.sum but it's not in the transitive deps in go.mod, and go 1.19 go.mod will include transitive deps that are used.

It's possible helm's go.mod is not in sync with actual builds but seems unlikely.
Someone could perhaps confirm by looking at the embedded go version metadata in the binaries or by switching helm to vendor.

argo-cd however does appear to be using github.com/hashicorp/go-retryablehttp:

https://github.com/argoproj/argo-cd/blob/7825821c1cda17b809e44b66cc5980fecf28af4f/go.mod#L47

[liggitt]

argo-cd however does appear to be using github.com/hashicorp/go-retryablehttp:

so is kubernetes-sigs/zeitgeist#543 and kubernetes-sigs/release-sdk#197

#138 was opened years ago specifically for this library... it's not clear why that wasn't allowlisted along with several of the other hashicorp libraries

[amye]

Closing as #138 resolves, but let me know if that's not the case!