Terraform vs OpenTofu — ライセンス変更(BSL)と分岐の顛末

2023年8月、HashiCorpはTerraformのライセンスをMPL 2.0からBSL 1.1へ変更しました。コミュニティはOpenTofuとして分岐し、Linux Foundation傘下に入っています。この顛末を一次情報で整理し、日本の実務者がどう判断すべきかを考えます。

01何が起きたのか — 3行で

まず全体像を押さえます。2023年8月、HashiCorpはTerraformを含む主要製品のライセンスをオープンソースのMPL 2.0(Mozilla Public License)からBSL 1.1(Business Source License)へ変更すると発表しました。これに反発したコミュニティが最後のMPL版Terraformをフォークし、2023年9月にLinux Foundation傘下のプロジェクト「OpenTofu」として発足。両者は当面互換を保ちつつ、別々に進化していく——というのが顛末です。

本記事は、HashiCorp・OpenTofu・Linux Foundationの一次情報をたどりながら、「で、うちはどっちを使えばいいのか」という日本のSIer/エンタープライズの実務判断に落とし込みます。ライセンスの話は感情論になりがちですが、実務者に必要なのは事実と選択基準です。

02BSLとは何か — MPLとの決定的な違い

HashiCorpの発表(2023年8月10日)によれば、変更後もエンドユーザーは「非商用・商用を問わずコードのコピー・改変・再配布ができる。ただしHashiCorpへの競合提供(competitive offering)を除く」とされています。裏を返せば、Terraformを組み込んで競合するホスティング/マネージドサービスを提供するベンダーは、以後のリリース・バグ修正・セキュリティパッチを取り込めないということです。

ここで多くの実務者が最初に不安に思うのが「自社のCI/CDでTerraformを回すのも違反か?」という点です。HashiCorpの整理では、社内利用や自社インフラの構築・運用のための利用は制限対象ではなく、あくまでTerraformそのものを競合製品として第三者に提供する行為が制限されます。とはいえ「競合(competitive)」「組込み(embedded)」の定義解釈は個社の事情に依存するため、判断はライセンスFAQと自社法務での確認が前提です。

現場のコツ：「BSL = もう使えない」は誤解です。大半の一般ユーザーにとって日常運用の実害は小さい。問題になるのは、(1)IaCを製品として外販/SaaS提供している、(2)Terraformをホスト実行するプラットフォームを他社に売っている、といったcompetitive offeringに該当しうる事業者です。自社がどちらの立場かをまず切り分けましょう。

MPLとの決定的な違いは、BSLがOSI承認のオープンソースライセンスではない点です。「ソースは見えるが、特定用途が制限される(source-available)」というカテゴリで、この一点がコミュニティの反発の核心になりました。

03コミュニティの反発とOpenTofuの誕生

発表直後、有志が「OpenTF Manifesto」を公開し、HashiCorpに決定の撤回を求めました。撤回がなされなかったため、2023年8月25日にMPL版Terraformのフォークが宣言され、OpenTofu(当初OpenTF)としてスタート。2023年9月20日、プロジェクトはLinux Foundationに受け入れられ、名称もOpenTofuに落ち着きました。

ここで重要なのはガバナンス設計です。OpenTofuはLinux Foundationの下で、Gruntwork・Spacelift・Harness・env0・Scalrといった複数企業の代表からなる技術運営委員会(TSC)によって運営されます。単一企業が方向性を支配できない構造にすることで、「またライセンスを変えられるのでは」というリスクを構造的に排除する狙いです。2024年1月にはOpenTofu 1.6のGA(一般提供)がLinux Foundationからアナウンスされました。

図：MPL→BSL変更を起点に、TerraformとOpenTofuが分岐した経緯。

04互換性の現在地 — どこまで「乗り換え可能」か

OpenTofuは最後のMPL版(1.5系)からのフォークとしてスタートしたため、初期のバージョンはTerraformと高い互換性を保っていました。OpenTofu側も後方互換性を重視し、既存の.tfコード資産が長く価値を持ち続けることを設計目標に掲げています。実際、多くの環境ではterraformコマンドをtofuに置き換えるだけで動く、というのが初期の触れ込みでした。

ただし2024年以降、両者は独自機能で差が広がりつつあります。OpenTofuはステート暗号化(state encryption)を独自機能として先行実装しました。一方、プロバイダ定義関数(provider-defined functions)はTerraform 1.8(2024年4月10日)が先にGA提供し、OpenTofuは1.7.0(2024年4月30日)で後追い対応しています。両者ともそれぞれ独自の進化を続けています。したがって「完全な相互互換」という前提は年々弱くなると考えるべきです。実務では以下の点が乗り換えの摩擦になります。

プロバイダ/モジュールのレジストリ：OpenTofuは独自レジストリを持ちます。既存の参照先やミラー設定の見直しが必要です。
バージョン固有の新機能：片方でしか動かない構文を使うと、もう片方へ戻れなくなります。移行期は共通部分に留めるのが安全です。
周辺エコシステム：CI/CDプラグイン、静的解析、ポリシー系ツールの対応状況は個別確認が必要です(公式で要確認)。

現場のコツ：移行検証は「本番のステートを直接触らない」のが鉄則です。既存ステートのバックアップを取り、サンドボックスでplanの差分がゼロになることを確認してから切り替えます。ステート運用の勘所はIaCのステート管理、ドリフトの監視はドリフト検知もあわせてご覧ください。

05IBM買収という新しい変数

選定を考えるうえで無視できないのが、2024年4月に発表され2025年2月に完了したIBMによるHashiCorp買収(約64億ドル)です。TerraformとVaultはIBMの自動化ソフトウェアポートフォリオの一部となりました。これは実務者にとって両面の意味を持ちます。

プラス面：大手ベンダーの傘下に入ることで、エンタープライズ向けサポート・調達・保守の安定性という観点では説明しやすくなります。日本の大手企業ではベンダーの継続性が調達要件になることが多く、IBMという後ろ盾は稟議上の安心材料になり得ます。
不確実性：買収後の製品戦略・価格体系・ライセンス方針が今後どう動くかは、現時点で確定しているわけではありません。価格や提供形態は公式で要確認とし、中長期の前提に固定しないことが賢明です。

06企業としての選び方 — 3つの判断軸

感情論を脇に置き、実務判断の軸を3つに絞ります。自社の状況をこのマトリクスに当てはめてください。

図：既存資産・サポート・リスクの3軸で選定を整理する。

既存資産：すでに大量の.tfを運用しているなら、慌てて移行する理由はありません。BSLは内部利用を強く制限するものではないためです。新規案件では、片方に依存しすぎない書き方(共通構文への集約)を心がけると将来の選択肢が残ります。
サポート/調達：商用SLAやベンダー保証が調達の必須要件なら、IBM/HashiCorpの商用オプションが説明しやすい。一方でOSSとしての中立性・コスト・ロックイン回避を重視するならOpenTofuです。OpenTofuにも商用ベンダー(Spacelift、env0等)によるサポートエコシステムが存在します。
リスク：自社事業がcompetitive offeringに該当しうる(IaCを外販/SaaS提供している)なら、BSLは事業リスクそのものです。この場合OpenTofuが有力候補になります。逆に単一ベンダーへの依存を許容できるかも、裏側の判断軸です。

07日本のSIer/エンタープライズへの含意

日本の現場特有の論点を挙げます。第一に稟議と説明責任。「なぜOSSではなくBSLの製品を使うのか」「なぜ主流のTerraformではなくOpenTofuなのか」——どちらを選んでも、社内・顧客への説明が求められます。本記事のような一次情報に基づく整理は、その説明資料の土台になります。

第二にマルチクラウド/マルチアカウント統制との関係です。大手企業ではTerraform/OpenTofuは単体で使われるより、アカウント発行・ガードレール・権限設計と一体で運用されます。ツール選定はIaC単体でなく、統制基盤全体の設計思想の中で決めるべきです。この観点はマルチアカウント統制もあわせてご検討ください。

現場のコツ：「今すぐどちらかに全振りする」必要はありません。多くの日本企業にとって現実的なのは、(1)既存資産はそのまま、(2)新規は中立に書ける設計、(3)四半期ごとに両者の動向とライセンスFAQを再確認、という様子見しつつ選択肢を残す戦略です。焦って移行してデグレを招くのが最悪手です。

第三にパイプライン設計との整合です。どちらを選ぶにせよ、plan/applyをCI/CDに組み込む勘所は共通します。実行基盤の設計はIaCのCI/CDパイプラインを参照してください。ツール名が変わっても、審査・承認・ステート保護の設計原則は変わりません。

—まとめ

Terraform vs OpenTofuは「善悪」の話ではなく、ライセンスと事業リスク、サポート、既存資産のトレードオフの話です。BSLは大半の内部利用者に致命的な制限を課すものではなく、影響が大きいのは競合提供に該当しうる事業者です。OpenTofuはLinux Foundation傘下の複数企業ガバナンスで、単一ベンダー依存を避けたい組織に選択肢を提供します。IBM買収という新しい変数も含め、前提は動きます。だからこそ、一次情報で事実を押さえ、自社の3軸(既存資産・サポート・リスク)で冷静に判断することが実務者の役割です。

—参考(一次情報)

自社のIaC資産をTerraform/OpenTofuどちらに寄せるべきか、既存構成とサポート要件を踏まえた棚卸しをご支援します。お問い合わせください。

相談する

← ブログ一覧へ戻る