Clarify license notices

[wata727]

Introduction

After merging #2030, TFLint now has two licenses: MPL 2.0 and BUSL 1.1.
Having two different licenses can be confusing for contributors and can lead to unintended patch submissions.
In particular, BUSL does not meet the definition of open source, which leaves a pretty bad situation for contributors who mistakenly think this project is completely open source.

Also, there is the question of how to handle contributions to the Terraform fork.
Most of the current fork is licensed under the MPL, but if a patch is merged into it that requires it to be MPL, it will no longer be possible to merge BUSL code into it in the future. (Note that MPL is file-level copyleft. Existing MPL-licensed code can be changed to BUSL because it has been relicensed as BUSL in the upstream, which is achieved by HashiCorp's CLA)

Proposal

To solve these problems, the following two things are probably needed.

• Contributor's explicit consent to provide patches under the current licenses
• Agreement to allow future changes to BUSL regarding patches to the Terraform fork

Perhaps something like the following would be helpful.

Developer Certificate of Origin (DCO)

By enforcing DCO on this project, we can force contributors to agree to the current license. However, the Developer Certificate of Origin v1.1 specifically mentions "open source", and I'm not sure if it works as an agreement for a license like BUSL.

There is also resistance to enforcing DCO because it increases the burden on contributors.

Contributor License Agreement (CLA)

We can define additional terms about licensing by requiring contributors to sign the CLA. Perhaps we could also define requirements for BUSL relicensing of the Terraform fork.

But I'm not a lawyer, so I don't know if I can design a good CLA. Maintaining this on a volunteer basis would be quite an arduous task.

Creating a CONTRIBUTING file

The easiest way to get started is to create CONTRIBUTING.md. This file may be useful for licensing notices. However, it is debatable whether the existence of this file can be treated as consent.

References

• https://wiki.linuxfoundation.org/dco
• https://developercertificate.org/
• https://github.com/apps/dco
• https://yahoo.github.io/oss-guide/docs/resources/what-is-cla.html
• https://opensource.google/documentation/reference/cla
• https://www.hashicorp.com/cla
• https://github.com/contributor-assistant/github-action
• https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors

[tedivm]

Any reason not to just use OpenTofu instead of the closed source code? Is it possible to make it so the closed source code is isolated away from the open source stuff enough for people to drop in opentofu instead?

[wata727]

Considering that TFLint is a "Terraform" linter, I decided that OpenTofu cannot be used as an alternative.
While it might be possible to extract the Terraform package as another library, it would likely be difficult in terms of effort to maintain this interface also available in OpenTofu. Perhaps it's not a bad idea to fork TFLint for OpenTofu.

---

This comment is off-topic in this issue, but I'm replying here because some people may have similar questions.
From now on, please avoid posting comments about OpenTofu or forks in this issue. If you would like to discuss this matter, you can start a new discussion.