タグ: オープンソース

[著者：Salil Deshpande]

Bain Capital Venturesのマネージング・ディレクターを務めつつ、インフラ・ソフトウエアとオープンソースに強い関心を持つ。

 

地平線に暗い雲が現れた。Amazonなどのクラウドインフラ・プロバイダーは、オープンソースの存続を脅かそうとしている。私は、以前、この問題を初めてTechCruncの記事で報告した。嬉しいことに、2018年になってから、何人かの指導的立場にある人たちが集結して論議を行い、いくつもの解決策を提示してくれた。ここに、先月の動きを紹介しよう。

問題

Amazon Web Services（AWS）の画面上部にある「Products」メニューにポインターを合わせると、Amazonが開発したものではないがサービスとして提供されているオープンソース・プロジェクトがたくさん現れる。これらは、Amazonに年間数十億ドルの収益をもたらしている。誤解のないように言っておくが、違法ではない。しかし、オープンソース・コミュニティーの存続と、とくに商業ベースのオープンソースのイノベーションに貢献することはひとつもない。

2つの解決策

2018年の初めに、私は20社ほどの大手オープンソース企業のクリエイター、CEO、相談役を集め、オープンソースに詳しいことで名高い弁護士Heather Meekerも加えて、どうすべきかを話し合った。

私たちは、クラウドインフラ・プロバイダーが特定のソフトウエアを商用サービスとして使うことを禁止し、同時に、そのソフトウエアを実質的にすべての人に対してオープンソースにする、つまり、商用サービスではない形で誰もが使えるようにするライセンスを規定したいと考えた。

私たちの最初の提案「Commons Clause」（共有条項）は、もっとも直接的なアプローチだった。これは、もっとも自由で寛大なオープンソース・ライセンスに追加できる条項で、ソフトウエアの「販売」を禁止するものだ。ここで言う販売には、商用サービスとしての提供も含まれる（Common Clauseソフトウエアで作られた別のソフトウエアの販売は、もちろん許される）。Common Clauseを追加すれば、オープンソースから生まれたプロジェクトは、Source-available（ソース利用可能）に変更される。

私たちはまた、別の参加者であるMongoDBが先頭に立って提案されたServer Side Public License (SSPL)も素晴らしいと感じた。ソフトウエアをサービスとして提供することを禁止するのではなく、管理ソフトウエア、ユーザーインターフェイス、アプリケーション・プログラム・インターフェイス、自動化ソフトウエア、モニタリング・ソフトウエア、バックアップ・ソフトウエア、ストレージ・ソフトウエア、ホスト・ソフトウエアなどを含むがそれに限られないサービス提供のためのソフトウエア開発に使用したすべてのプログラムをオープンソース化し、すべてのユーザーはこのサービスのインスタンスを実行できるというものだ。これは「コピーレフト」と呼ばれている。

これらは、まったく同じ問題に対する2つの解決法だ。Heather Meekerは、FOSSAでまとめられた意見を元に、この2つについて解説している。

当初、この努力に対して、コミュニティーを「欺く」ものだという騒ぎや避難が起こったが、それはむしろオープンソース・コミュニティーが解決を必要とする深刻な問題を抱えていることを世間に知らしめ、オープンソース・コミュニティーはそろそろ現実を直視すべきであること、そして、インターネット巨大企業は、彼らが中心的に利用しているオープンソースの相応の代償を支払う時期に来ていることを理解してもらうという、よい方向に転じた。

10月には、Apacheソフトウエア財団（ASF）の役員から連絡があり、業界の需要に応える新しいオープンソース・ライセンスを一緒に作ろうと提案された。

MongoDBに拍手

SSPLの使用を明言し、それと並行して、オープンソース・ライセンスの認証を受けるためにSSPLをオープンソース・イニシアチブ（OSI）という組織に提出したが、その承認を待たずにSSPLライセンスのもとでソフトウエアの販売を開始したMongoDBの行動は称賛に値する。

OSIは、何がオープンソースで何がそうでないかを「判断」する神聖な立場にあると自認しているため、オープンソースか否かの視野の狭い論議に陥りがちだ。OSIへのSSPLの提出により、MongoDBはOSIのコートにボールを投げ込んだ形になる。OSIは、果たして問題解決のために一歩前進するか、それとも砂の中に頭を埋めてしまうか。

しかし実際は、MongoDBはOSIに大きく貢献している。MongoDBは、自ら問題を解決し、完璧に実用的なオープンソース・ライセンスを銀の盆に載せてうやうやしくOSIに差し出したからだ。

神聖なるオープンソース

SSPLに関するOSIの論議の公開記録は、ときに有益な内容を含み、ときに楽しく、滑稽に感じられることもある。最初にMongoDBがSSPLを提出したとき、OSIのメンバーたちは、SSPLはオープンソース・ライセンスではないと囃し立て、その理由を探しまくった。その後に賛同する声も加わった。しかし、メンバーのひとりJohn Cowanは、彼らにこう言い聞かせた。OSIがオープンソースとしてライセンスを認証しなかったとしても、それがオープンソースではないとする理由はない。

私が知る限り（それは非常に広範に及ぶが）、それはOSIの仕事ではない。OSIが公的に「ライセンスXはオープンソースではない」と発言したことはない。メーリングリストの人々はそうしてきたが、OSIは違う。「私たちのOSI Certified リストにないライセンスは、いかなるものもオープンソースではない」などとも言わない。なぜなら、それは間違いだからだ。だが、明らかにオープンソース・ライセンスであるにも関わらず、なんだかんだと理由をつけてOSIが認定しないというのは、あり得ることだ。

Eliot Horowitz（MongoDBのCTOで共同創設者）は、質問、コメント、反対意見について丁寧に対応し、次のように結論付けた。

要するに今の世界では、リンクは、プログラムをサービスとして提供する方式に取って代わられ、ネットワークを通じてプログラムがつながることが、プログラムの組み合わせの基本的な形になっていると思う。既存のコピーレフトのライセンスが、こうした形態のプログラムの組み合わせに明確に適用できるかは不確かだ。そこで私たちは、この不確かさに対処するために、開発者にひとつのオプションとしてSSPLを提示したいと考えている。

OSIの目的、役割、妥当性に関する議論が数多く重ねられた。そして、Van Lindberg、McCoy Smith、Bruce Perensから、いくつかの法的な問題が提示された。

そこへHeather Meeker（Commons ClauseとSSPLを起草した弁護士）が歩み出て、それまでに課題とされていた法律上の問題を完全に解決した。また、その他の解釈もEliot Horowitzによって明確にされ、必要ならばライセンスの表現を変更する意思を示した。

OSIの役割、妥当性、目的に関するメンバー同士の議論は続いたが、そのひとりが鋭い指摘をした。グループの中には「フリーソフト」支持者が大勢いて、オープンソースの質を貶め、新しい指針を打ち出そうとしているという。

もしOSIが、フリーソフトの組織として生まれ変わることを決意したなら、そして「我々」の仕事がフリーソフトであり、「我々」の主眼がフリーソフトにあるなら、名称を「フリーソフト・イニシアチブ」に変更して、すべての人に門戸を開くべきだ。彼らは完全にオープンソースなのだから、彼らに仕事を譲れば、誇りを持ってやってくれる。:-)

SSPLは、ユーザーのタイプで差別をしていないかという議論がある。それはオープンソースの質に関わる問題だ。Eliot Horowitzは、そうではないと、説得力のある説明をしている。それで人々は黙ったように見えた。

Heather Meekerは、法的な知識をグループの人々に与えた。それが問題の解決に大いに役立ったようだった。いわゆるオープンソースの定義の第6条を書いたBruce Perensは、SSPLは第6条にも第9条にも抵触しないと認めた。それに続いて彼は、SSPLが違反となるように第9状を改訂することを提言した。

私たちは、この問題ために自刃などしない。OSD #9は2つの言葉で修正でき、役員が集まり次第「執行」できる。それにしても面倒だ。

実績あるオープンソースの弁護士Kyle Mitchellは、そうした戦術に反対している。Larry Rosenは、一部のメンバーの主張（いかなる目的であっても、すべての人がプログラムを使えるというのがオープンソースの基本である）は真実ではないと指摘した。OSIの目的とオープンソースの意味に関する面白い議論はまだ続く。

Carlos Pianaは、SSPLが実際にオープンソースである理由を簡潔に述べた。Kyle Mitchellは、SSPLのときと同じ方法でライセンスを審査するなら、GPL v2もオープンソースではなくなるとも指摘している。

世論の高まり

一方、データベース企業ScyllaDBの創設者Dor Liorは、SSPLとAGPLを付き合わせて比較し、こう異論を唱えた。「MongoDBは、もっとうまくCommons Clauseをやるべきだった。そうでなければ、ぐっと堪えてAPGLで我慢すべきだった」と。インメモリー・データベースの企業Redis Labsが、RediSearchと4つの特別なアドオン（Redis自体は含まない）をCommons Clauseライセンス化した後、Player.FMは、Common ClauseライセンスのもとでRediSearchを使いサービスを開始した。グラフデータベースの企業Neo4Jは、コードベース全体をCommons Clauseライセンス化して8000万ドル（約90億8400万円）のシリーズE投資を獲得した。

さらに、 Red Hat Ansibleを開発したMichael DeHaanも、新しいプロジェクトにCommons Clauseを選択した。彼は、オープンソースに関してOSIが「認定」した既存のライセンスを選択しなかった理由を、次のように語っている。

彼らのツイッターや誇大広告の大騒ぎの後、OSIのことはどうでもよくなった。あれは政治的な資金集めの団体だよ。

この2018年のうねりは、修正すべきは業界側の問題であることを示す証拠となった。

Eliot Horowitzは、すべての問題を要約して対処した後、発言を止めて、しばらく遠ざかった。SSPLがオープンソース・ライセンスのすべてのルールに従っているように見えていたとき、そしてメンバーの支持を集めていたときは、Brad Kuhnは、なぜOSIは必要に応じてルールを変更して、SSPLがオープンソースであると思われないように対策しないのかという的はずれな議論を一歩前に進め、こうまとめた。

「ライセンス評価の過程」には、本質的な欠陥があるようだ。

Mitchelは、明確な論拠をあげてSSPLがオープンソースであるという議論に決着を付けた。Horowitzは、改訂案に対して意見や不満を述べてくれたメンバーに礼を言うと、数日後、改訂版SSPLを発表した。

OSIには、MongoDBが新しい申請を行った後、60日以内に次の決断を下すことになった。

1. 目を覚ましてSSPLが確かにオープンソース・ライセンスであることを認める（わずかな変更は許される）。
2. OSIには業界の問題を解決する意思はないと世界に公表し、政治オタクとなって理論的な議論に終始する。

ここで言うオタク（wonk）は、最良の道だ。

Wonk：[名詞]（口語）政治的方策のささいな事柄に必要以上にこだわる人のこと。

重要なのは、MongoDBが、いずれにせよSSPLの使用を推進するということだ。MongDBがOSIの決断を待つとなると、つまりOSIがなんらかの貢献をするならば、私たちはOSIがSSPLをオープンソース・ライセンスであると認めるか否かを、息を殺して見守ることになる。

目下のところ、OSIの決断は、業界のためというより、OSI自身のためのものだ。それは、OSIが業界の問題解決に協力する方向性を保つか、重箱の隅をつつくだけの役立たずの団体になるかを表す指標になるからだ。もし後者だった場合に備えて、私たちはリーダーシップのある他の団体に目を配り、彼らが業界のニーズに応える新しいオープンソース・ライセンスの創設を目指すときのために、Apacheソフトウエア財団（ASF）と話をしてきた。

SSPLをオープンソースだと認めるなら、それはOSIにとってよいことだが、それは決定打にはならない。John Cowanの言葉を思い出して欲しい。OSIがそのライセンスをオープンソースだと認めなくとも、オープンソースではないという理由にはならない。私たちは、さまざまな業界団体のほぼすべてのメンバーと、彼らがそれぞれの分野で重ねてきた努力に対して、大きな尊敬の念を抱いているが、自分たちを、個々のライセンスがオープンソースかどうかを「判断」する特別な存在だと思い上がっている人たちを尊敬するのは難しい。それは独裁的で、時代遅れだ。

正誤表

この問題をいち早く解決して欲しくて業界に発破をかけるつもりで、以前の記事にこう書いてしまった。「ある人が、どこかの別の人が開発したオープンソース・ソフトウエアを使って、文字通り自分だけが儲かる商用サービスを始めること」（クラウドインフラ・プロバイダーがしているように）は、オープンソースの「精神に反する」と。ちょっと言い過ぎた。率直に言って、正しい表現ではない。オープンソースの理念にこだわる人たちは、そう主張するだろう。私は彼らに喧嘩を売るつもりはないが、「精神の中にあるもの」からは距離を置いて語るべきだった。私の記事の本当の意図がぼやけてしまった。

結論

クラウドインフラ・プロバイダーの振る舞いは、オープンソースの存続を脅かした。しかし、クラウドインフラ・プロバイダーは悪ではない。現在のオープンソース・ライセンスは、元になったオープンソース・プロジェクトやそれを育てて来た人たちへの見返りを支払うことなく、 言葉どおり、それを利用できるようにしている。問題は、クラウドインフラ・プロバイダーの勝手を防ぐ、開発者のためのオープンソース・ライセンスが他にないことだ。オープンソースの標準化を行う団体は、それを邪魔するのではなく、助けるべき立場にある。私たちは、オープンソース・ソフトウエアの開発者が死なずに済むだけでなく、繁栄できる道を確保しなければならない。そのために、クラウドインフラ・プロバイダーに対してもっと強く出られる方法が必要ならば、開発者には、それを可能にするライセンスを用意するべきだ。オープンソース・コミュニティーは、これを最優先課題として早急に取り組まなければいけない。

おことわり

私はMongoDBには、直接、間接を問わず投資はしていません。私は、以下のオープンソース・プロジェクトに携わる次の企業に、直接または間接の投資をしています。Spring, Mule、DynaTrace、Ruby Rails、Groovy Grails、Maven, Gradle、Chef、Redis、SysDig、Prometheus、Hazelcast、Akka、Scala、Cassandra、Spinnaker、FOSSA、そして……Amazon

[原文へ]

（翻訳：金井哲夫）