OSSとライセンスの悩ましい関係。HelmとCommunity Compactの動向に注目
オープンソースソフトウェアは文字通り、ソースコードを公開して、だれでもアクセスできるようにすることで、そのソフトウェアを使おうとする企業には多大な利益を与えている。その一方で、開発やメンテナンスに関わるデベロッパーは、直接的に利益を得られていないという不合理さが生じている。
つまり、クローズドなソフトウェアであればソフトウェアの売り上げによってコードを書いたエンジニアには報酬が与えられるが、オープンソースソフトウェアの場合、ソースコードを売ることで直接的に利益を得ることをできない。MicrosoftやRed Hat、Googleなどの大規模な企業には、オープンソースソフトウェアに対する貢献を専任とするエンジニアが存在するが、彼らが得る報酬は他部門の利益を還流させていると言える。
これ以外のユニークなケースとしては、ZabbixやCloud Foundryの例が挙げられる。Zabbixの場合、ソースコードはオープンだが、コードを書くのはZabbixの社員が中心で、ユーザー企業は必要なソフトウェアをZabbixに発注して有償で開発をしてもらうことで利益を産んでいる。またCloud Foundryの場合、コードはオープンだが、コントリビューターになるためにはPivotal Labの高価なペアプログラミングの研修を受ける必要がある。
このように特異なケースはあるが、民間企業が開発したコードをオープンソース化しても開発に関わるエンジニアに利益を還元することは難しく、利用者の増加を求めてコミュニティの拡大に腐心するのが施策の中心となる。エコシステムとして利益を産む構造にするには、Red Hatのようにサポートを有償化してそこから利益をあげる方法、巨大な組織を保持し、利益を産む別部門から還元する方法、オープンコアとしてコアの部分はオープンソース、付加価値の部分はクローズドにして付随するソフトウェアから利益をあげる方法などが考えられる。
OSSのライセンスに関する新たな動き
そんな中、オープンソースソフトウェアに関して新しい動きがあった。1つ目はKubernetesのサブプロジェクトとして運営されていたHelmが、CNCF配下の独立したプロジェクトになったことで、コントリビューター向けのライセンススキームが変わったというニュースだ。これはKubernetesが採用するCNCF Contributor License Agreement（CLA）から、より簡易なDeveloper Certificate of Origin（DCO）に変更を行い、コントリビューターがもっと簡易にコードの提供を行えるようにするものだ。
DCOへの移行のアナウンス
そして2つ目がChefのCTO、Adam Jacob氏が提案するオープンソースプロジェクトにおける新しいコミュニティのエコシステムを提案する「Community Compact」である。Chefは、構成管理ツールのChefやライフサイクル管理ツールのHabitatの開発元として知られている。Community Compact提案の背景には、Redis LabがRedisのアドオンモジュールのライセンスを変更したことがあると思われる。
CLAからDCOへの変更
まずHelmのCLAからDCOへの変更について説明しよう。Helmのライセンス変更は、面倒な法的書類に関する手続きを簡易化することで様々なデベロッパーをコミュニティに集めるのが目的だ。Kubernetesが採用するCLAは、日本のオープンソースに関わるエンジニアからも「あのままではパッチを書きたくても二の足を踏む」と表現されるほど面倒であるという。その意味では、HelmがKubernetesから分かれて簡単にコードを提供できる仕組みを採用したのは、コミュニティを拡大したい他のプロジェクトにも参考になるだろう。特にGitのコミットコマンド（$ git commit -s）を使うことで、デベロッパーにとっては馴染みやすい仕組みとなっている。
Redis Labsのライセンス変更とその反響
次にAdam Jacob氏の提案について解説しよう。そのためにはまずRedis Labsが行ったライセンスの変更について説明しよう。これはRedis Labsが開発をリードするキーバリューストアのデータベース管理システム、Redisについて、本体はそのままBSDライセンスでオープンソースとするものの、Redis Labsが開発するアドオンなど（RediSearch、Redis Graph、ReJSON、Redis-ML、Rebloom）についてはApache 2.0の上に「Commons Clause」を追加して、それらのモジュールの商用サービスへの利用を防ぐように変更したのだ。
ChefのCTO、Adam Jacob氏
Redis Labsのブログポストを読むと、AWSやAzureなどのクラウドサービスプロバイダーに対する強い不満が読み取れる。つまり彼らは、自社のサービスのためにオープンソースソフトウェアを利用し、それをサービス化することで収益を上げていながら、対象となるオープンソースソフトウェアの開発には貢献せず、タダ乗りを続けている、というのが主張である。そのためコアの部分はそのままオープンソースとするが、アドオンモジュールについてはその機能をパッケージして販売し、コンサルティング、ホスティングなどの商用には使えないとするというのが、今回のRedis Labsのライセンス変更の主旨だ。
確かにAWSもAzureもGCPもそこでユーザーがメモリーやCPUを消費してくれれば課金ができるわけで、その上でLinuxが動こうがWindowsが動こうが関係ないだろう。そして面倒なアップグレードやパッチの適用などをユーザーに代わって肩代わりすることで、ユーザーは利便性を得られる。クラウドプロバイダーとユーザーの勝利だが、開発を行うデベロッパーには何の利益も落ちてこないのはおかしい、という主張だ。
これに関してAnsibleの開発者であるMichael DeHaan氏は、自身のブログで意見を表明した。
Why Open Source Needs New Licenses
この中でDeHaan氏は、Redis Labsの判断には理解を示しつつも、今回のRedis LabsのようにCommons Clauseで縛ることをせずに、そのソフトウェアでユーザー企業から一定の利益を得る方法を提案している。
DeHaan氏のブログポスト
Adam Jacob氏によるCommunity Compactの提案
しかしChefのCTO、Adam Jacob氏は別の提案を行っている。ここでは、その内容を紹介しよう。
上記はJacob氏のブログの投稿だが、Jacob氏はGitHubでも同様の内容を保存しており、コメントや修正のリクエストを送れるようになっている。
https://github.com/adamhjk/community-compact
要約すると、Community Compactはライセンスの用語で商用利用の可／不可を規定することから、オープンソースソフトウェアを開発するコミュニティに視点を移した発想だ。
Jacob氏のGitHubでの記述の箇条書きの部分を要約すると、以下のようになる。
- ソフトウェアのライセンスはOSIが設定したものであれば可
- 著作権は設定されるのではなく相互に許諾される
- 商用利用はコミュニティとソフトウェアを持続させる目的として実行される
- 商用利用をする企業は商標を登録することができる（例：Red Hat Enterprise Linux）。その場合、クラウドプロバイダーなどのネットワークサービスやコンサルティング企業は商標を使ってビジネスを行うことができるが、その許諾はソフトウェアのライセンスで規定するのではなく、商標のポリシーと配布ライセンスによって規定される
- 商用利用したい企業は、コミュニティによって開発されたソフトウェアと全く同一のディストリビューションを作ることができる。その場合、ビジネスでの利用の規定は受けないが、道徳的もしくは倫理的規制を受ける
- その規制とは商用利用した企業の名前を「FREELOADERS」というファイルに記述することができることである
- しかしその企業にコントリビューターがいれば、その記述の例外とすることができる
- ソフトウェアのライセンスを販売することも可能
- もしも自社にコントリビューターが存在せず「FREELOADERS」への記述を免れたい場合は、年間1USドルの費用を負担するか、ソフトウェアのメンテナーの3/4以上の賛成を得る必要がある
- もしもビジネスを行う企業がコミュニティにとって悪い影響を与えていることが判明した場合、商標の利用を停止されることができる。その場合、ビジネスを行う企業は商標を使うことができず名称を変更する必要がある
ここから分かるのは、ソフトウェアの利用ライセンスではなく、商標の利用ポリシーと配布のためのライセンスを新たに作ることで、ライセンスの条項には手を入れずにビジネスで利用したい企業にとって選択肢を与えていることだ。企業が「タダ乗りをしている（FREELOADERS）」というフラグを立てられることを防ぐためには、コントリビューターを雇うか、費用を負担するかのどちらかを選ぶ必要がある。つまりどちらの場合も「コミュニティが持続する」ことを最優先して設計されていることが分かる。
この提案がオープンソースコミュニティに支持されるかどうかは不明だが、ライセンスの文言で縛るために必要となる法的作業を減らし、代わりに「コミュニティを持続させるために何をするべきか？」を考えるきっかけとなるだろう。前述のHelmによるCLAからDCOへの変更もコミュニティを拡大させるための施策であり、コミュニティがオープンソースソフトウェアにとって重要であるということを考えされられた。今後もCommunity Compactには注目していきたい。
