Investigate MPL -> BUSL Changes/Impact

[jeefy]

trafficstars

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 https://github.com/cncf/foundation/issues/187 (License exception for hashicorp/terraform projects)

EDIT: Let's keep this a data-gathering Issue only please 😄 See https://github.com/cncf/foundation/issues/617#issuecomment-1678235192 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: https://github.com/kubernetes/kubernetes/pull/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 (https://github.com/jaegertracing/jaeger/issues/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

• https://github.com/lima-vm/lima/pull/1728

[terrytangyuan]

Argo has one direct and multiple indirect dependencies on HashiCorp projects. My understand is that those dependencies are not subject to MPL -> BSL change. We are tracking those closely at https://github.com/argoproj/argoproj/issues/236.

[ckotzbauer]

Kured uses one library indirectly, I opened https://github.com/kubereboot/kured/issues/817

[stefanprodan]

@dims I think CNCF needs to replace hashicorp/vault with hashicorp/vault/api in the license exceptions, only the API package remains MPL, while the rest is now BUSL 1.1.

[justincormack]

The repos that have changed licenses are below (note as Stefan says, there may be parts that are not relicensed in these repos)

hashicorp/terraform hashicorp/consul hashicorp/vault hashicorp/vagrant hashicorp/nomad hashicorp/packer hashicorp/waypoint hashicorp/boundary hashicorp/vault-csi-provider hashicorp/vault-secrets-operator

All the general Go libraries etc are unchanged.

Sub parts that remain MPL include (not exhaustive check) hashicorp/consul/api hashicorp/vault/api hashicorp/vault/sdk

[stefanprodan]

For the Flux project we are tracking the HashiCorp license change impact here https://github.com/fluxcd/flux2/issues/4156.

While evaluating our usage of HashiCorp Go packages and software products, two questions have been raised:

❓ We need to decide what do to with the Flux Terraform Provider, if CNCF doesn't add the Terraform Plugin SDK (MPL licensed) to the exceptions list we may be forced to stop offering an official Terraform Provider for Flux.

❓ We need to decide what do to with the various end-to-end tests that rely on Terraform for infrastructure bootstrap. We've invested tremendous time in developing automated e2e and conformance tests for Flux 2.0 GA. I hope we can keep using Terraform internally as we don't ship any HashiCorp software with Flux, we only use this software in GitHub Actions Workflows.

[jayunit100]

... anyways, so re: sig-windows-dev-tools...

• we dont vendor it at all, its just used in the dev workflow as a blackbox, so ...
• i dont think were effected by this @amye :) sorry about the useless initial response earlier.

[JorTurFer]

Hello, In KEDA (keda.sh) we support HashiCorp Vault as secrets source (we just read values from there as a client), due to it, we use these deps:

github.com/hashicorp/vault/api
github.com/hashicorp/errwrap v1.1.0 // indirect github.com/hashicorp/go-cleanhttp v0.5.2 // indirect 
github.com/hashicorp/go-hclog v1.3.0 // indirect 
github.com/hashicorp/go-multierror v1.1.1 // indirect 
github.com/hashicorp/go-retryablehttp v0.7.2 // indirect 
github.com/hashicorp/go-rootcerts v1.0.2 // indirect 
github.com/hashicorp/go-secure-stdlib/parseutil v0.1.7 // indirect 
github.com/hashicorp/go-secure-stdlib/strutil v0.1.2 // indirect 
github.com/hashicorp/go-sockaddr v1.0.2 // indirect 
github.com/hashicorp/go-uuid v1.0.3 // indirect 
github.com/hashicorp/hcl v1.0.0 // indirect

We also deploy a HashiCorp Vault during e2e test to test the integration (we use helm chart for it). We only use it locally within the testing cluster and we remove it after the e2e test.

For managing e2e test infrastructure we use terraform as well. We manage the infra from its own repo and terraform is executed via GH Action (using an Azure Blob Storage as backend).

I think that we aren't affected because KEDA doesn't provide any service that compits with hashicorp products, so 3rd parties who offer KEDA as service should be safe, but it'd be nice if we could confirm this point.

[sftim]

Using Vagrant is allowed by the new licence, so long as either:

• it's not a production service (our CI/CD isn't that, in my view)
• it is a production service but there is no competition with Hashicorp's business interests

I am of course not a lawyer

[ahrtr]

etcd has only one indirect dependency on library github.com/hashicorp/golang-lru, it seems not subject to the license change based on https://www.hashicorp.com/license-faq

[yongtang]

coredns has indirect dependencies on multiple hashicorp projects through github.com/openzipkin/zipkin-go and gopkg.in/DataDog/dd-trace-go.v1:

github.com/openzipkin/[email protected] github.com/hashicorp/[email protected]
github.com/openzipkin/[email protected] github.com/hashicorp/[email protected]
github.com/openzipkin/[email protected] github.com/hashicorp/[email protected]
gopkg.in/DataDog/[email protected] github.com/hashicorp/consul/[email protected]
gopkg.in/DataDog/[email protected] github.com/hashicorp/vault/[email protected]
gopkg.in/DataDog/[email protected] github.com/hashicorp/vault/[email protected]
gopkg.in/DataDog/[email protected] github.com/hashicorp/[email protected]
gopkg.in/DataDog/[email protected] github.com/hashicorp/[email protected]
gopkg.in/DataDog/[email protected] github.com/hashicorp/[email protected]
gopkg.in/DataDog/[email protected] github.com/hashicorp/[email protected]
gopkg.in/DataDog/[email protected] github.com/hashicorp/[email protected]
gopkg.in/DataDog/[email protected] github.com/hashicorp/[email protected]
gopkg.in/DataDog/[email protected] github.com/hashicorp/[email protected]
gopkg.in/DataDog/[email protected] github.com/hashicorp/[email protected]
gopkg.in/DataDog/[email protected] github.com/hashicorp/[email protected]
gopkg.in/DataDog/[email protected] github.com/hashicorp/[email protected]
gopkg.in/DataDog/[email protected] github.com/hashicorp/[email protected]
gopkg.in/DataDog/[email protected] github.com/hashicorp/[email protected]

[MikeZappa87]

Hashicorp pulls in go-cni for nomad. Can we position our license to say they can no longer use it? Or larger to say you cannot use the CNI at all?

[dims]

Hashicorp pulls in go-cni for nomad. Can we position our license to say they can no longer use it? Or larger to say you cannot use the CNI at all?

@MikeZappa87 please let's not go there.

[bryantbiggs]

coredns has indirect dependencies on multiple hashicorp projects through github.com/openzipkin/zipkin-go and gopkg.in/DataDog/dd-trace-go.v1:

github.com/openzipkin/[email protected] github.com/hashicorp/[email protected]
github.com/openzipkin/[email protected] github.com/hashicorp/[email protected]
github.com/openzipkin/[email protected] github.com/hashicorp/[email protected]
gopkg.in/DataDog/[email protected] github.com/hashicorp/consul/[email protected]
gopkg.in/DataDog/[email protected] github.com/hashicorp/vault/[email protected]
gopkg.in/DataDog/[email protected] github.com/hashicorp/vault/[email protected]
gopkg.in/DataDog/[email protected] github.com/hashicorp/[email protected]
gopkg.in/DataDog/[email protected] github.com/hashicorp/[email protected]
gopkg.in/DataDog/[email protected] github.com/hashicorp/[email protected]
gopkg.in/DataDog/[email protected] github.com/hashicorp/[email protected]
gopkg.in/DataDog/[email protected] github.com/hashicorp/[email protected]
gopkg.in/DataDog/[email protected] github.com/hashicorp/[email protected]
gopkg.in/DataDog/[email protected] github.com/hashicorp/[email protected]
gopkg.in/DataDog/[email protected] github.com/hashicorp/[email protected]
gopkg.in/DataDog/[email protected] github.com/hashicorp/[email protected]
gopkg.in/DataDog/[email protected] github.com/hashicorp/[email protected]
gopkg.in/DataDog/[email protected] github.com/hashicorp/[email protected]
gopkg.in/DataDog/[email protected] github.com/hashicorp/[email protected]

These are all fine per https://www.hashicorp.com/license-faq#What-did-HashiCorp-announce-today-(Aug-10)

HashiCorp APIs, SDKs, and almost all other libraries will remain MPL 2.0.

[abvaidya]

Athenz provides a terraform provider - https://github.com/AthenZ/terraform-provider-athenz and uses following libraries -

github.com/hashicorp/go-cty v1.4.1-0.20200723130312-85980079f637
    github.com/hashicorp/terraform-plugin-sdk/v2 v2.27.0

    github.com/hashicorp/errwrap v1.1.0 // indirect
github.com/hashicorp/go-checkpoint v0.5.0 // indirect
github.com/hashicorp/go-cleanhttp v0.5.2 // indirect
github.com/hashicorp/go-hclog v1.5.0 // indirect
github.com/hashicorp/go-multierror v1.1.1 // indirect
github.com/hashicorp/go-plugin v1.4.10 // indirect
github.com/hashicorp/go-uuid v1.0.3 // indirect
github.com/hashicorp/go-version v1.6.0 // indirect
github.com/hashicorp/hc-install v0.5.2 // indirect
github.com/hashicorp/hcl/v2 v2.17.0 // indirect
github.com/hashicorp/logutils v1.0.0 // indirect
github.com/hashicorp/terraform-exec v0.18.1 // indirect
github.com/hashicorp/terraform-json v0.17.0 // indirect
github.com/hashicorp/terraform-plugin-go v0.18.0 // indirect
github.com/hashicorp/terraform-plugin-log v0.9.0 // indirect
github.com/hashicorp/terraform-registry-address v0.2.2 // indirect
github.com/hashicorp/terraform-svchost v0.1.1 // indirect
github.com/hashicorp/yamux v0.1.1 // indirect

[AkihiroSuda]

@jeefy

Investigate MPL -> BSL Changes/Impact

Could you consider s/BSL/BUSL/ in the issue title?

"BSL" stands for "Boost Software License" (OSI-approved, very permissive license) in SPDX:

• https://spdx.org/licenses/BSL-1.0.html
• https://spdx.org/licenses/BUSL-1.1.html

[amye]

@jeefy

Investigate MPL -> BSL Changes/Impact

Could you consider s/BSL/BUSL/ in the issue title?

"BSL" stands for "Boost Software License" (OSI-approved, very permissive license) in SPDX:

• https://spdx.org/licenses/BSL-1.0.html
• https://spdx.org/licenses/BUSL-1.1.html

Done

[jeefy]

My bad, thanks!

[fedordikarev]

if it can be useful: Dashboard with overview of modules and their licences: https://fedordikarev.grafana.net/dashboard/snapshot/AVkaQa2He4cgKOfXisVPZGTF2c5oS6eY (2023-08-13 12:25 UTC: updated column widths for better UX)

and here is code how to get and reproduce that data: https://github.com/fedordikarev/misc/tree/master/cncf_hashicorp

[dims]

thanks @fedordikarev that's really helpful