地平線に暗雲が立ち込めている。Amazonのようなクラウドインフラプロバイダーの行動は、オープンソースの存続を脅かしている。

[[243323]]

私は過去 13 年間にわたり、数多くのオープンソース プロジェクトを運営する企業に投資してきたベンチャー キャピタリストです。

• 春
• ラバ
• ルビーレール
• グルーヴィー
• 聖杯
• メイヴン
• グラドル
• レディス
• シスディグ
• ヘーゼルキャスト
• アッカ
• スカラ
• カサンドラ
• スピナカー
• その他の企業

オープンソースはすでに社会に貢献しており、オープンソースのビジネスモデルは非常に成功し、収益性も高まっています。

アマゾンの行動

Amazonの経営戦略には感心しています。ベンチャーキャピタル業界では、IBM、オラクル、HP、コンピュウェア、ジェネシス、EMC、VMware、Citrixといった大手ソフトウェア企業が主に巨大な販売・流通チャネルとして機能し、それらのチャネルを活性化させるにはイノベーション（つまりスタートアップ企業の買収）が不可欠というイメージが一般的です。しかし、Amazonは違います。2015年7月、ウォール・ストリート・ジャーナル紙は私の発言を引用し、「Amazonの経営戦略は非常に強力で、まるでスタートアップ企業のようだ。エコシステムに関わるすべての人にとって恐ろしい存在だ」と伝えました。同月、私は投資家向けウェブサイトSeeking Alphaに「Fear the Amazon Juggernaut」（https://seekingalpha.com/article/3333195-fear-the-amazon-juggernaut）という記事を執筆しました。この記事を執筆して以来、Amazonの株価は400%上昇しました。（私は間接的にAmazonの株式を保有しています。）

しかし、顧客以外の人にとって、Amazonは感情的な企業ではありません。多くの記事で、その冷酷な企業文化が詳しく取り上げられています。では、なぜオープンソースに対するアプローチは異なるのでしょうか？

AWSにアクセスし、上部の「製品」メニューにマウスを合わせてください。Amazonが開発はしていないものの、サービスとして運営されている無数のオープンソースプロジェクトが表示されます。これらのプロジェクトは、Amazonに毎年数十億ドルの収益をもたらしています。

例えば、AmazonはRedis（Stack Overflowの開発者アンケートで最も人気のデータベース）をほとんどフィードバックがないままサービスとして運用し、AWS Elasticacheとしてブランド名を変更しました。Elasticsearch、Kafka、Postgres、MySQL、Docker、Hadoop、Sparkなど、他の多くの人気オープンソースプロジェクトもAWS製品として提供されています。

これは違法ではないことに留意してください。しかし、私たちはこれが誤りであり、オープンソースコミュニティの持続可能な発展に有害であると考えています。

コモンズ条項

2018年初頭、私は20社以上の大手オープンソース企業（一部は上場企業）の創業者、CEO、またはチーフアドバイザーを集め、今後の対応について議論しました。3月には、この成果をGeekWireに発表しました。建設的で綿密な議論を経て、複数のオープンソースライセンスを混ぜ合わせるという形式的なやり方ではなく、こうした行為を禁止する簡潔な条項を策定すべきだという点で全員が合意しました。この条項の草案作成には、著名なオープンソース弁護士であるヘザー・ミーカー氏を招きました。

2018年8月、Redis Labsは、一部のアドオンの無料およびオープンソースライセンスに「Commons Clause」と呼ばれる新たな条項を追加することを発表した。Redis自体は引き続きPermissive BSDライセンスの下で提供され、Redis自体には変更はない。ただし、Redis LabsのアドオンにはCommons Clause（ソースコードを公開する条項）が含まれるものの、「販売」は許可されないため、商用サービスとして提供することはできなくなる。これは、クラウドインフラプロバイダーによる非倫理的な行為を明確に防止する狙いがある。

ゼネラルモーターズ（GM）やゼネラル・エレクトリック（GE）を含む他のすべての企業は、共通利用規約が適用されたとしても、これまでと同様にソフトウェアで行えるすべての操作を実行できます。ソースコードを閲覧・変更したり、マージリクエストを送信して製品に変更を加えたりできます。さらには、社内の従業員向けにソフトウェアをサービスとして提供することも可能です。共通利用規約は、クラウドインフラプロバイダーのように、商用サービスが他者のオープンソースソフトウェアと並行して実行されることを防ぎます。

当然のことながら、この発表はオープンソースコミュニティ内で激しい議論を巻き起こし、賞賛と批判が入り混じった。過度な単純化のリスクについては、賞賛する人たちは、これはオープンソースライセンスのあり方における合理的かつ前向きな進化であり、オープンソース企業がオープンソースプロジェクトに投資しながら事業を成功させることができると主張した。Ansibleの開発者であるマイケル・デハーンは、著書『なぜオープンソースに新しいライセンスが必要なのか？』の中で、特に次の点を指摘している。

オープンソースの「財団」やウェブサイトを運営する人々の中には、テレビのコメンテーターのように振る舞い、「オープンソース・イニシアチブ」のような組織が定義する「オープンソース」の定義について政治的な発言をする者もいる。これらの組織は多くのプロジェクトで一定の人気や支持を得ている。彼らは、ソースコードは無料で入手できるものの、利用例が限られているライセンスは「オープンソースではない」と主張しようとしている。残念ながら、この主張は既に現実のものとなっている。

中立的または反対の立場をとる人々は、共有規約によってソフトウェアがオープンソースではなくなると指摘しており、これは正しい。コードベースの一部を独自のものにすることはオープンソースの精神に反する。Redis Labs は明らかに行き詰まりに達しており、収益を上げるのは困難になるだろう。

まず、Redis Labs については心配しないでください。彼らは素晴らしい会社です。Redis はこれまで以上に強力で、より好まれ、BSD 準拠になっています。

さらに重要なのは、今日の環境において、オープンソースの精神を再考すべき時が来たということです。オープンソースが普及した当初は、実践者がオープンソースコミュニティに還元しながら、実験と改良を重ねていくことが想定されていました。当時、インフラをサービスとして提供する企業はなく、オープンソースプロジェクトをリパッケージ化し、名前を変えてサービスとして運営し、利益を上げながら、コミュニティへの還元をほとんど行わない企業もありませんでした。

オープンソースソフトウェアは、クラウドインフラ企業が取得して再販することを意図したものではないと私たちは考えています。それはオープンソース本来の精神ではありません。共有利用条項は、その本来の精神を復活させるものです。人気のあるオープンソースプロジェクトのコンポーネントを自身のアプリケーションに利用したい研究者、愛好家、開発者は、引き続きそうすることができます。しかし、他者が実際に開発した同じソフトウェアを、個人的な利益のためにサービスとして提供しようとすると、オープンソースコミュニティの精神に反します。

共通利用条項を例に挙げると、これはソースコードが厳密にはオープンソースではないことを意味します。しかし、オープンソース本来の精神を守るためには、これは許容しなければならないことです。

Apache + 共通用語

Redis Labs がリリースする一部のアドオンモジュールは、Apache Commons Agreement を使用しています。Redis Labs は、Commons Agreement を使用しているため、これらのモジュールはオープンソース製品ではないと明確に述べています。Redis 自体はオープンソースであり、BSD ライセンスの下でライセンスされています。

一部の過激なオープンソース支持者は、Redis Labs が「Apache」という単語を使用しているため、モジュールがオープンソースであるとオープンソースコミュニティに信じ込ませようとしていると非難している。

トリックはありません。共通条項は、あらゆる許容オープンソースライセンスに付加される補足条項です。様々なオープンソースプロジェクトが様々なオープンソースライセンスを使用しているため、共通条項でソフトウェアをリリースする際には、共通条項がどの許容オープンソースライセンスに付加されているかを明確にする必要があります。

AGPL を使用しないのはなぜですか?

このシナリオでAGPLを使用しない主な理由は2つあります。AGPLはオープンソースライセンスであるため、AGPLライセンスのコードをサービスとして使用する場合、変更を加えた場合は必ず公開する必要があります。

まず、AGPLはクラウドインフラプロバイダーが前述のような不正行為を行うことを単に困難にするだけで、それを防ぐものではありません。AGPLは、そのような行為を行った場合、プロバイダーが行った変更をすべて公開しなければならないと規定しているだけです。次に、AGPLのソフトウェア特許条項は不要であり、多くの企業に嫌われています。

私たちが投資した AGPL プロジェクトを持つ企業の多くは、AGPL の使用が企業ポリシーに違反するため、大企業からより許容度の高いライセンスに切り替えるよう要請を受けています。

バランスの道

クラウドインフラプロバイダーは悪い人ではなく、悪意を持って行動しているわけでもありません。オープンソースは常にバランスをとる手段でした。私たちの多くは、顧客や仲間がソースコードをレビューし、改善を行い、フィードバックを提供してくれることを信頼しています。誰かが自分の成果物を無料で配布し、見返りを求めるのは、常に信頼関係の飛躍です。プロジェクトによっては、このバランスがそれほど努力することなく自然に実現できる場合もありますが、そうでない場合もあります。特に、クラウドインフラプロバイダーがスタックの上流、つまりマスマーケット向けのコンピューティングやストレージから、より高度なインフラサービスへと移行することで差別化を図ろうとする中で、オープンソースインフラではこうした傾向がますます顕著になっています。

リビジョン

本稿執筆時点での共通利用規約のバージョンは1.0です。今後、共通利用規約の目的達成に向けて改訂・調整を行ってまいります。皆様からのフィードバックをお待ちしております。

これまで見てきた共通の用語に関する異なる見解は、実際にはイデオロギーの違いによるものです。批判の多くは、ソフトウェアで利益を上げることを目的としないオープンソース活動家から発せられています。彼らの哲学は異なりますが、彼らの仕事は政治活動家であり、企業に価値を生み出すことではないため、当然のことです。

共通規約が、メンテナンス、サポート、または専門サービスの提供を禁じていると誤解している方がいます。これは規約の誤った解釈です。共通規約はAGPLと矛盾すると主張する人もいます。共通規約はAGPLよりも寛容なオープンソースライセンスと組み合わせて使用​​されるように設計されているため、AGPLは不要です。しかし、AGPLが適用される場合でも、作者が開発したソフトウェア製品のユーザーで、作者による共通規約使用の意思表示を完全に無視することが賢明だと考える人はほとんどいないでしょう。

オープンソースを保護する

オープンソースのステークホルダーの中には、混乱している方もいます。どちらの側につくべきでしょうか？この共通規約は新しいものであり、議論は当然のことと考えています。この取り組みを支持する方々は、オープンソースの熱心な支持者です。私たちの目標は、オープンソースを存亡の危機から守ることです。オープンソース企業が利益を上げ、オープンソースが存続し、オープンソース開発者がその貢献に見合う報酬を得られるよう、他の方々も団結して共通規約を支持してくださることを願っています。

著者: サリル・デシュパンデ、ベインキャピタル・ベンチャー・パートナーズ マネージングディレクター