從 BSL 震盪到狀態加密：OpenTofu 的開源抗爭與技術突圍

在雲端基礎設施即程式碼（Infrastructure as Code, IaC）領域，HashiCorp 於 2014 年釋出 Terraform，長年被視為實質上的控制平面標準。藉由宣告式的 HashiCorp 設定語言（HCL）與外掛驅動架構，它奠定了現代多雲編排的基石。

然而，2023 年 8 月 10 日，HashiCorp 宣布變更核心授權：旗下包含 Terraform 在內的專案，不再沿用寬鬆的 Mozilla 公共授權條款 2.0（MPL 2.0），改採具商業限制的商業原始程式碼授權條款 1.1（BSL 1.1）。

這項轉變直接衝擊了圍繞 Terraform 建立的自動化生態。為了維持開源標準，社群在數週內啟動專案分叉，並在 Linux 基金會託管下成立了 OpenTofu。

授權模式轉向：BSL 震盪與 TACOS 商業夾擊

在授權變更前，Terraform 採用弱互惠（weak copyleft）的 MPL 2.0 授權。該條款允許任何個人與企業免費將程式碼用於商業用途、散布執行檔，甚至封裝至專有軟體中，僅要求對 MPL 原始檔案本身的修改維持公開。這種高度自由造就了龐大的全球生態。

HashiCorp 切換至 BSL 1.1 的核心機制包含三個面向：原始程式碼維持公開可讀、設定四年後自動轉回開源授權的變更條款，以及最具爭議的附加使用限制。

該條款明文規定：禁止將授權軟體用於提供與 HashiCorp 旗下產品或服務產生「實質競爭」的託管服務或商業產品。

開源倡議組織（OSI）隨即明確指出，BSL 違反了開源定義第 6 條「不得歧視任何應用領域」的準則。因此，BSL 屬於「原始程式碼可用（Source-Available）」授權，而非開放原始碼。

HashiCorp 之所以轉向，根源在於商業化產品面臨外部生態的夾擊。Terraform 本質上是本機 CLI 工具，團隊協作仰賴狀態儲存與自動化管線。

市場上應運而生了一批專門提供遠端狀態協作與環境管理的平台，統稱為 TACOS（Terraform Automation and Collaboration Software），代表廠商包括 Spacelift、env0、Scalr 與 Gruntwork 等。

這些廠商以開源的 Terraform CLI 為核心，開發出在功能與彈性上媲美甚至超越 Terraform Cloud 的商業服務。與此同時，公有雲巨頭藉由社群 Provider 帶動龐大雲端用量，卻毋需向 HashiCorp 支付授權費用。

面對公開市場的獲利壓力，HashiCorp 認定商業夥伴在「免費搭便車」，試圖透過授權條款精準打擊競爭者。

然而，該條款表面上瞄準 TACOS 競品，實質上卻引發了廣大企業使用者的恐慌。由於「實質競爭」的最終定義權完全掌握在 HashiCorp 單方面手中，企業自行建置的內部開發者平台（IDP）、委託外部顧問交付的維運腳本，或雲端代管服務（MSP），都可能隨時落入模糊的侵權灰色地帶。

《OpenTF 宣言》與基金會託管：將控制權還給社群

面對單一商業實體的授權施壓，生態鏈廠商迅速意識到抗爭必須制度化。2023 年 8 月 15 日，在 HashiCorp 發布公告僅五天後，Gruntwork、Spacelift、env0、Scalr 與 Harness 等團隊共同發表了 《OpenTF 宣言》。

宣言呼籲 HashiCorp 撤回決定，並宣告若限期內未獲正面回應，社群將正式分叉專案並捐贈給中立基金會，承諾永久開源。短短數週內，該宣言獲得超過 140 家企業與逾 600 名工程師的連署支持。

2023 年 9 月初，在確認 HashiCorp 無意撤回決策後，專案正式啟動分叉。為了迴避商標法律風險，社群放棄「Terraform」與過渡期名稱「OpenTF」，於 2023 年 9 月 20 日定名為 OpenTofu，正式加入 Linux 基金會。

加入 Linux 基金會具備關鍵戰略價值：專案的智慧財產權與商標歸屬中立非營利法人，任何單一發起廠商都無權私自變更授權。專案採用 MPL 2.0 授權，並進一步銜接雲原生運算基金會（CNCF）生態。

在治理架構上，OpenTofu 成立了 技術指導委員會（TSC），席次由不同廠商代表與獨立維護者共同分擔。重大功能變更全面導入 意見徵求（RFC） 流程，由全球社群公開審查。

承接既有生態：維持二進位相容、自建 Registry 與化解版權爭端

Terraform 最龐大的資產是既有生態，包含全球數千個 Provider 驅動器與公開模組。OpenTofu 要想站穩腳跟，必須在技術層面達成百分之百相容。

在架構設計上，Terraform 核心引擎（Core）與 Provider 外掛各自獨立運作，並未編譯在同一個二進位檔中。兩者是各自獨立的本機行程（processes），透過行程間通訊（IPC）實體隔離。

核心與 Provider 在本機建立 Unix Domain Socket（Windows 上則走本機 TCP 迴路連線），藉由 go-plugin 框架以 gRPC 協定與標準的 Protobuf 介面溝通。

正因為兩者純粹以網路協定溝通，Provider 根本不在乎通訊對象換成了 OpenTofu。只要 OpenTofu 精確相容了 Protocol Version 5 與 Version 6，無論是由雲端原廠或社群維護的 Terraform Provider 二進位檔，完全毋需重新編譯即可直接於 OpenTofu 執行，完整延續了底層生態。

然而，二進位相容解決了執行問題，卻面臨下載通路的封鎖。2023 年 8 月 24 日，HashiCorp 修改了官方 Terraform Registry 的服務條款，明文規定該 Registry 內容「僅限搭配 HashiCorp 官方產品使用」（solely for use with, or in support of, HashiCorp Terraform），實質上封鎖了分叉專案與第三方客戶端。

若 OpenTofu 預設向官方 Registry 發出請求，將面臨直接的民事訴訟風險；但若無法下載 Provider，使用者執行 tofu init 便會拋出錯誤中斷。

面對通路防堵，OpenTofu 團隊採取了雙軌戰略：

首先，團隊建立了獨立中立的 registry.opentofu.org。該服務不轉送 HashiCorp 流量，而是直接追蹤各 Provider 在 GitHub Releases 等公開平台的發行載點。OpenTofu CLI 在背後透明映射，使用者現有設定中的 hashicorp/aws 等宣告完全毋需手動修改，即可繞過官方 Registry 的限制條款正常下載。

第一軌解決了公開生態的生存問題，第二軌則著眼於企業內部製品管理的現代化。團隊在 OpenTofu 1.10 進一步引進開放容器倡議（OCI）標準，依據 OCI Distribution Spec 支援模組以容器製品散布，Provider 亦能以 oci_mirror 作為次要安裝來源：

module "vpc" {
  source = "oci://ghcr.io/my-org/infrastructure-modules/vpc?tag=v1.2.0"
}

這項架構讓企業可以直接沿用現有的內部容器儲存庫（如 Harbor、GitHub Packages 或 AWS ECR），毋需額外架設專用 Registry 伺服器。

除了通路防堵，分叉專案還必須抵擋版權法律戰的考驗。OpenTofu 以 MPL 2.0 授權時期的 Terraform 程式碼為基礎分叉（1.5.7 是最後一個 MPL 2.0 穩定版本），並對貢獻者建立嚴格的乾淨室防火牆。

然而在切換至 BSL 後，HashiCorp 於 Terraform 1.7 推出了用於標記資源移除的 removed 語法；當 OpenTofu 隨後也實作相容功能時，HashiCorp 於 2024 年 4 月發出停止侵權函（C&D），指控其核心開發者抄襲並不當使用 BSL 授權的程式碼。

面對指控，OpenTofu 團隊在 Linux 基金會法務協助下公開原始碼溯源分析報告，以逐段原始碼溯源分析證明該實作源自更早期的 moved 區塊演進，成功化解法律危機。

補齊核心資安缺口：OpenTofu 1.7 客戶端狀態加密

在 IaC 宣告式架構中，狀態檔（terraform.tfstate）是基礎設施的唯一真實來源。然而，該檔案長期存在嚴重的資安隱憂：所有敏感資訊皆以明文 JSON 儲存。

無論是資料庫的管理者密碼、TLS 私密金鑰，還是雲端 API 憑證，全都在狀態檔中清晰可見。過去官方建議仰賴儲存貯體（如 AWS S3）的靜態加密（SSE），但這僅防範實體硬碟遭竊；任何擁有讀取權限的工程師或 CI/CD 流程，下載後依然能閱覽完整機密。

2024 年 4 月 30 日發布的 OpenTofu 1.7，正式推出了社群期待已久的重大創新：原生客戶端狀態與計畫檔加密（Client-side State and Plan Encryption）。

這套機制在核心引擎內部建立了三層解耦模型，確保狀態資料在離開本機記憶體前已完全加密：

 +----------------------------------------------------+
 | 1. Key Providers (AWS KMS, GCP KMS, Vault, PBKDF2) |
 +----------------------------------------------------+
                           | 提供金鑰／KEK
                           v
 +----------------------------------------------------+
 | 2. Encryption Methods (AES-GCM-256, unencrypted)   |
 +----------------------------------------------------+
                           | 對目標套用加密方法
                           v
 +----------------------------------------------------+
 | 3. Consumers (state, plan, remote_state)           |
 +----------------------------------------------------+

1. 金鑰提供者（Key Providers）：負責串接金鑰來源，涵蓋 AWS KMS、GCP KMS、Azure Key Vault、OpenBao（相容 Vault 1.14 MPL 版）與本機 PBKDF2。
2. 加密方法（Encryption Methods）：定義密碼學演算法，主流採用具備認證標籤完整性驗證的 AES-GCM-256。
3. 消費層（Consumers）：指定套用對象，除了常態狀態檔（state），更包含執行計畫二進位檔（plan）與跨專案引用（remote_state）。

在與雲端 KMS 整合時，由於 KMS 的單次呼叫通常有資料大小上限，且每次操作皆為跨網路往返，直接以 KMS 加密整份狀態檔會造成效能瓶頸。因此，OpenTofu 採用了密碼學標準的 信封加密（Envelope Encryption） 架構：

 +------------------------------------------
 | 寫入（Write）：
 | 1. 經 KEK 向 KMS 請求一次性 DEK
 | 2. 以明文 DEK 對狀態內容執行 AES 加密
 | 3. 從記憶體丟棄明文 DEK
 | 4. 將 [加密後 DEK + 密文 + IV] 存入 S3
 +------------------------------------------
                     |
                     v
 +------------------------------------------
 | 讀取（Read）：
 | 1. 自遠端後端取回信封封裝
 | 2. 將加密 DEK 送回 KMS，以 KEK 解密
 | 3. 在記憶體中以 DEK 解密狀態內容
 +------------------------------------------

在這套架構中，OpenTofu 呼叫雲端 KMS 產生隨機且臨時的資料加密金鑰（DEK, Data Encryption Key），並利用本機 CPU 的硬體加速指令集（如 AES-NI），以取得的明文 DEK 快速執行 AES-GCM 狀態加密。

加密完成後，系統僅將經 KMS 託管的 金鑰加密金鑰（KEK, Key Encryption Key） 加密後的 DEK 封套打包存回後端，明文 DEK 隨用即棄、不落磁碟。使用者完全毋需在 HCL 中手動宣告 DEK。這種設計大幅降低了 API 延遲與呼叫成本，同時也在雲端稽核日誌留下精準存取紀錄。

為了讓現有專案平順轉換，OpenTofu 提供了靈活的 fallback 機制，容許在讀取舊明文狀態的同時，寫入時自動升級為強加密：

terraform {
  encryption {
    # 宣告雲端 KMS 金鑰提供者（KEK 來源）
    key_provider "aws_kms" "production_kms" {
      kms_key_id = "arn:aws:kms:us-east-1:123456789012:key/my-key-uuid"
      key_spec   = "AES_256"
      region     = "us-east-1"
    }

    # 定義 AES-GCM-256 對稱加密方法
    method "aes_gcm" "prod_aes" {
      keys = key_provider.aws_kms.production_kms
    }

    # 套用至狀態儲存並設定回退策略
    state {
      method = method.aes_gcm.prod_aes

      # 平滑遷移：容許讀取歷史未加密狀態，寫入時自動加密
      fallback {
        method = method.unencrypted.legacy
      }
    }

    # 同步套用至執行計畫檔（可選）
    plan {
      method = method.aes_gcm.prod_aes
    }

    # 定義過渡期未加密方法
    method "unencrypted" "legacy" {}
  }
}

設定中的 fallback 僅在「讀取」歷史狀態且主方法無法解密時生效，用來相容過去未加密的舊檔；「寫入」路徑則一律採用主方法加密，不會退回明文。待歷史狀態全數完成升級後，再移除 fallback 並改設 enforced = true，即可徹底禁止任何 unencrypted 方法存在於組態中。

透過這套「讀舊寫新」策略，團隊得以在零停機狀態下，讓數千個歷史專案在下一次執行 tofu apply 時無痛自動升級。

雙軌生態下的工具抉擇

2024 年 4 月，IBM 宣布以 64 億美元收購 HashiCorp，並於 2025 年初完成交割。在收購初期，開源社群曾寄望 IBM 能撤銷 BSL、促成專案重回開源社群；然而 IBM 最終選擇維持 BSL 授權框架，將 Terraform 與 Red Hat Ansible 深度整合成大型企業級混合雲方案。

這項決定消除了兩大專案重新合併的可能，雙方自此確立了各自獨立的發展路線。

面對目前的技術生態，企業在評估選用時可參考以下面向：

兩條路線各自滿足不同的市場需求：Terraform 走向大型企業統包與原廠商業支援，OpenTofu 則在中立基金會下，以二進位相容與狀態加密延續開放生態。