Investigate MPL -> BUSL Changes/Impact about foundation HOT 73 OPEN

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?

from foundation.

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

from foundation.

@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

from foundation.

@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

from foundation.

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).

from foundation.

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.

from foundation.

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

• lima-vm/lima#1728

from foundation.

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 argoproj/argoproj#236.

from foundation.

Kured uses one library indirectly, I opened kubereboot/kured#817

from foundation.

For the Flux project we are tracking the HashiCorp license change impact here fluxcd/flux2#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.

from foundation.

... 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.

from foundation.

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.

from foundation.

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

from foundation.

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

from foundation.

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]

from foundation.

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.

from foundation.

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.

from foundation.

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

from foundation.

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

from foundation.

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

from foundation.

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.

from foundation.

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

from foundation.

Sig windows dev tools uses vagrant

from foundation.

Sig windows dev tools uses vagrant

Slightly more details would be helpful!

from foundation.

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

from foundation.

• 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

from foundation.

@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.

from foundation.