GPL・MIT・Apacheの違いとライセンスの歴史

GPL、MIT、Apache: 各ライセンスが求めること

GPL、MIT、Apache 2.0 は、同じ問いに異なる形で答えます。ソフトウェアを他者に渡すとき、何を負う必要があるのかという問いです。MIT が求めるのは、著作権表示だけです。Apache 2.0 は、著作権表示に加えて、コードに関わる全員の間で特許に関する取り決めを求めます。GPL は、その上に構築したもののソースコードを、受け取ったときと同じライセンスで公開するよう求めます。

これは、実際に運用しているプロジェクトがライセンスを変更し、2 つに分裂するまでは、法律家向けの問題に見えます。その時点で、これは運用上の問題になります。選択できるパッケージリポジトリが 2 つになり、相互に通信できなくなるクライアントライブラリも発生します。このガイドでは、ライセンスとその仕組みを扱います。ライセンスを生み出した運動については扱いません。そのため、各セクションでは、アップグレードを実行する必要がある人、つまりあなたに関係するところまで説明します。

GPL が存在する理由：誰も修理を許されなかったプリンター

1980 年頃、MIT Artificial Intelligence Lab に Xerox 9700 レーザープリンターが導入されました。研究所では以前のプリンターのソフトウェアにパッチを適用し、ジョブが詰まったときに通知するようにしていました。しかし、新しいプリンターにはソースコードがなく、秘密保持契約を理由に提供も拒否されました。当時この研究所でプログラマーをしていた Richard Stallman は、この拒否を一時的な問題ではなく一般的な状況として捉え、1983 年 9 月 27 日に GNU プロジェクトを発表しました。

Copyleft は著作権法に反するものではなく、著作権法を基盤にしています。原則として、他人のコードをコピーする権利は一切ありません。GPL は、ある条件の下でその権利を認めます。プログラムを他者に渡す場合、同じ条件でソースコードも提供しなければなりません。これにより、研究所ができなかったことを受け取った側が実行できます。この条件を法的に適用できるのは、ライセンスがなければ、そもそもコピーする許可がなかったためです。

Stallman は最初に GNU Emacs 用のライセンスを作成し、その後、1989 年 2 月 25 日に GPL version 1 として一般化しました。GPL version 2 は 1991 年 6 月に続きました。現在も、利用しているシステムソフトウェアの大半でこのライセンスが使われています。ライブラリ向けには Lesser GPL が登場しました。これにより、コピーレフトのライブラリを任意のライセンスのプログラムからリンクでき、そのプログラム自体を GPL の対象にする必要がなくなりました。

GPL が self-hoster に与える影響を決める重要な点が 1 つあります。義務が発生するのは利用時ではなく、頒布時です。GPL プログラムを変更し、自分のサーバーで実行し、それを使って一般の利用者にサービスを提供しても、コピーを他者に渡していないため、誰かに何かを提供する義務はありません。この差を埋めるために AGPL が存在します。

寛容なライセンスの系譜: BSD、そして MIT

Berkeley は別の道を選びました。Computer Systems Research Group は、著作権表示の保持を求め、保証をすべて否認するライセンスで Unix の成果を公開しました。元の版には4つの条項があり、4番目の広告条項では、ソフトウェアの機能に言及するすべての広告資料で University への謝辞を表示するよう求めていました。この方式は規模を拡大できません。Stallman は、NetBSD の1997年版で75件の個別の謝辞が必要だったと数えています。UC Berkeley は1999年7月22日、Office of Technology Licensing の William Hoskins が出した書簡で、この条項を撤回しました。

残ったのが3条項 BSD licence です。これは、貢献者の名前を製品の推奨に利用することを禁じています。2条項版では、その禁止も削除されています。MIT licence の本文は、X Window System を対象としていた1980年代の MIT から生まれました。実務上は、2条項 BSD と同じ役割を果たします。

動機は異なっていました。公的資金で運営される大学は、企業を含むあらゆる利用者に成果を使ってほしいと考えました。GNU project は、閉鎖できない共有財産を作ろうとしました。どちらの立場も誠実ですが、どちらにも失敗する場合があります。寛容なライセンスのコードは私有化され、何も還元されないことがあります。Copyleft のコードは、条件を受け入れない企業の弁護士によって採用を拒まれます。

Berkeley から得られる2つ目の教訓があります。この投稿が繰り返し取り上げているのは、その教訓です。AT&T's Unix System Laboratories は1992年、BSD のコードをめぐって Berkeley Software Design を提訴し、この訴訟は1994年初頭に和解しました。2年間、BSD を基盤として安全に構築できると誰も確信できず、Linux が成長する一方で採用は停滞しました。法的な不確実性は、機能の不足よりも速く採用を止めます。

Apache 2.0で特許許諾が追加された理由

Apache Groupの最初のライセンスは、同じ広告条項の問題を抱えるBSD 4条項ライセンスの派生版でした。2000年のVersion 1.1では、その条項が削除されました。2004年1月に公開されたVersion 2.0は、部分的な修正ではなく、全面的な改訂版でした。

重要な追加点は特許です。MITとBSDは、特許についてまったく定めていません。コントリビューターは、自分のコードについて明確な著作権許諾を与えながら、そのコードの動作に及ぶ特許を保有し、コードの利用者を提訴できます。Apache 2.0はこの抜け穴を塞ぎます。各コントリビューターは、自分の貢献物を対象とする特許ライセンスを許諾します。また、その成果物が自分の特許を侵害すると主張して提訴した人は、その成果物に関する自分の特許ライセンスを失います。脅威が相互に作用するため、実際には誰も提訴しません。

2.0の残りの部分は管理面に関する規定であり、企業がこのライセンスを好む理由もそこにあります。NOTICEファイルが定義されているため、帰属表示をツリー内の複数箇所に分散させず、1箇所にまとめられます。ライセンスを各ソースファイルに貼り付けるのではなく、参照によって適用できます。コントリビューションには明示的な条件が適用されます。商標は対象外です。Apache 2.0の依存関係を法務レビューすると、確認したい事項がすべて本文に記載されているため、承認を定型的に進められます。これが「企業のデフォルト」の大部分を意味します。

GPLv3 で変わったことと、Linux が GPLv2 にとどまった理由

TiVo は Linux を実行するビデオレコーダーを出荷し、GPLv2 の要件どおり kernel のソースコードを公開しました。しかし、そのハードウェアは起動時に暗号署名を検証し、認識できない kernel の実行を拒否しました。ソースコードを読み、変更し、コンパイルすることはできました。しかし、その kernel を元のデバイス上で実行することはできませんでした。ライセンスの文言は満たしていても、その目的は損なわれていました。この手法は tivoisation という名前で知られるようになりました。

GPL version 3 は 29 June 2007 に公開され、この問題に直接対応しました。コンシューマー向けデバイス内でバイナリを提供する場合、変更版をインストールして実行するために必要な鍵または手順である「Installation Information」も提供しなければなりません。Version 3 では、明示的な特許許諾も追加されました。また、November 2006 の Microsoft と Novell の特許契約を受けて作成された条項と、Apache 2.0 との一方向の互換性も追加されました。

Linux は追随しませんでした。kernel は GPL version 2 のみで、「or any later version」という選択肢はありません。COPYING ファイルにもそのことが記載されています。Linus Torvalds は、署名付きハードウェアを対象とする anti-tivoisation 条項に公然と反対しました。実際の障壁は、この意見の相違より大きなものです。kernel には数千人の著作権者がいるため、全員が望んだとしても、ライセンスを変更するために必要な許諾を集めることはできません。この事実だけでも、プロジェクトが持ち得る最も強力な保護になります。1 社が所有するプロジェクトを見るときは、この点を覚えておく価値があります。

あなたにとっては、2007 年に登場したもう 1 つのライセンスの方が重要です。同じ年の November に公開された GNU Affero GPL version 3 は、ネットワーク経由でプログラムを操作する人にもソースコードの提供義務を拡張します。変更した AGPL サービスを一般向けに実行する場合、その利用者にソースコードを提供しなければなりません。多くの self-hosted Web ソフトウェアが AGPL を採用しているのはそのためです。Nextcloud はその一例です。Nextcloud の self-hosted 代替ソフトウェアを比較する場合、各候補の repository にあるライセンスの記載は、機能一覧よりも、そのソフトウェアの今後 5 年をよく示します。

実際に組み合わせられるライセンスはどれですか？

互換性は一方向で、許諾的ライセンスからコピーレフトへ向かいます。

• MIT および BSD のコードは、クローズドな製品を含め、どのようなものにも組み込めます。
• Apache 2.0 のコードは GPLv3 プロジェクトに含めることができ、組み合わせた成果物は GPLv3 になります。
• Apache 2.0 のコードを GPLv2 のみのプロジェクトに含めることはできません。Apache 2.0 の特許終了条項と補償条項は追加条件に該当し、GPLv2 では追加できません。FSF と ASF はいずれもこの結論を公表しています。
• GPL のコードを、利用者の判断で許諾的ライセンスへ変更することはできません。変更できるのは著作権者だけです。そのため、著作権者が誰なのかという問題に戻ります。

再ライセンスの時代: SSPL、BUSL、およびそれらが意味しないもの

きっかけは商業的なものでした。ある企業が製品の著作権を保有し、クラウドプロバイダーがその製品を大規模なマネージドサービスとして提供しながら、ほとんど還元しない状況で、企業がそれを止めるためにライセンスを変更しました。Redis Labs は 2018 年 8 月、複数のモジュールについて Apache 2.0 に Commons Clause を追加し、最初の目立った動きを見せました。MongoDB は 2018 年 10 月 16 日、AGPLv3 から Server Side Public License へ移行しました。

SSPL は、1 つのセクションを書き換えた AGPL です。プログラムをサービスとして第三者に提供する場合、その提供に使用するすべてのソフトウェアのソースコードを公開する必要があります。これには、そのプログラムを取り巻く管理ソフトウェアやオーケストレーションソフトウェアも含まれます。この義務の範囲には明確な境界がなく、裁判所による判断もまだありません。OSI はこのライセンスを承認せず、MongoDB は 2019 年 3 月に申請を取り下げました。Debian はそれ以前の 2018 年 12 月に、SSPL ソフトウェアはアーカイブに含めないと表明していました。Fedora も 2019 年 1 月、このライセンスはフリーではないと判断しました。その後 Red Hat は Fedora と Red Hat Enterprise Linux から MongoDB を削除しました。これが再ライセンスによる機械的な結果です。ディストリビューションがソフトウェアのパッケージ提供を停止するため、以後のアップグレードはベンダーのリポジトリから、ベンダーのスケジュールで取得することになります。

Business Source License は別の仕組みです。これは MariaDB の創業者が作成したもので、バージョン 1.1 は 2017 年のものです。コピーレフトではなく、オープンソースでもありません。ソースコードは公開され、ベンダーが除外する用途を除いて利用は無償です。通常、除外されるのは競合するホステッドサービスの運用です。また、各リリースは、そのリリースから 4 年以内に設定された変更日に、自動的に実際のオープンソースライセンスへ移行します。移行先のライセンスは GPLv2 と互換性がなければなりません。HashiCorp は 2023 年 8 月 10 日、Terraform とその他の製品を BUSL 1.1 に移行しました。Outline もこのライセンスを使用しています。セルフホスト型の Notion 代替製品を選ぶ場合は、この点を知っておくとよいでしょう。自分のチーム向けに運用することは許可されていますが、それを基盤にサービスを構築することは許可されていません。

どちらのライセンスも不誠実なものではありません。どちらもソースコードが利用可能であることを明示しています。OSI の定義では、どちらもオープンソースではありません。そして、その違いの影響を受けるのは、対象とされたクラウドプロバイダーではなく、あなたです。

OpenSearch: ライセンス変更によるフォークが運用者にもたらすコスト

Elastic は 2021 年 1 月 14 日、Elasticsearch と Kibana について、release 7.11 以降、Apache 2.0 を離れ、SSPL または Elastic License のいずれかに移行すると発表しました。Version 7.10.2 が Apache 2.0 での最後の release でした。その約 1 週間後、AWS は両方の Apache 2.0 フォークを作成し、維持すると発表しました。このフォークは 2021 年 4 月 12 日に OpenSearch と命名され、Kibana は OpenSearch Dashboards に改称されました。OpenSearch 1.0 は 2021 年 7 月 12 日に一般提供され、Elasticsearch 7.10.2 と Kibana 7.10.2 を基に構築されました。

クラスタを運用する人々に何が起きたかを見てみましょう。パッケージ名とリポジトリが変わりました。運用手順書にある Kibana への参照はすべて OpenSearch Dashboards になりました。プラグイン名も移行しました。さらに分岐はアプリケーションコードにまで及びました。Elastic の公式クライアントライブラリは version 7.13 以降、接続先を確認し、Elasticsearch 以外への接続では処理を拒否して、サーバーが不明な製品であると報告します。自社が関与していない会社のライセンス判断が、自社アプリケーション内の失敗する呼び出しとして現れたのです。

その後、この状況はさらに 2 回変化しました。Elastic は 2024 年 8 月 29 日、3 つ目のライセンス選択肢として AGPLv3 を追加しました。そのため、現在の Elasticsearch は再び OSI 承認済みのオープンソースです。2024 年 9 月 16 日、AWS は OpenSearch を、Linux Foundation がホストする OpenSearch Software Foundation に移管しました。これにより、このフォークには単一企業に依存しないガバナンスの基盤ができました。分岐から 5 年後の現在、両プロジェクトはオープンソースであり、両方とも維持されています。2026 年 8 月時点で、OpenSearch は 3.x 系列です。

結末から得られる教訓は明確です。ライセンスは元に戻り、フォークは残りました。エコシステムにあらゆるものが 2 つずつ存在する状態になると、書類上の変更を元に戻しても、再び 1 つに統合されるわけではありません。

ライセンス変更がどれほど大きな負担になるかを決める数字は、発表から実際にデプロイできる安定版フォークまでの期間です。

[
  {
    "label": "Elasticsearch to OpenSearch 1.0",
    "gap_to_stable_fork": 179
  },
  {
    "label": "Terraform to OpenTofu 1.6.0",
    "gap_to_stable_fork": 153
  },
  {
    "label": "Redis to Valkey 7.2.5",
    "gap_to_stable_fork": 27
  }
]

各期間は、ベンダーによる公開発表日から、フォークの最初の安定版 release までを、以下に示す日付に基づいて数えています。OpenSearch 1.0 には 179 日かかりました。フォーク名の変更と再構築が必要で、コピー元となる以前のフォークがなかったためです。OpenTofu には 153 日かかりました。Valkey には 27 日かかりました。Redis 7.2.4 からフォークし、プロトコルとディスク上の形式を同一に維持したためです。重要なのはその方向性です。現在では、財団と有給のメンテナーを初日から備えた、信頼できるフォークが数週間で登場します。

Valkey と OpenTofu: 同じパターンをより速く

Redis Ltd は 2024 年 3 月 20 日、Redis のライセンスを 3 条項 BSD ライセンスから RSALv2 または SSPLv1 の選択制へ変更しました。8 日後、Linux Foundation は Valkey を発表しました。Valkey は Redis 7.2.4 からフォークされ、3 条項 BSD ライセンスを維持しています。Valkey 7.2.5 は 2024 年 4 月 16 日にリリースされ、同じプロトコルと同じデータファイルを使用しました。そのため、多くの運用者にとって移行はパッケージ名の変更で済みました。その後、Redis は 2025 年 5 月の Redis 8 で 3 つ目の選択肢として AGPLv3 を追加しました。これにより、OSI の定義では再びオープンソースとなりました。一方、Valkey は独自のガバナンスの下で開発を続けています。この構図は Elasticsearch とよく似ています。

Terraform も同じ経過をたどりましたが、もう 1 つ章が加わりました。OpenTofu は Mozilla Public License 2.0 の最後のリリースからフォークされ、2023 年 9 月に Linux Foundation に加わり、2024 年 1 月 10 日に 1.6.0 をリリースしました。2024 年 4 月 3 日、HashiCorp の弁護士はプロジェクトに cease and desist letter を送り、BUSL ライセンスの Terraform リリースのコードがフォークにコピーされたと主張しました。OpenTofu は 2024 年 4 月 11 日、これを否定する詳細な回答を公開し、問題とされたコードは両プロジェクトが共有する MPL ライセンスの履歴に由来すると説明しました。その後、公の場でさらなる動きはありませんでした。この出来事から覚えておくべき本当のリスクは、告発だけでも採用を 1 四半期止める可能性があることです。これは、30 年前に Berkeley の訴訟がもたらした影響と同じです。

すべてのフォークがライセンス問題から始まるわけではありません。Forgejo は 2022 年、Gitea の開発が企業の下に移った後に Gitea からフォークされました。これはライセンスではなく、ガバナンスをめぐる対立でした。Forgejo は version 8 series まで MIT ライセンスを維持し、その後 2024 年の version 9.0 から GPLv3 or later に再ライセンスしました。これにより、その成果物を商業的に管理される製品へ取り込んで戻すことができなくなりました。自己ホスト型 Git サーバーの選択肢を検討しているなら、この組み合わせは 1 つのコードベースと 2 つの思想を示す、最も分かりやすい現在の例です。

導入前に実行するテスト

最初のインストール後ではなく、導入前に確認する4つの質問があります。

1. 著作権を誰が保有していますか。再ライセンスには、すべての著作権保有者の許可が必要です。そのため、独立した貢献者が数百人いて、著作権の譲渡もないプロジェクトは、現実的には再ライセンスできません。1社がすべてを所有するプロジェクトなら、取締役会の決議だけで再ライセンスできます。
2. CLA はありますか。ある場合、何を許諾していますか。会社が望む任意の条件で貢献内容を再ライセンスできる contributor licence agreement が、上記のすべての再ライセンスを可能にした仕組みです。Linux kernel が 2004 年に採用した署名行である DCO (developer certificate of origin) は、権利を一切移転しません。Foundation が保有する CLA は、会社が保有する CLA より安全です。会社は売却される可能性があるためです。
3. 商標を誰が保有していますか。Elastic が Elasticsearch の名称を保持したため、フォークは名称変更を迫られ、Kibana に言及していたすべての runbook も書き直す必要がありました。
4. あなたにとって、再ライセンスにはどのような費用が発生しますか。データ形式、client library、書き換えが必要な設定、互換性のあるフォークがすでに存在するかどうかを確認してください。

このうち一部は、2つのコマンドですぐに確認できます。

head -n 12 /usr/share/doc/bash/copyright
git log --oneline -- LICENSE COPYING LICENSE.md

すべての Debian および Ubuntu パッケージには /usr/share/doc/<package>/copyright のファイルが含まれています。このファイルに記録されているのは、プロジェクトが現在使用しているライセンスではなく、インストールしたバージョンのライセンスです。Ubuntu 24.04 の bash では、このファイルに GNU General Public License version 3 と記載されています。2つ目のコマンドを source checkout 内で実行すると、ライセンスファイル自体の履歴を確認できます。そこに過去2年以内の commit がある場合は、そのプロジェクトを基盤に何かを構築する前に確認する価値があります。コマンドの出力がない場合は、リポジトリ内で別の名前のライセンスファイルを使用しています。root directory の内容を一覧表示して確認してください。

どのライセンスを選んでも、あらゆる結果から保護されるわけではありません。理念だけで選ぶと、後で予想外の問題に直面します。著作権が多くの個人に分散しているか、foundation が保有しているプロジェクトを優先し、データは export できる形式で保持してください。次に、移行先となるフォークを特定し、必要になる前にその名前を書き留めておきます。各候補にこの確認を適用しても1時間未満で済みます。これは、2026年に self host する対象を決める際に、upgrade と migration を分けるものです。

FAQ

MIT ライセンスは BSD ライセンスと同じですか？

実質的には、MIT ライセンスは 2 条項 BSD ライセンスと同じです。著作権表示と無保証の免責条項を残せば、クローズド製品の開発を含め、自由に利用できます。3 条項 BSD ライセンスでは、許可なく貢献者の名前を製品の推奨に利用することが禁止されます。古い 4 条項版では、広告資料で謝辞を示すことも求められていました。UC Berkeley は 1999 年 7 月 22 日にこの条項を撤回したため、現在この条項を含むライセンスはほとんどありません。

Apache 2.0 のコードを GPLv2 プロジェクトに組み込めますか？

いいえ。Apache 2.0 には、GPLv2 では追加を認めていない条件が含まれています。特に問題となるのが、特許権の終了に関する条項です。そのため、結合した著作物は両方のライセンスを同時に満たせません。FSF と ASF は、いずれもこの結論を公表しています。逆方向は可能です。Apache 2.0 のコードを GPLv3 プロジェクトに組み込むことができ、結果は GPLv3 になります。Linux kernel に Apache 2.0 のコードを統合できないのも同じ理由です。Linux kernel は GPL version 2 のみでライセンスされているためです。

SSPL はオープンソースライセンスですか？

いいえ。実務上も影響があります。OSI は SSPL を承認しておらず、MongoDB は 2019 年 3 月に申請を取り下げました。Debian は 2018 年 12 月、SSPL ソフトウェアをアーカイブに含めないと表明しました。Fedora も 2019 年 1 月に、このライセンスはフリーではないと判断しました。その後、Red Hat は Fedora と Red Hat Enterprise Linux から MongoDB を削除しました。つまり、ディストリビューションが以前保守していたパッケージが、現在はベンダーのリポジトリから提供され、ベンダーのサポート日程に従うことになります。Business Source License も、オープンソースではなくソースコードを利用できるライセンスです。ただし、各リリースは 4 年以内にオープンソースライセンスへ移行します。

すでに実行しているバージョンにもライセンス変更は適用されますか？

いいえ。リリース時に付与されたライセンスを、すでに公開されたコピーに対して取り消すことはできません。これがフォークが可能な理由です。OpenSearch は、Elastic が Apache 2.0 で公開した最後のリリースである Elasticsearch 7.10.2 から作られました。失われるのは将来です。次のセキュリティ修正は、新しい条件の下で提供されます。寛容なライセンスの最後のバージョンに固定すれば数か月はしのげますが、それは計画とはいえません。