「Open Source Summit Europe」で、LFがTerraformの代替となる新プロジェクト「OpenTofu」を発表

こんにちは、吉田です。今回は、9月19日から3日間、スペインのビルバオで開催された「Open Source Summit Europe」において、Linux Foundationから発表された新プロジェクト「OpenTofu」の内容を紹介します。

【参照】Linux Foundation Launches OpenTofu: A New Open Source Alternative to Terraform
https://www.linuxfoundation.org/press/announcing-opentofu

OpenTofuはInfrastructure as Code(IaC)のプロビジョニングツールとして広く使われている「Terraform」の代替となるプロジェクトで、ライセンスはMPLv2(Mozilla Public License v2.0)を採用しています。これは、2023年8月にHashiCorpがTerraformのライセンスをMPLv2からBSL/BUSLv1.1(Business Source License v1.1)に変更したことに対する、コミュニティ側からの回答とも言える動きになります。

BSLv1.1は最初にMariaDBが採用したライセンスで、ソースコードは誰でも入手可能です。複製・改変・派生ソフトウェアの作成・再頒布が許されていますが、基本的に商業的利用を許していないため、OSI(Open Source Initiative)が定義しているOSSライセンスの定義から逸脱しています。その他には、Couchbase、Cockroach Labsなどが採用しています。

今回のようなライセンス変更は、HashiCorpが初めてではなく、下表のように2018年頃から行われてきたものです。

そもそも、AWSのようなクラウドプロバイダーがこれらのOSSを活用してサービス提供し始めたことに対して、いわゆる「フリーライド」的な利用を制限することを目的に、このようなライセンス変更がなされました。この動きはいったん落ち着いたように見えましたが、また2021年頃にAWSとElasticの論争で再燃し、その他のOSSにも飛び火した形になりました。

さて、このような背景もあり、今回のOpenTofuプロジェクトでは、下記のようなゴール設定をしています。

• 真にオープンソースであること
  企業が信頼でき、広く受け入れられやすいライセンス(MPL)を採用すること、および、そのライセンスが単一ベンダーの気まぐれに左右され、突然変更されることのないようにする。
• コミュニティ主導であること
  コミュニティがコミュニティのためにプロジェクトを管理し、プルリクエストが定期的にレビューされ、そのメリットに応じて受け入れられること。
• 公平であること
  特定のベンダーへの影響に関係なく、コミュニティにとっての価値に基づいて価値ある機能や修正が受け入れられるようにする。
• 階層化されたモジュールであること
  プログラマーに優しいプロジェクト構造で、レイヤー化、モジュール化され、その上に構築することを奨励し、ツールや統合の新しい活気あるエコシステムを可能にする。
• 後方互換性があること
  既存のコードで今後何年にもわたって価値を高めることができる

また、すでに147の企業や730人以上の個人がこの活動へのサポーﾄを表明しており、少なくとも今後5年間はLinux Foundationで最低18人の開発者がフルタイムで開発に取り組むことが確約されています。

Open Source Summit Europeの基調講演で、Linux Foundationのエグゼクティブディレクターを務めるJim Zemlin氏が紹介した内容が興味深かったので、ここで紹介します。

この基調講演の中で、独フリードリヒ・アレクサンダー大学エアランゲン・ニュルンベルク校のDirk Riehle教授が執筆した論文「The Future of the Open Source Definition」を引用する形で、新しいオープンソースの定義を解説しました。

この論文では、現在のオープンソースの定義について扱われていない重要な側面として「プロジェクトのガバナンス」があると指摘しています。ここで、ガバナンスとは「プロジェクトがどのように運営されるか」「どのように決定がなされるか」「誰が貢献できるか」などのプラクティスとプロセスのことで、従来のオープンソースの定義は成果物のみを対象としています。つまり「ソフトウェアがどのように開発されているか」については言及していないということです。

そこで、オープンソースソフトウェアの黎明期の大半は共同で開発されるものであるという考えでしたが、現在ではさまざまな形で開発されています。ソフトウェア開発プロジェクトは、下図のように分類されます。

ソフトウェア開発プロジェクトの分類 【出典】The Future of the Open Source Definition

この中で問題になるのは「Vendor-owned open source」です。1980年代、ソフトウェアベンダーは、オープンソースであることで顧客が抵抗なく足を踏み入れる入口になる素晴らしい方法だと発見し、自社製品をオープンソースで提供していました。マルチライセンスの手法を用いれば、同じソフトウェアをオープンソースでも商用ライセンスでも利用できるようになります。そのため、そのようなベンダーはオープンソースに貢献する可能性のある開発者に対して、その貢献に対する権利をベンダーに譲渡することを要求していました。このような製品は、成熟することでオープンソース戦略の意義が失われていくと考えられ、これらのベンダーの背後にいるベンチャーキャピタルの収益性と投資収益率を高める必要性が支配することになると考えるのが一般的です。

今回のOpenTofuプロジェクトは、このような動きに対抗するものとして、あくまでも「Community Open　source」として活動を続けることで、オープンソースの本来の価値を追求できると思います。このプロジェクトの今後の発展を期待したいですね。