プロダクトのライセンスを選択するということ

GPL をはじめ、いろいろなオープンソースライセンスがありますが、オープンソースライセンスを、ほんとうにざっくり大ぐくりすると、「自由に改変して自由にタダで使っていいですよ」というようなライセンスです。

オープンソースとは何か、という説明については各所にとても沢山の解説がありますので、ここでは割愛します。

オープンソースプロダクトへのフリーライド

近年、オープンソースプロダクトにフリーライド(ただ乗り)している輩が増えてけしからん、という議論が巻き起こっています。

参考記事:Redis、MongoDB、Kafkaらが相次いで商用サービスを制限するライセンス変更。AWSなどクラウドベンダによる「オープンソースのいいとこ取り」に反発

上記記事から引用すると、

オープンソースプロジェクトにとってサービスで得られる収入は、大事な資金源となり得ます。しかし現実は、あるオープンソースプロダクトが人気になると、コミュニティにはまったく、あるいはほんの少しだけしか貢献していない大規模クラウドベンダがあっさりとその大部分を獲得していくのです。結果として、小規模な企業はこうした大規模クラウドベンダの戦略的な利益の対象になることを望まず、多くの新しいソフトウェアがクローズドソースとして開発されています。

つまり、コミュニティにはまったく、あるいはほんの少しだけしか貢献していない大規模クラウドベンダが大きな利益を得て、大きく貢献している者はほとんどその利益を得ることが出来ない、という現状に不満を抱いてライセンスを変更した、ということです。

Amazon は ECサイトとして有名で、第2四半期で13億ドルの純利益(監査ずみ数値ではない)を上げています。
すさまじい金額でどのぐらいなのかちょっと理解できないほどですが、クラウド事業の方ではさらに大きな16億ドルの営業利益を上げています。
引用元:https://jp.techcrunch.com/2018/07/27/2018-07-26-amazons-aws-continues-to-lead-its-performance-highlights/
※1

Amazon だけでなく、MicrosoftAlibabaGoogle なども同様にオープンソースプロダクトを利用したクラウド事業で大きな利益を上げています。

どのような意図でオープンソースプロダクトを開発しているのかにもよりますが、一般的にみて、これでは現状に不満を抱くのは当たり前です。
開発した者は開発に対する貢献か金銭による報酬が得られるのが、あるべき姿でしょう。

しかし、GPL ライセンスでは貢献や利益を得ることができるとは限りません。
誰でも自由に使えることを保証するライセンスだからです。

ですので、貢献や金銭的利益を確実に得たい、得られるべき、と考えるソフトウェアについては、GPL は何の役にも立ちませんし、GPL を選択するべきではないでしょう

そこで、RedisMongoDBKafka などのオープンソースプロダクトではライセンスを変更することにしました。
私はこの動きを全く非難する気持ちはありません。
どのようなライセンスを選択するかは、(基本的には ※2)デベロッパーの自由だからです。
プロダクトがどのように使われるかを規定できるのでは、デベロッパーであるべきでしょう。

どのようなライセンスに変更されたか

では、上記の各ベンダーはどのようなライセンスに変更されたのでしょうか。

どのベンダーも似たライセンスに変更されており、その趣旨について Redis の Redis Labs’ Modules License Changes という公式発表から翻訳して引用してみます。

しかしやがて、MongoDBやConfluentのような他の評判の高いオープンソース企業が、オープンソースのライセンスに対するモダンな変種の独自の提案を作成した。各社は異なるアプローチをとったが、いずれも同じ目標を共有していた。つまり、クラウドプロバイダが他の企業によって開発されたオープンソースプロジェクトを採用したり、プロプライエタリなサービスにパッケージ化したり、市場の力を利用して大きな収益源を創出したりすることを阻止したのである。

※Thanks to みらい翻訳

ターゲットはあくまでクラウドサービスベンダーだ、ということです。
同じような内容の表明は、ライセンス変更を実施した他のプラダクトからもリリースされています。

Kafka

Kafka のコアにあたる「Apache Kafka」には引き続き Apache 2.0 というオープンソースライセンスが適用されます。
Confluence が管理している REST Proxy、Schema Registory などのプロダクトについて、新しいライセンスが適用されます。
変更後のライセンスに含まれる具体的な制約事項は Confluent Community License を見てみます。

ライセンシーには、除外された目的のためにライセンスを行使する権利は付与されず、ライセンシーはこれを行使してはならない。本契約の適用上、「目的外」とは、本ソフトウェアを提供するConfluent製品またはサービスと競合する、software-as-a-service、platform-as-a-service、infrastructure-as-a-service、またはその他類似のオンラインサービスを利用可能にすることをいいます。

*****-as-a-service という記述が特徴的です。
プロダクトをそのままサービスとして提供してはいけません、というライセンスです。
他の2つのプロダクトでも、言葉を変えて同じような制約になっています。

Redis

Redis のコアは BSD というオープンソースライセンスです。
RediSearch、RedisGraph などの Redis 由来のオリジナル部分のソフトウェア群が Redis Source Available License Agreement (PDF)に変更されています。

ソフトウェアまたはソフトウェアへの変更はアプリケーションの一部としてのみ使用することとし、配布されたデータベース製品または、第三者によってその他の方法で使用可能になったデータベース製品との接続には使用できません。

Redis は一種のデータベース製品なので、そのままデータベースとして提供する、あるいは競合するデータベース製品に組み込んで使用することを制限する内容です。

MongoDB

MongoDB は含まれているプロダクトの一部についてライセンスを変更している他のプロダクトと違い、MongoDBをサービスとして利用しようとする場合は Server Side Public License (SSPL) という新しいライセンスが適用されます。

SSPLはMongoDBをサービスとして提供したい人は誰でも、あるいはこのライセンスを使っている他のソフトウェアであれば誰でも、商用ライセンスを取得するか、サービスをオープンソース化してコミュニティに提供する必要があると明示的に述べています。

※Thanks to みらい翻訳

MongoDBをサービスとして提供するならお金を払うか、製品をオープンソース化してコミュニティに貢献する、としています。

ライセンスの選択

このようなライセンスの変更によって、全てのプレイヤーが使用に見合った支払いをし、正当な貢献や利益を得られるわけではありません。
すでにプロダクトに多大な貢献をしているクラウドベンダーが存在した場合、そのクラウドベンダーは全く利益を得ることができなくなります。
また、コミュニティはクラウドベンダーからの貢献を受けることが出来なくなります。

しかし、それらのデメリットやメリットを含めて、デベロッパーの選択なのです。
オープンソースライセンスを選択してプロダクトやエコシステム、コミュニティの成長に注力するのか、利用に制限を設けてある程度利益を得やすいライセンスを選択するのか。
そのような選択の自由があるにもかかわらず、フリーライドだと利用者だけを批判だけするのには違和感があります。
GPL というオープンソースライセンスには「あなたは、物理的に複製物を譲渡するという行為に関して手数料を課しても良い」と明確に規定されています。
そのライセンスを選択したのはデベロッパーなのです。

私の周辺、WordPressでは

私は近年、Webサイトを構築する会社に勤務しており、よく WordPress という GPL ライセンスのオープンソースプロダクトを利用しています。

この WordPress 周辺のプラグインやテーマといったプロダクトについて、「転売する輩が出てくる」「GPLプロダクトを有償で売る敵」「タダで使われるとデベロッパーが損をする」などという意見を見かけることがあります。

プロダクト全体を GPL で(100% GPL と呼ばれています)リリースすることを選択しているのはデベロッパーです。
WordPress 周辺のプロダクトにおいて、プロダクト内の一部を GPL ではないライセンスとすることは許されて(※3)います。

ですので、デベロッパーの場合は上記のような批判的な意見を言ってもいいかもしれませんが、現状に不満があるのであれば、ライセンスの変更を検討してはどうでしょうか。
ライセンスを変更したくないのであれば、マーケティング上の努力をすることも検討されてはどうでしょうか。
あるいは、寄付をお願いしすることもできます。

デベロッパーではなく、応援しているプロダクトに対して上記のような批判を持っている場合には、先にも書きましたが、100% GPL を選択したのはデベロッパーなのです。
注意深く 100% GPL を選択しているデベロッパーは、そのプロダクトをタダで使われたり転売されることを想定・受容した上でリリースし、利益を得たい場合にはマーケティング活動や寄付の依頼を行っており、無料での使用を批判する気も無いでしょう(もちろん、お金を払って使って欲しいでしょうが)。
一方、第三者が上記のような批判をすることについて、デベロッパーはどのように思うでしょうか。
「応援してくれてありがとう」と思うのでしょうか。
なんとなく GPL を選択しているデベロッパーは、なんとなく嬉しいかもしれません。

結論のようなもの

私は、デベロッパーが正当な貢献や金銭的利益を得られたらいいな、と思っています。
100% GPL を選択したデベロッパーは金銭的利益を得られなくても仕方ない、とも思っていません。
ですので、フリーライドについての批判は、感情的には理解できます。

しかし、デベロッパーは(基本的には)プロダクトのライセンスを選択する自由があります。
プロダクトのリリースにあたってライセンスを選択する際に、そのライセンスを適用したらどうなるかを真剣に考えた方が良いと思います。

私はフリーライドしたいと思っていませんし、喜んで自分が利用しているオープンソースプロダクトに貢献したいと思っていますので、WordPress の Core 開発やサポートフォーラム、翻訳、プラグインの開発などでコミュニティに貢献しています。
ところが、私はその他にも多数のオープンソースプロダクトを利用しており、それによって利益を得ている場合もあります。
プロダクトの例としては、Linux、GNUツールチェーン、Apache、nginx、MySQL、MariaDB、Chromium、FireFox、Git、Subversion、OpenJDK、Elasticsearch、Apache Lucene(Elasticsearch の中で使われている) その他使っていることに気づいてもいないプロダクト。
気が遠くなります。
あるいは、オープンソースかちょっと分かりませんが Let’s Encrypt、Wikipedia など。

これらについて、今のところ感謝の念以外の貢献はできていないませんが、このような私の行為はフリーライドだと批判する向きもあります。

これらのプラダクトに貢献したいのはやまやまですが、現実問題、全てのプロダクトに貢献することはできません。
これをフリーライドというなら、私が知っている(知らない人も)ほとんどの人がフリーライドに含まれてしまいます。
私はこのような批判は極端なものだな、と思います。
そもそも、オープンソースで公開する目的の一つは広く使ってもらうためなのではないでしょうか。
ですので、オープンソースソフトウェアをタダで使われるとでデベロッパーが損をする、というものも極端な批判だと思います。

フリーライドという批判は、デベロッパーが想定していなかった使用方法で利益を上げている場合によく聞かれるように思います。
現在はオープンソースソフトウェアベンダーとクラウドベンダー双方が正解を模索している段階と言えるかもしれませんが、現在は制約のあるライセンスに変更するのが主な流れになっているようです。

※1
純利益と営業利益の比較数値ですが、Amazon はどこにも税金を納めていないらしいので双方で似たような数字じゃないんですかね、会計に強くないので間違っているかもしれませんが。


※2
コピーレフトって何?
https://www.gnu.org/licenses/copyleft.ja.html

以下引用

そのソフトウェアを再配布する人は、変更してもしなくても、それをコピーし変更を加える自由を一緒に渡さなければならない

要するに、GPL が適用されたプロダクトやその派生物を配布する場合には、GPL で配布しなければいけない、という決まりです。

GNU 一般公衆利用許諾契約書 バージョン2 (非公式日本語訳)

以下引用

6. あなたが『プログラム』(または『プログラム』を基にした著作物全般)を再頒布するたびに、その受領者は元々のライセンス許可者から、この契約書で指定された条件と制約の下で『プログラム』を複製や頒布、あるいは改変する許可を自動的に得るものとする。あなたは、受領者がここで認められた権利を行使することに関してこれ以上他のいかなる制限も課してはならない。あなたには、第三者がこの契約書に従うことを強制する責任はない。


※3
※2に記述しているように、GPL ライセンスを持つプロダクトの派生物にも GPL ライセンスを適用する必要があります。
一方で、WordPress においては、プロダクトに含まれる PHP 以外の画像、CSS などについては GPLライセンスを適用しないことが許容されると考えられています。
Themes are GPL, too
https://wordpress.org/news/2009/07/themes-are-gpl-too/

以下、一部を引用・翻訳

WordPress テーマの PHP は GPL である必要があるが、画像や CSS はそうではない。

しかし、WordPress コミュニティでは好ましくない方法、と捉えられています。

テーマやプラグインなどが「画像やCSS」も全て含めて GPL でない場合には、公式ディレクトリに登録できない(ダッシュボードで選択することできない)、そのようなプロダクトの制作者はWordCamp などのコミュニティイベントで登壇者・ボランティア・スポンサーになれないといった制約が生じます。

Agreement among WordCamp Organizers, Speakers, Sponsors, and Volunteers

そのようなコミュニティでの不利益を受けないために 100% GPL が選択されているのであれば、それはやはりデベロッパーの選択です。
この制約があるから 100% GPL を選択せざるを得ない、という意見もありますが、その制約を作ったのは WordPress コミュニティであり、使用者には何の関係もありません。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です