Investigate MPL -> BUSL Changes/Impact #617
Comments
|
Kubernetes Infra (sig-k8s-infra) has a lot of usages of terraform: Kubernetes image-builder subproject of CAPI uses packer to build AMI(s): 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: And we have tools to prevent regressions to the vendored depdenencies: Initial slack discussion: |
|
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 |
|
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/ |
|
The Register has a story at https://www.theregister.com/2023/08/11/hashicorp_bsl_licence/ (in the inimitable El Reg style). |
|
Sig windows dev tools uses vagrant |
Slightly more details would be helpful! |
|
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 |
|
Jaeger backend (https://github.com/jaegertracing/jaeger) uses two Hashicorp libraries:
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 |
|
OpenFGA (https://github.com/openfga/openfga) uses:
OpenFGA's CLI (https://github.com/openfga/cli) uses
Our understanding is that those projects are libraries that are not subject to MPL -> BSL change. |
|
|
Lima has a template for Nomad, but we are going to ditch it away |
|
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. |
|
Kured uses one library indirectly, I opened kubereboot/kured#817 |
|
@dims I think CNCF needs to replace |
|
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 All the general Go libraries etc are unchanged. Sub parts that remain MPL include (not exhaustive check) |
|
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. |
|
... anyways, so
|
|
Hello, 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. |
|
Using Vagrant is allowed by the new licence, so long as either:
I am of course not a lawyer |
|
etcd has only one indirect dependency on library |
|
Starting from the 21.0.0 release, Keycloak discontinued support for Hashicorp integration, so the impact should be low. If there's any information needed from us, please let me know. |
Due to [1] We need to make sure not to use BSL modules. Luckily the current we use have not changed. The ones that are not changed are SDK/API and general Go libraries. "HashiCorp APIs, SDKs, and almost all other libraries will remain MPL 2.0." [1] [2] This commit creates a github action which allowlists them. Any other module of hashicorp will be rejected, and will need to be manually examined if it uses MPL (or other non restrictive license) or BSL. [1] https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license [2] cncf/foundation#617 (comment) Signed-off-by: Or Shoval <oshoval@redhat.com>
Due to [1] We need to make sure not to use BSL modules. Luckily the current we use have not changed. The ones that are not changed are SDK/API and general Go libraries. "HashiCorp APIs, SDKs, and almost all other libraries will remain MPL 2.0." [1] [2] This commit creates a github action which allowlists them. Any other module of hashicorp will be rejected, and will need to be manually examined if it uses MPL (or other non restrictive license) or BSL. [1] https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license [2] cncf/foundation#617 (comment) Signed-off-by: Or Shoval <oshoval@redhat.com>
They've added hashicorp/vault/shamir to the MPL licensed packages |
|
Hello, We conducted a manual audit in Falco by examining the content of all the We did identify a small number of MPL2 licensed packages without existing license exceptions. We're currently assessing whether we can get rid of these. If not, we'll proceed with a license exception request. Tracking here: falcosecurity/evolution#305. MPL2 licensed licensed package to be evaluated
Other Hashicorp package we are using
N.B. |
That was as of the time of publication and predates this issue. If you need a separate issue, feel free! |
@amye Thank you for the clarification! My point is: since an exception for If this is not the case, I will open a separate issue 🙏 |
|
Seems we never documented this here, Prometheus is using which are both explicitly under MPL 2.0; scanners would catch it anyway if they weren't |
|
Hi, from the KubeVela project we have the following dependencies:
|
According cncf/foundation#617 (comment) we need to look on go.mod only because we have "go 1.17" in go.mod. Adapt git actions accordingly. Signed-off-by: Or Shoval <oshoval@redhat.com>
* go mod: Improve readability The go VER line was there, but not in the beginning as it should. Signed-off-by: Or Shoval <oshoval@redhat.com> * modules: Amend hashicorp filtering According cncf/foundation#617 (comment) we need to look on go.mod only because we have "go 1.17" in go.mod. Adapt git actions accordingly. Signed-off-by: Or Shoval <oshoval@redhat.com> --------- Signed-off-by: Or Shoval <oshoval@redhat.com>
|
notation-hashicorp-vault uses vault API as a direct dependency. According to the HashiCorp statement and Vault API license file, HashiCorp APIs, SDKs, and almost all other libraries will remain MPL 2.0, as well as Vault API. I assume it is compliant to use Vault API as a dependency in notation-hashicorp-vault. If there is any concern on Vault API's license, please let us know. Thanks. |
|
@FeynmanZhou you should cross check if the official list of exceptions has what you need already ... if not you will need to ask for an exception https://github.com/cncf/foundation/tree/main/license-exceptions |
|
@dims are these lists up to date? Hashicorp Vault is marked MPL 2.0 while it's BUSL https://github.com/hashicorp/vault/blob/main/LICENSE foundation/license-exceptions/cncf-exceptions-2023-06-27.spdx Lines 65 to 74 in 23f35b3 foundation/license-exceptions/cncf-exceptions-2023-06-27.json Lines 28 to 31 in 23f35b3 |
|
@stefanprodan looks you have to use the MPL version of the older tags/releases as BUSL is not been granted an exception. If you are not able to, then please file for a new exception specifying which release(s) you want to use which have the newer license. |
|
@dims Vault's API package is MPL, see https://github.com/hashicorp/vault/blob/main/api/.copywrite.hcl I this the exclusion list should point to the foundation/license-exceptions/cncf-exceptions-2023-06-27.spdx Lines 76 to 85 in 23f35b3 |
|
@stefanprodan ok i kicked off a PR to force the issue - #670 |
|
Thanks @dims |
|
We're going to close this out as we've collected enough info for the Legal Committee to navigate these waters. We really appreciate everyone's input! Y'all rock <3 |
and others
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
The text was updated successfully, but these errors were encountered: