In the event that Hashicorp sticks to their gun concerning their current license change for Terraform (something I consider likely unfortunately), I think the following questions will need to be addressed:

• What name will the fork have? (will opentf be the final name?)
• What deadline should be given before work on a fork starts?
• What are the immediate changes that will have to be made for the fork to be viable, separate from the Hashicorp organization?

Concerning the last point, I surmise the following work would have to be undertaken:

• We'd have to gradually rip "terraform" from the codebase and change it to the new name for the project, prioritizing what is externally visible first (in order not to infringe on trademarks)
• Plan for a replacement for the Terraform registry for providers and modules. That would probably entail implementing a centralized default with the possibility for the user to substitute it for their own.
• Work on a website and documentation for the fork.

In the process of scrubbing "Terraform" and "Hashicorp" out of the code base at least for areas that end users will see for trademark reasons, it has come to my attention that the terraform code has a lot of terraform cloud integration baked into it.

For my part, I just conservatively left it there, but I think we'll have to make a conscious decision about this.

Given that my workplace doesn't use Terraform Cloud, its easy for me to say "lets rip it out and it will make the code simpler", but I'm guessing a decent number of Terraform users are using Terraform Cloud and the set of people that would want to use OpenTF AND Terraform Cloud might not be empty (I have no idea how large it is).

However, if we keep Terraform Cloud into the code, Hashicorp won't maintain it as Terraform diverges from the OpenTF repo and we would have to shoulder the constant reconciliation of that divergence ourselves.

Alternatively, something we could try to do is remove Terraform Cloud integration from the repo and optionally support it as a separate plugin if we need (I'm naively guessing that is possible, though it would require significant architectural work and either way I think it is safe to guess that Hashicorp would not join the party in maintaining Terraform Cloud as a separate plugin either even if they would potentially have a commercial interest in it).

Since when changing the license of software you need to request sign-off from all the Copyright holders, the CLA granting a perpetual copyright license allowed for unilateral change to be made to the project's software license.

As OpenTofu is going to be under the Linux Foundation's umbrella (where most projects seem to use EasyCLA) and there's already been mention of a potential new CLA I'm asking here if that is in fact the intention going forward.

If that is the case I'd be curious to understand why this decision was taken when the lesson here seems to me that "the community" at large can not trust promises of good will when faced with the reality of possible unilateral re-licensing.

I'm no lawyer but the LF CLA doesn't seem materially different to the Hashicorp one

https://github.com/cncf/cla/blob/master/individual-cla.pdf

https://www.hashicorp.com/cla

The case for CLAs

...
1. Easy relicensing:
...
There are benefits in relicensing being hard because it results in stable legal expectations around a project and encourages projects to consult their contributor communities before undertaking significant legal policy changes.

https://opensource.com/article/19/2/cla-problems

For successful relicensing the agreement of all involved copyright holders, typically the developers, to a changed license is required. While in the free and open-source domain achieving 100% coverage of all authors is often impossible due to the many contributors involved, often it is assumed that a great majority is sufficient. For instance, Mozilla assumed an author coverage of 95% to be sufficient.

https://en.wikipedia.org/wiki/Software_relicensing

The BUSL (unlike the SSPL license which Elastic and MongoDB switched to) will eventually convert to an unrestricted OSS Change License which in Hashicorp's case is MPL2, but it's up to the licensor to say after how long time.

The creator of the BUSL, MariaDb, writes this in their FAQ (emphasis mine):

Q: How far in the future is the recommended Change Date?

A: Picking the right Change Date depends on how rapidly the software is changing. Bear in mind that, regardless of the Change Date, the Change License will take effect on the fourth anniversary of the first publicly available distribution of software under the BSL. For most software, the recommendation is four years, which is the BSL’s default position. For rapidly developing software, an earlier Change Date may help encourage community contributions.

So, if Hashicorp won't switch back to an OSS license and there will be a fork of Terraform, then you should still lobby Hashicorp to make the Change Date shorter than the current 4 years that they are targeting (which happens to be the max allowed bu BUSL)

A shorter Change Date, like eg. a 6-12 month one, would make Hashicorp's Terraform act more like a "downstream" fork of your "upstream" one and you can pull back changes after the 6-12 months has passed. That would ensure that your community version and the Hashicorp proprietary version would stay more in sync, which would be good for Hashicorp as well, as they can then benefit from contributions to the community version as well.

If Hashicorp choose to stick by 4 years as the Change Date, then you should demand a justification for that other than "that's the default of the BUSL license". In practice a 4 years Change Date for Terraform is far too long to be useful in practice and far longer than Hashicorp can justify.

I believe adding a number in the main page showing the total number of people and companies signing the manifesto is a good idea.

I guess adding links of opentf to other social media platforms will help to broadcast the message on a wider range

Rename OpenTF to OpenTofu in the whole Repo (wherever applicable)

Since we already have more than 2K people supporting our cause, why not start a project for creating an IAAS tool which is completely open source and has no licence issue?

So many projects and companies are at stake if we could pull this off even in an year we could save the community from upcoming hassles .

If people just donate an hour of their time every day to this project we could soon have a useful product.

Despite nearly 30K stars, I can't find OpenTF in GitHub's search results when searching for "terraform"

Rename OpenTF to OpenTofu in the whole Repo

Since Fireship.io's Video about the OpenTF movement tonight, OpenTF has been getting Github Stars by the second!
So I thought instead of changing it manually, we can just dynamically change the star count using some basic JS scripts.

Not sure which repo is the right one to post this, currently HashiCorp have the terraform website with all its documentation and registry, is there an intention for OpenTF to have its own documentation site and more importantly a common nodule\provider registry.

I feel its important that OpenTF should not have any reliance on HashiCorp moving forwards as who knows they might change the license or start charging to have things listed in their registry

Let's have a similar documentation too for Opentofu ;ike you have terraform docs

• What if HashiCorp changes how they interpret competitive? -> competitive to competition.
• the ability to use the project in their own projects or businesses, to republish modified source, -> source to sources.
• HashiCorp switching it back to a truly open source license or by us forking it into a foundation -> by us forking to by forking
• And that's not even counting the thousands of other providers in the Terraform Registry that built -> that built to that were built
• Reasearch typo to Research
• opensource typo to open-source

The sponsor button is missing.

Updating the amount of stars in the repository for 3.8k

See here:

The sharing social media icons on index.html page had some opacity settings already. A hover effect can be added to enlarge them on hover.

Though I'm still trying to figure out everything, I thought multi language version of this manifesto could help users to understand what's going on. If' that'll help, there's a quick translated version of Traditional Chinese below, please feel free to use it.

OpenTF 宣言

Terraform 於 2014 年以 Mozilla 公共授權（v 2.0）（「MPL」）開源。在接下來的大約 9 年裡，它建立了一個社群，包括數千名使用者、貢獻者、客戶、認證從業人員、供應商，以及一個開源模組、外掛、函式庫和擴充套件的生態系統。然後，在 2023 年 8 月 10 日，幾乎沒有提前通知或讓社群大部分人有任何參與的機會下，HashiCorp 將 Terraform 的授權從 MPL 更改為商業原始碼授權（v1.1）（「BSL」），一個非開源授權。我們認為，這一變化威脅到在過去 9 年間圍繞 Terraform 建立起來的整個社群和生態系統。

我們的擔憂：BSL 授權是 Terraform 的毒藥。

一夜之間，數以萬計的企業，從個人小店到財富 500 強，都醒來發現他們的基礎設施的基礎突然成為潛在的法律風險。BSL 和 HashiCorp 團隊撰寫的額外使用授權非常模糊，現在每個使用 Terraform 的公司、供應商和開發人員都必須擔心他們所做的是否可能被解讀為與 HashiCorp 的產品競爭。常見問答提供了一些對最終客戶和系統整合商的安慰，但即使你現在可能沒問題，你如何能夠確信你的使用不會在未來違反授權條款呢？如果你的產品或 HashiCorp 的產品改變了呢？如果 HashiCorp 改變了他們如何解釋競爭呢？如果他們再次更改授權呢？因此，使用 Terraform 的一切都處於不穩定的地基上。

我們清楚地看到，在新授權下，圍繞開源 Terraform 建立起來的蓬勃生態系統將會萎縮和凋零。隨著開發人員考慮學習哪些工具和貢獻哪些生態系統，以及公司考慮使用哪些工具來管理他們的基礎設施，越來越多的人將選擇真正的開源替代方案。現有的 Terraform 程式碼庫將變成過時的負擔，獨立的工具將幾乎消失，社群將分裂和消失。

這種變化也損害了所有類似的開源專案。每個公司和每個開發人員現在都需要三思而後行，以防建立者突然決定更改授權。想像一下，如果 Linux 或 Kubernetes 的建立者突然切換到僅允許非競爭使用的非開源授權。

我們相信，現代網際網路的基本元件，例如 Linux、Kubernetes 和 Terraform，需要真正開源：這是確保我們在堅固和可預測的基礎上建立我們的產業的唯一方法。

我們的目標：確保 Terraform 始終真正開源。

我們的目的是將 Terraform 返回到完全開源授權。BSL 不是開源，所以這意味著將 Terraform 返回到 MPL 授權，或者一些其他眾所周知、廣泛接受的開源授權（例如，Apache License 2.0）。此外，我們希望確信 Terraform 將永遠保持開源，所以你不必擔心另一個突然的授權更改將一切置於危險之中。

我們對 HashiCorp 的要求：將 Terraform 切換回開源授權。

我們要求 HashiCorp 為社群做正確的事情：不要繼續使用 BSL 授權，而是將 Terraform 切換回真正的開源授權，並承諾永遠保持這樣。這樣，我們不是分裂社群，而是得到一個單一、公正、可靠的 Terraform 之家，整個社群可以團結起來，繼續建立這個了不起的生態系統。

我們的備案：將 Terraform 分叉到基金會。

如果 HashiCorp 不願將 Terraform 切換回開源授權，我們建議將遺留的 MPL 授權 Terraform 分叉並在基金會中維護。這類似於 Linux 和 Kubernetes 是由基金會（Linux 基金會和 Cloud Native Computing Foundation）管理的，這些基金會由多家公司運營，確保工具始終真正開源和中立，而不受任何一家公司的任性支配。

特別是，我們想為 Terraform 建立一個基金會，即：

• 真正開源 - 在一個公司可以信任的、未來不會突然改變的、不受單一供應商任性支配的、眾所周知和廣泛接受的授權下
• 社群驅動 - 以便社群為社群管理專案，定期審查和接受拉取請求的價值
• 公正 - 以便根據對社群的價值接受有價值的功能和修復，而不考慮對任何特定供應商的影響
• 分層和模組化 - 具有對程式設計師友善的專案結構，以鼓勵在其基礎上進一步開發，促使新的工具和整合的生態系統蓬勃發展
• 向下相容 - 以便現有程式碼可以在未來幾年內繼續創造價值

支持的公司和承諾資源的清單：

我們承認，維護像 Terraform 這樣的開源專案需要大量的時間、技能、努力和協調投資。我們感謝 HashiCorp 建立 Terraform 並帶領它走到這一步，也感謝數千名社群成員迄今為止的貢獻。Terraform 的下一步必須是保持開源，無論是 HashiCorp 將其切換回真正的開源授權，還是我們將其分叉到基金會。無論結果如何，我們都必須確保有足夠的投資來發展和演變 Terraform。因此，下面的簽署人承諾共同投入資源，共同為開源 Terraform 建立更開放、包容的未來。

如果你願意加入我們的行動，請透過在此頁面底部建立 PR 並新增自己來簽署宣言，並可選地讓我們知道你想以個人或組織身份提供什麼幫助。

承諾公司

• Gruntwork
• Spacelift
• env0
• Scalr
• Digger
• Doppler
• Massdriver
• Qovery
• Rivet
• Terramate
• Terrateam
• Verifa
• Finisterra

聯絡我們

如果你是社群成員、新聞界人士、HashiCorp 員工，或有任何問題或回饋要分享的人，你可以透過向 [email protected] 傳送電子郵件與我們背後的團隊聯絡。

分享

August 14th, 2023

Overnight, tens of thousands of businesses, ranging from one-person shops to the Fortune 500 woke up to a new reality where the underpinnings of their infrastructure suddenly became a potential legal risk. The BUSL and the additional use grant written by the HashiCorp team are vague. Now, every company, vendor, and developer using Terraform has to wonder whether what they are doing could be construed as competitive with HashiCorp's offerings. The FAQ provides some solace for end-customers and systems integrators today, but even if you might be in the clear now, how can you build confidence that your usage won't violate the license terms in the future?

The goal of Hashicorp is clear -- prevent 3rd party providers from offering their own products and charge for it without Hashicorp gaining anything. In fact, you can even use Terraform to build and host a product that's competitive to Terraform, using Terraform v1.6+! As long as what you're building and commercially offering doesn't share Terraform v1.6+ source code. This is clarified in their FAQ:

The BSL license does not prevent developers from using our tools to build competing products. For example, if someone built a product competitive with Vault, it would be permissible to deploy that product with Terraform. Similarly, if someone built a competitive product to Terraform, they could use Vault to secure it. What the BSL license would not allow is hosting or embedding Terraform in order to compete with Terraform, or hosting or embedding Vault to compete with Vault.

This means, their license change to BSL 1.1 actually doesn't affect 99% of Terraform users in any way. But the way you've worded it (esp. in the paragraph I quoted above) seems to be aimed at causing undue alarm among your readers. Firstly, even though you point out that Hashicorp's "FAQ provides some solace", you've conveniently not linked to the said FAQ, which would have actually helped a reader to become more informed.

Please make an effort to provide a more balanced perspective on the situation, and help your readers be informed on the subject by encouraging them to read Hashicorp's original announcement and its associated FAQ.

They've made the video private, but there's a nice transcript of it here:
https://www.ignw.io/blog/2019/faq-hashicorp-open-source

"All the major projects that we have at HashiCorp are open source ..."

and

"... all major innovation in the infrastructure space has tended towards open source ..."

I recently started a fork from tag v1.5.5 of Terraform.

However, there are a fair number of commits after 1.5.5 release, but before the license change that are not included: Magnitus-/opentofu@main...hashicorp:terraform:main

Roughly, there are almost 300 commits between the v1.5.5 tag and the license change.

We could:

• Go from the latest possible commit
• Go from tag v1.5.5

I like going from tag v1.5.5 because we know it is reasonably stable and then we can cherry-pick any of the later commits as needed even though it might be a little more work to reconcile afterwards.

Any thoughts?

There are two invite links to the OpenTF Slack in the manifesto that are no longer valid:

https://github.com/opentffoundation/manifesto/blob/ba197da1cff8df3ff519428dd8b31d904eeb8ddf/fork.html#L91
https://github.com/opentffoundation/manifesto/blob/ba197da1cff8df3ff519428dd8b31d904eeb8ddf/fork.html#L125

Giving this is going to be forking Terraform is this also going to fork the other Hashicorp tools or just Terraform?

I would rather see a foundation take over all of the Hashicorp tooling chain and not just Terraform.