OSSを理解するうえで欠かせない「コピーレフト」の概念とは
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
オープンソースを理解する上で欠かせないのは、「コピーレフト」という考え方です。GNUプロジェクトの創始者であるリチャード・ストールマンがフリーソフトウェア運動の中で、熱心に普及を推進している考え方です。一般的にオープンソースライセンスは、この「コピーレフト」という概念で分類されます。
この「コピーレフト」という表現は、「コピーライト」の反対の用語ということで、パブリックドメインのように著作権を放棄しているように誤解される可能性もありますが、決してそうではなくあくまでも著作権は保持した状態になります。著作権を保持したままにすることにより、そのソフトウェアが自由(フリー)な状態を維持できるという考え方です。
GPLの「アプリケーションサービスプロバイダ(ASP)の抜け穴」
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
この考え方を具体的に実装したのが、GPL(GNU Public License)ということになります。上記の定義のように二次的著作物にもGPLが適用されなければならないと規定されているので、GPLのソースコードを一部でも使用したソフトウェアにはGPLライセンスが適用されるということになります。
しかしながら、このGPLにはいわゆる「アプリケーションサービスプロバイダ(ASP)の抜け穴」があります。これは、SaaSプロバイダなど主にネットワーク上で動作するソフトウェアでは、コピーレフト条項が適用されないという問題です。具体的には、GPLでは、ソフトウェアのライセンスの制約は頒布した時に発生すると考えられていますので、そのソフトウェアがサーバー上で動作している限り、ソフトウェア自体は頒布していることにあたらないので、ライセンスの制約が適用されないと考えられています。
AGPLの策定
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
この問題を解決するためにAfferro,Incが2002年3月にAGPLv1を策定しました。このAGPLv1はGPLv2をベースに作成されたものであったため、2007年にFSF(Free Software Foundation)がGPLv3をベースにAGPLv3(*1)をリリースしました。以下、AGPLと記述した場合、AGPLv3を表します。
AWSによる「strip-mining問題」
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
AGPLをめぐる問題が、2018年頃から顕在化してきました。AWSによる「strip-mining問題」です。発端は、「Redis」、「MongoDB」、「Kafka」が2018年に立て続けにライセンスの変更を発表しました。
まず、2018年8月に「Redis」の開発元であるRedis Labsは、Redis拡張モジュールのライセンス「AGPL」から「Commons Clause条項付きのApache 2.0」へ変更しました(*2)。ちなみに「Redis」自体はBSDライセンスです。Commons Clauseは既存のオープンソースソフトウェアライセンスに条件を加えることで、開発者の権利の保護を図るもの。土台のオープンソースライセンスの条件はそのままに、商用での販売に制限を設定するものになります。
これはAWSなどのクラウドプロバイダは、自ら開発していないオープンソースを活用したサービスの提供により、利益を得ていることに対する対抗策になります。AGPLでは、AWSなどのクラウドプロバイダがAGPLライセンスのコードを使用してマネージドサービスを構築することを妨げられないというのが一番大きな理由です。
また、2018年10月MongoDBは、ライセンスを「AGPL」から「Server Side Public License(SSPL)」へ変更すると発表しました(*3)。SSPLはAGPLをベースとしたライセンスですが、「当該ソフトウェアの機能をサービスとして提供する場合、その周辺ソフトウェア (管理用ツールなど) も公開しなくてはならない」という記述があり、実質的にマネージドサービス化を制限することになります。残念ながら、このSSPLはOSSライセンスを管理承認する団体であるOSI(Open Source Initiative)により承認されませんでしたので、正確にはMongoDBはオープンソースではありません。
しかし、AWSもMongoDBのこの変更に黙っているわけはなく、2019年1月にMongoDB互換のサービスである「Amazon DocumentDB」というサービスを発表しました。このサービスで提供されるのは、2019年当時の最新のMongoDBのバージョン4.0ではなくMongoDB 3.6互換のAPIでした。しかも内部的にはMongoDBをそのまま使ったサービスではなく、AWS独自のデータベースを基盤としてMongoDB 3.6 APIをエミュレーションしているとされています。
この他にも、「Kafka」や「CockroachDB」などもライセンス変更を行いましたが、次にご紹介する「Elastic」とAWSとの間では、さまざまな問題が発生しました。
Elastic vs AWS
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
2021年1月にオープンソースの検索・分析エンジンである「Elasticsearch」の開発企業であるオランダのElasticが、この「Elasticsearch」とデータ可視化ダッシュボードである「kibana」のライセンスを「Apache License 2.0」から、商用サービス化を制限する「Server Side Public License」（SSPL）と「Elastic License」のデュアルライセンスへ変更することを発表しました。
これより約2年前の2019年3月にAWSが公開した独自ディストリビューションである「Open Distro for Elasticsearch」にも触れておかなければいけないでしょう。「Elasticsearch」には、オープンソースのコードとプロプライエタリのコードを混在しているので、オープンソースだけで構成されたディストリビューションを作成したというのがAWSの主張です。Elasticによれば、オープンソース部分もプロプライエタリ部分も顧客やコミュニティとともにオープンに開発していくというのが同社の方針だということで相容れないものになっています。
話を戻して、上記のライセンス変更に対して、その1週間後AWSは「Elasticsearch」と「kibana」をフォーク、独自のディストリビューションを作成すると発表し、2021年4月に「OpenSearch」プロジェクトを発表しました。これにより、AWSのサービス名も「Amazon Elasticsearch Service」から「Amazon OpenSearch Service」に変更され、2021年9月にサービスが開始されました。
2022年2月にElasticは、AWSとの商標権訴訟で和解し、AWSのWebページからElasticsearchという用語を削除し、「Elastic Cloud Sold by: Elastic」という表現に置き換えるということで合意しました。これにより、一連の騒動は表向き終了しました。
クラウド時代のOSSライセンス
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
これからは、組み込み機器メーカーやゲームメーカだけではなく、ソフトウェア製品を開発している企業やネットワーク経由でサービスを提供する企業など、OSSのライセンス管理に注力しなければいけない企業が増えていくことになります。
みなさんの会社はOSSのライセンス管理はできていますか？
今からでも遅くないので、OSSのライセンス管理に取り組んでみてはいかがでしょうか？
(*!)https://gpl.mhatta.org/agpl.ja.html
(*2)https://redis.com/blog/redis-license-bsd-will-remain-bsd/
(*3) https://www.mongodb.com/blog/post/mongodb-now-released-under-the-server-side-public-license
※本文中記載の会社名、商品名、ロゴは各社の商標、または登録商標です。
Tips集のご案内
テクマトリックスでは、開発企業としてOSSと上手につきあうための「OSS活用Tips集 – シーズン2」を提供しています。
「資料ダウンロードはこちら」から、ホワイトペーパーを一括でダウンロードできます。
1.「OSS最新動向-コロナに負けないオープンソース」
2.「オープンソースSBOMが必要な理由とは！」
3.「ソフトウェアイノベーションはOSSから、コンテナ・AI技術がイノベーションを牽引」
4.「OSSと上手に付き合う方法～攻めは最大の防御なり～」
5.「OSSと上手に付き合う方法～サプライチェーンを安全に～」
6.「ISO/IEC 5230で変わる？OSSコンプライアンス対策」
7.「著作権トロールとは？」
