Investigate MPL -> BUSL Changes/Impact

[jeefy]

We may have some projects that may be impacted by a license change.

We should investigate the impact on our projects and provide guidance if they are impacted.

Relevant Links:
https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license
https://github.com/cncf/foundation/blob/main/allowed-third-party-license-policy.md
https://github.com/cncf/foundation/blob/main/agpl-recommendations.md
#187 (License exception for hashicorp/terraform projects)

EDIT: Let's keep this a data-gathering Issue only please 😄 See #617 (comment) for context.

EDIT EDIT: We've published some initial guidelines here: https://github.com/cncf/foundation/blob/main/source-available-recommendations.md

[dims]

Kubernetes Infra (sig-k8s-infra) has a lot of usages of terraform:
https://github.com/search?q=repo%3Akubernetes%2Fk8s.io%20terraform&type=code

Kubernetes image-builder subproject of CAPI uses packer to build AMI(s):
https://cs.k8s.io/?q=packer&i=nope&files=&excludeFiles=&repos=kubernetes-sigs/image-builder

Some good news though, Kubernetes used to vendor libraries from hashicorp under MPL for a long time in its history, but over time we started pruning them a while ago, the last of which went in here:
kubernetes/kubernetes#103548

And we have tools to prevent regressions to the vendored depdenencies:
https://github.com/kubernetes/kubernetes/blob/master/hack/unwanted-dependencies.json#L30

Initial slack discussion:
https://kubernetes.slack.com/archives/C5P3FE08M/p1691699636105219

[rikatz]

From a quick search on Vagrant usage:

Sig-windows-dev-tools rely on Vagrant to build the environment https://github.com/kubernetes-sigs/sig-windows-dev-tools

Kubespray (github.com/kubernetes-sigs/kubespray) offers a way to bootstrap using Vagrant

IIUC from the license, dev workflow licensing will not be changed and both tools uses Vagrant for development and not to offer production services, but it is worth checking as some cloud provider may be using at least kubespray internally and this may impact them

[BenTheElder]

While kubernetes core doesn't depend on any hashicorp libraries, plenty of subprojects do. https://cs.k8s.io/?q=%22github.com%2Fhashicorp&i=nope&files=&excludeFiles=&repos=

From a quick scan, I think these are all MPL things that remain MPL for now.

EDIT: We also have some vagrant usage in https://github.com/kubernetes-sigs/kind CI, but nothing critical and we can probably move to lima, we just need to non-interactively boot a cgroupsv2 enabled VM and ssh install/test docker/podman/kind. The kubernetes-sigs/image-builder project is probably the most immediate concern.

[vielmetti]

The Register has a story at https://www.theregister.com/2023/08/11/hashicorp_bsl_licence/ (in the inimitable El Reg style).

[jayunit100]

Sig windows dev tools uses vagrant

[amye]

Sig windows dev tools uses vagrant

Slightly more details would be helpful!

[dims]

Looking through the https://cs.k8s.io/?q=hashicorp%5C%2F&i=nope&files=go.mod&excludeFiles=&repos= and the exceptions list from https://github.com/cncf/foundation/tree/main/license-exceptions the grand total of 24 repos that seem to get vendored

hashicorp/consul/api
hashicorp/errwrap
hashicorp/go-cleanhttp
hashicorp/go-getter
hashicorp/go-hclog
hashicorp/go-immutable-radix
hashicorp/go-msgpack
hashicorp/go-multierror
hashicorp/go-plugin
hashicorp/go-retryablehttp
hashicorp/go-rootcerts
hashicorp/go-safetemp
hashicorp/go-secure-stdlib
hashicorp/go-sockaddr
hashicorp/go-uuid
hashicorp/go-version
hashicorp/golang-lru
hashicorp/hcl
hashicorp/memberlist
hashicorp/raft
hashicorp/raft-boltdb
hashicorp/serf
hashicorp/vault
hashicorp/yamux

[yurishkuro]

Jaeger backend (https://github.com/jaegertracing/jaeger) uses two Hashicorp libraries:

• github.com/hashicorp/go-hclog v1.5.0
• github.com/hashicorp/go-plugin v1.4.10

It is my understanding that libraries are not subject to MPL -> BSL change, but we're watching those repos anyway. We also have a plan to phase out hashicorp/go-plugin (jaegertracing/jaeger#4647).

[aaguiarz]

OpenFGA (https://github.com/openfga/openfga) uses:

• https://github.com/hashicorp/go-cleanhttp
• https://github.com/hashicorp/go-retryablehttp
• https://github.com/hashicorp/hcl

OpenFGA's CLI (https://github.com/openfga/cli) uses

• https://github.com/hashicorp/errwrap
• https://github.com/hashicorp/go-multierror
• https://github.com/hashicorp/hcl

Our understanding is that those projects are libraries that are not subject to MPL -> BSL change.

[AkihiroSuda]

• containerd has been using Vagrant in CI: https://github.com/containerd/containerd/blob/70a2c95ae8c02d7a4e448f0e4fb8bb0e6344b5c7/.github/workflows/ci.yml#L521-L572
  If this is problematic we can switch away from Vagrant to Lima (CNCF Sandbox) or something else.

• containerd has been also using https://github.com/hashicorp/go-multierror and https://github.com/hashicorp/go-retryablehttp , but they seem to remain MPL-2.0
  https://github.com/containerd/stargz-snapshotter/blob/45af8ffae86460a44f4181bce8c84391ffdfbf01/go.mod#L14-L15

[AkihiroSuda]

Lima has a template for Nomad, but we are going to ditch it away

• templates: remove nomad lima-vm/lima#1728