Impact of Terraform adopting BUSL

[wata727]

Hashicorp has announced that it will change Terraform's license from MPL 2.0 to BUSL 1.1.

• https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license

TFLint embeds a fork of Terraform, so it is concerned that it may be affected by this license change.

• Forked source code
  • https://github.com/terraform-linters/tflint/tree/v0.47.0/terraform
• PR for license change to MPL 2.0
  • Change license: MIT -> MPL 2.0 #245

At this time, the actual impact of this license change is unclear. BUSL may impose copyleft requirements on forks (See FAQ 14 and License terms), so TFLint license may also need to be changed to BUSL.

Also, the tflint-plugin-sdk includes a fork of Terraform, so we may need to change the SDK license to BUSL as well. If so, I'm not sure if plugins built with the SDK should also be changed to BUSL. If it has the same copyleft requirements as GPL, then the same license may apply as long as there are no linking exceptions. See Combining work with code released under BSL.

Yet another possibility is that tflint-ruleset-opa is a product that competes with Sentinel and violates BUSL.

Anyway, once again, no actions have been decided yet for this license change. Our initial goal is to clarify this impact, and as details become available we will share them in this discussion.

---

UPDATE: Here are the net effects of this license change:

• This license change is not retroactive, so there is no impact on usage up to TFLint v0.47.
• TFLint source code will continue to be distributed under MPL.
• When TFLint supports Terraform v1.5.6, the fork of Terraform source code will be changed to BUSL.
  • This means that the repository will have a mix of MPL-licensed and BUSL-licensed source code.
• Combined works (release binaries) are bound to both MPL and BUSL.
  • This means they are subject to the more restrictive BUSL.

[wata727]

Posted a question to the Hashicorp discussion forum.
https://discuss.hashicorp.com/t/hashicorp-projects-changing-license-to-business-source-license-v1-1/57106/3?u=wata727

[bendrucker]

https://discuss.hashicorp.com/t/hashicorp-projects-changing-license-to-business-source-license-v1-1/57106/7

The BSL does not impose copyleft requirements for your OSS project, so you do not need to change your project’s overall license to BSL. However, the clarifications in FAQ 14 do still apply. In particular, if your copy/fork of Terraform internal packages are based on HashiCorp BSL licensed source code, then these derivative copies will need to also be BSL licensed with the same terms.

And re: OPA:

After an initial review of the plugin on GitHub, it is not in violation of BSL as it does not appear to host or embed. If the scope of the plugin changes and you have additional questions, please reach out to us.

[bendrucker]

Sounds like the only semi-immediate action is to update the package license:

https://github.com/terraform-linters/tflint/blob/master/terraform/LICENSE

And even then, this is only required when pulling in new code from 1.5.6 and on, existing releases and main are still. compliant.

[wata727]

Yes, according to joatmon08's reply, there is no copyleft requirement in BUSL and TFLint source code can still be licensed under the MPL.
However, a fork of Terraform will be licensed under BUSL, so perhaps TFLint will have a mixture of MPL and BUSL licensed source code.

Also, according to the answer to second question, Combined Work is bound by both licenses. I think this means that release binaries are subject to the most restrictive BUSL.

Should OSS that uses BSL-licensed source code as a library change license to BSL?
No. It will be bound by both licenses as it is mixed with BSL source code and the existing license of your project.

[wwuck]

Have you seen the OpenTF announcement?

https://opentf.org/announcement

Is tflint considering moving to opentf after it is released?

[wata727]

I'm not sure yet. OpenTF is a fledgling project and we cannot assess its continuity at this time.
At the moment, TFLint is focused on compatibility with Terraform, so it's unlikely to switch the OpenTF.

[bendrucker]

Generally I'm not very optimistic about OpenTF.

Forking Terraform as it exists today and renaming things is easy. Maintaining a fork that maintains compatibility with Terraform's interfaces (CLIs, provider plugin protocol) without using any of its code is hard in the long run.

Folks from HashiCorp that have steered Terraform's architecture in recent years like https://github.com/apparentlymart and https://github.com/jbardin are incredibly sharp. Having a bunch of Terraform practitioners sign a petition, to be blunt, doesn't achieve anything. Whether this works out will largely hinge on whether Spacelift/env0/Scalr/etc., who claim they will cover the cost of 3-5 full time engineers for 5+ years, are committed to shouldering the several million dollars that will cost.

If OpenTF is able to take on a bit of the burden of reverse engineering Terraform internals, e.g., expression evaluation, TFLint could take depend on those modules rather than embedding its own forked packages. But that will be a long term consideration. There is definitely no plan to move upon release as everything that TFLint has forked is MPL licensed.

[skyzyx]

Thank you for your answer.

From a technical perspective, I expect that it will be a no-op for the time being as OpenTF anticipates maintaining compat/interop for the foreseeable future. (However, OpenTF has stated that some functionality may be added to OpenTF that is a superset of what's in base Terraform. [source])

From a process perspective:

1. If there is a bug in OpenTF that does not exist in Terraform (or vice-versa), will bug reports (as they pertain to this project) be treated equally on both platforms?

2. Will testing be performed with code targeting both platforms?

3. For OpenTF's potential future "superset" functionality, will that be treated as a first-class citizen?

Based on responses from @wata727 and @bendrucker, it sounds like "not right now". But these are my concerns as someone who is impacted by the fork.

[bendrucker]

Not right now is accurate for all 3. TFLint is primarily concerned with the Terraform language and not the broader feature set. Packages were extracted from Terraform out of convenience but not strict necessity. For now, TFLint will follow the Terraform language spec as provided by HashiCorp.

[kvendingoldo]

@skyzyx I think that we can start to work on independent project based on v0.50.3 that had MPL 2.0 license in scope of tofuutils. WDYT? I think that in the future it will be necessary to have a separate linter for opentofu, except tofu fmt or Checkov.

[kvendingoldo]

jfi, we created blank repo for this work: https://github.com/tofuutils/tofulint
will try to make fork and required changes soon, after discussing it

[pdecat]

Shouldn't the license of https://github.com/tofuutils/tofulint be MPL 2.0 like https://github.com/terraform-linters/tflint/blob/v0.50.3/LICENSE ?

[kvendingoldo]

Yes. It will be MPL 2.0, no worries about it.

[tedivm]

Is TofuLint going to support Terraform and OpenTofu, in a similar way to how tenv has supported both?

Although I've already released the chapter of my book that covers TFLint to the early access program, I'm going to have to update it now that TFLint is no longer completely open source and since the authors don't seem to want to support OpenTofu (which I'll have to mention as well). We should chat about the timelines for TofuLint so I can also include it in the book before publication.

[kvendingoldo]

@tedivm it's a good question. TFLint is a complicated tool and requires a lot of other dependencies like sdk and plugins. I'm still thinking about backward supportability like we did in tenv, but don't think that it will be covered to 100%. I think that TofuLint will be a separate tool and will support only OpenTofu.

@skyzyx how do you think, where it will be better to discuss? Maybe in OpenTofu slack channel?