オープンソースライセンスの種類と違い｜MIT・Apache・GPL・AGPLの義務と商用利用の可否

ソフトウェア開発では、自分で書いたコードよりも、外部から取り込んだライブラリのほうが行数で上回ることが珍しくありません。そのライブラリ1つ1つに、著作権者が定めた利用条件（ライセンス）が付いています。多くは無料で使えますが、「無料で使える」ことと「何をしてもよい」ことは別で、著作権表示を残す義務や、改変したコードを公開する義務が伴う場合があります。この記事では主要なライセンスを、名前ではなく「使う側が何を負うか」の観点で整理します。

01.結論：ライセンスは3系統で捉える

ライセンス名を1つずつ覚えようとすると、似た名前が多く混乱します。実務では「この系統に属するライセンスだから、こういう義務がある」と大まかに掴んだうえで、採用時に原文を確認する進め方が扱いやすくなります。

3つ目の系統は、コードがGitHubで公開されていてもオープンソースには当たりません。オープンソースには後述の定義があり、利用目的による制限を置いた時点でそこから外れるためです。「GitHubで公開されている＝自由に使える」という思い込みが、実務上の事故につながりやすいところです。

02.オープンソースライセンスの基礎

ライセンスは著作権法上の利用許諾

プログラムは著作権法で保護される著作物です。日本の著作権法は、第10条第1項第9号でプログラムの著作物を著作物の例示に挙げています。著作権者以外は、複製・改変・公衆送信を原則として行えません。オープンソースライセンスは、この原則に対して著作権者があらかじめ与えている利用許諾で、「この条件を守るなら複製・改変・再配布してよい」という意思表示にあたります。

したがって、条件を守らなければ許諾の前提が崩れ、単なる著作権侵害の状態になります。ライセンスは「守れば得をするマナー」ではなく、守らなければ利用そのものが違法になりうる条件だと捉えると、実務上の優先度が見えやすくなります。

オープンソースの定義（OSD）

「オープンソース」は語感で使われがちですが、Open Source Initiative（OSI）が公開するThe Open Source Definitionという定義があり、10の項目で構成されています。要点は次の3つです。

• 再配布を制限しない：無償で配ることも、有償で売ることも禁じてはなりません（第1項）。
• 利用分野で差別しない：商用利用、遺伝子研究など、特定の用途を禁止できません（第6項）。
• 人・グループで差別しない：特定の企業や国の利用者を除外できません（第5項）。

つまり、「商用利用は禁止」と書かれたライセンスは、その時点でオープンソースではありません。後述するBUSLやSSPLが「オープンソースではない」と整理されるのも、主にこの利用分野の差別に当たるためです。なおOSIは、定義を満たすかどうかを審査してライセンスを承認する承認済みライセンス一覧を公開しています。採用を検討しているライセンスがこの一覧にあるかどうかは、最初の判断材料になります。

義務は3つの型に分けられる

個々のライセンス条文は長いものの、使う側が実際に負う義務は次の3つの型に整理できます。この型を頭に入れておくと、初めて見るライセンスでも読むべき箇所が絞れます。

03.主要ライセンスの早見表

代表的なライセンスについて、使う側から見た4つの軸で比較します。色が濃いほど、その項目で自由度が高いことを示します。

「改変版を非公開にできる」欄の△は、公開義務の範囲が限定されることを示します。MPL 2.0は改変したファイルだけ、LGPLはライブラリ本体だけが対象で、自分のアプリケーション全体を公開する必要はありません。特許条項欄の○は、GPL-3.0・LGPL-3.0・SSPLのようにバージョンや系統によって明文の規定があるものと無いものが混在することを示します（GPL-3.0は第11条で特許ライセンスを明示していますが、GPL-2.0には対応する条文がありません）。

BUSL 1.1とSSPLの2行は、制限の掛かり方がオープンソースの系統とは根本的に違う点に注意してください。BUSL 1.1は公開義務を課すのではなく、本番環境での利用そのものを制限します。制限の範囲は提供元が設定するAdditional Use Grantで変わり、社内利用は認められている例も多いため、採用前に対象のリポジトリで実際の設定を読む必要があります。SSPLはGPL-3.0を土台にしているため配布時の公開義務を引き継ぎ、そのうえでサービス提供時の公開範囲を広げています。詳細は07章で扱います。

04.許諾型：MIT・BSD・Apache License 2.0

許諾型（パーミッシブ）は、使う側の義務が著作権表示にほぼ限られる系統です。改変したコードを公開せずに製品へ組み込めるため、企業が採用しやすく、npmやPyPIで公開されているパッケージの多くがこの系統に属します。

MIT License

最も広く使われている許諾型ライセンスです。OSIが公開する原文は20行ほどしかなく、内容は「著作権表示とこの許諾表示を、ソフトウェアの複製物または重要な部分すべてに含めること」という条件と、無保証の免責だけです。

条件が1つしかないため、商用製品への組み込み、改変版の非公開での利用、再ライセンスのいずれも制限されません。実務上の注意点は、この唯一の条件である著作権表示を落としてしまうことです。フロントエンドのコードをバンドルして配信する場合や、コンテナイメージに同梱する場合でも表示義務は残るため、依存関係のライセンス表記をまとめて出力する仕組みを持っておくと漏れを防げます。

BSD License（2条項・3条項）

BSDライセンスは条項数で呼び分けられます。BSD 2-Clause（Simplified BSD）は、ソース形式・バイナリ形式それぞれでの再配布時に著作権表示と免責条項を残すことを求めるもので、内容はMITとほぼ同じです。

BSD 3-Clause（New BSD）は、これに3つ目の条項が加わります。開発元の名前や貢献者の名前を、事前の書面による許諾なく派生製品の宣伝や推奨に使ってはならないという、無承認条項（no endorsement clause）と呼ばれる規定です。技術的な制約ではありませんが、「◯◯プロジェクト公認」といった打ち出しを避ける必要があるため、マーケティング表現を検討する際は確認しておく箇所になります。

Apache License 2.0

Apache License 2.0は、許諾型でありながら特許の扱いを明文化している点が特徴です。Apache Software Foundationが公開する原文の第3条では、貢献者が利用者に対して恒久的・世界的・無償の特許ライセンスを付与すると定めています。同じ条項には、利用者がそのソフトウェアを特許侵害だと主張して訴訟を起こした場合、その利用者に付与されていた特許ライセンスは訴訟提起の日付で終了する、という条件も含まれます。

MITやBSDには特許について明示的な規定がありません。そのため、貢献者が保有する特許を後から主張されるリスクを条文の形で減らしたい場合は、Apache 2.0のほうが判断材料が明確です。企業が関わるプロジェクトでApache 2.0が採用される理由の1つが、この条文の存在です。

使う側の義務は、同じ原文の第4条にまとまっています。ライセンス全文の同梱に加えて、変更したファイルにその旨を明記することと、元の配布物にNOTICEファイルが含まれる場合はその帰属表示を引き継ぐことが求められます。MITと比べると手順が1段増えるため、Apache 2.0のライブラリを改変して再配布する予定があるなら、この2点を作業フローに組み込んでおくと安全です。

05.コピーレフト型：GPL・LGPL・AGPL・MPL

コピーレフト型は、自由なソフトウェアから派生したものも同じように自由であるべきだ、という考え方を条文にした系統です。使う側にとっての要点は、公開義務が発生する引き金と範囲の2つです。引き金は原則として配布（第三者への提供）であり、社内で使うだけなら義務は生じません。

GPL（v2・v3）

GNU General Public Licenseは、コピーレフト型の代表格です。Free Software Foundationが公開するGPL-3.0の原文では、改変版を配布する場合、その全体を同じGPLの条件で、対応するソースコードとともに提供することが求められます。GPLのコードを自社製品にリンクして配布すると、自社が書いた部分も含めてソースコードの公開義務が及びうる点が、コピーレフト型で最も注意が要るところです。

v2とv3の主な違いは3点です。v3では、ハードウェアに組み込んだ際に利用者が改変版をインストールできないようにする措置（いわゆるTivoization）を禁じる規定、明文の特許ライセンス条項、デジタル著作権管理（DRM）に関する規定が追加されました。v2とv3には互換性がないため、GPL-2.0-onlyのコードとGPL-3.0-onlyのコードは同じ成果物に混ぜられません。多くのプロジェクトがGPL-2.0-or-laterのように「以降のバージョンでもよい」と指定しているのは、この非互換を避けるためです。

LGPL

GNU Lesser General Public Licenseは、公開義務の範囲をライブラリ本体に限定したものです。LGPL-3.0の原文では、LGPLのライブラリを利用するアプリケーション（原文でいうCombined Work）を、独自のライセンスのまま配布できると定めています。ただし条件があり、利用者がライブラリを改変版に差し替えて動かせる状態を保つ必要があります。

この条件の満たし方は、LGPL-3.0の第4条(d)に2つの選択肢として書かれています。共有ライブラリの仕組みで動的にリンクする場合（(d)(1)）は、利用者の環境にあるライブラリを実行時に読み込む形にしておけば足ります。静的リンクの場合（(d)(0)）は、利用者が改変版のライブラリと結合し直せるよう、ライブラリ側のソースコードとアプリケーションのオブジェクトファイルなどを提供する必要があります。組み込み機器のようにライブラリの差し替えが難しい構成では条件を満たしにくくなるため、採用前に配布形態を確認しておくとよいでしょう。

AGPL

GNU Affero General Public Licenseは、GPLの公開義務の引き金にネットワーク経由の利用を加えたライセンスです。AGPL-3.0の原文第13条は、改変したプログラムをネットワーク越しに利用させる場合、その利用者に対して対応するソースコードを受け取る機会を提供しなければならないと定めています。

従来のGPLは「配布」が引き金だったため、ソフトウェアを自社サーバーで動かしてSaaSとして提供する形態では公開義務が生じませんでした。AGPLはこの点を埋めるもので、AGPLのソフトウェアを改変して自社サービスに組み込むと、その改変部分の公開義務が生じます。Webサービスを提供する企業にとっては、コピーレフト型の中でも影響が最も大きいライセンスです。

MPL 2.0

Mozilla Public License 2.0は、公開義務の範囲をファイル単位に絞ったライセンスです。Mozillaの公式FAQによると、コピーレフトが及ぶのはMPLのコードを含むファイルだけで、MPLのコードを含まない新規ファイルは改変（Modification）に当たらず、同じ成果物にまとめてコンパイルしてもMPLで配布する必要はありません。

この設計により、MPLのライブラリを使いつつ、自社の独自コードは非公開のまま配布できます。改変した既存ファイルだけを公開すればよいため、GPLとApache 2.0の中間に位置づけられる選択肢として扱われます。同じFAQでは、GPLとの組み合わせについても、第3.3条のLarger Workの仕組みを使って両方の条件で配布する形が示されています。

06.権利を放棄する系統とドキュメント向けライセンス

著作権表示すら求めない系統もあります。CC0 1.0はクリエイティブ・コモンズが用意した権利放棄の仕組みで、著作権者が法的に可能な範囲で権利を放棄し、パブリックドメインに近い状態に置きます。The Unlicenseも同様の目的を持つ文書で、いずれもデータセットやサンプルコードの公開で使われます。

混同しやすいのが、クリエイティブ・コモンズ・ライセンス（CC BY、CC BY-SAなど）です。これらは文章・画像・動画といった著作物向けに設計されており、クリエイティブ・コモンズ自身がFAQでソフトウェアへの適用を推奨していません。ソースコードの配布形式や特許について規定していないためです。ドキュメントはCC BY、コードはMITというように、対象ごとに使い分けるのが一般的です。

なお、AIモデルの重みには、これらのどれとも異なる独自の利用規約が付くことがあります。モデル本体はApache 2.0でも、別途「禁止事項ポリシー」が並行して適用される形式が典型です。

07.オープンソースを名乗れないソース公開ライセンス

2020年前後から、クラウド事業者が自社のソフトウェアをそのままマネージドサービスとして提供することへの対抗として、ソースコードは公開しつつ利用目的に制限をかけるライセンスが増えました。これらはソース利用可能（source available）と呼ばれ、OSDの「利用分野で差別しない」という項目を満たさないため、オープンソースには当たりません。

BUSL・SSPL・Elastic License・FSL

時間経過で切り替わる仕組みを持つのがBUSLとFSLです。MariaDBが公開するBusiness Source License 1.1の原文は、Change Dateを遅くとも各バージョンの最初の公開から4年後とし、Change LicenseにはGPL-2.0またはその互換ライセンスを指定すると定めています。FSLの公式サイトも同じ発想で、こちらは2年後にApache 2.0またはMITへ切り替わり、切り替え先を変えたい場合は名称を変える必要があるとしています。制限が永続しないため、自社が使いたいバージョンのChange Dateを過ぎているかどうかが判断の分かれ目になります。

制限の範囲が特に広いのはSSPLです。MongoDBが公開するSSPLの原文第13条は、そのソフトウェアの機能を第三者にサービスとして提供する場合、対象となるソースコードに管理ソフトウェア、ユーザーインターフェース、API、監視・バックアップ・ストレージ・ホスティング用のソフトウェアまで含めて公開することを求めています。データベース本体だけでなく、それを動かす基盤一式が対象になるため、SaaS提供者にとっては実質的に採用しにくい条件です。

方針転換が起きた実例

この領域は数年単位で状況が動いています。採用時点のライセンスがそのまま続くとは限らないため、主要な事例を押さえておくと判断材料になります。

• Redis：2024年3月にBSD-3-ClauseからSSPLとRSALv2の二重ライセンスへ移行しました。Linux Foundationが2024年3月28日に公開した発表によると、この変更を受けてAWS・Google Cloud・Oracle などが参加するフォーク「Valkey」が立ち上がっています。その後、Redisが2025年5月1日に公開した発表によると、Redis 8からOSI承認のAGPLv3を選択肢として追加しました。
• Elasticsearch・Kibana：2021年にApache 2.0からSSPLとElastic License 2.0へ移行し、AWSがOpenSearchとしてフォークしました。Elasticが2024年8月に公開した発表によると、その後AGPLv3が選択肢として追加されています。
• Terraform：HashiCorpが2023年8月10日に公開した発表によると、同社は製品の今後のリリースをMPL-2.0からBUSL-1.1へ移行しました（API・SDKなどのライブラリはMPL-2.0のまま）。この変更を受けて、Linux Foundation配下のOpenTofuとしてフォークが生まれています。

RedisとElasticがいずれもAGPLv3を追加したのは、クラウド事業者への対抗と、オープンソースとしての位置づけの回復を両立できる選択肢だったためと整理できます。一方で、これらの移行は既存の利用者にバージョンアップの判断を迫るものでもありました。基盤ソフトウェアを採用するときは、ライセンスの内容だけでなく、提供元がライセンス変更を行った履歴があるかどうかも見ておくと、後の切り替えコストを見積もりやすくなります。

08.使う側が確認すること

ライブラリを採用するときに見る箇所は、そう多くありません。次の5点を順に確認すると、大きな見落としは防げます。

推移的な依存の確認は、手作業では追い切れません。npm lsやpip-licensesのようなコマンド、あるいはソフトウェア部品表（SBOM: Software Bill of Materials）を生成するツールで一覧化し、レビューの対象にする運用が扱いやすくなります。特にAIにコードを書かせる比重が上がるほど、依存関係が増える速度も上がるため、機械的な検査を開発フローに組み込んでおく価値は高まっています。

なお、AIが生成したコードそのものの著作権や、学習データに含まれるコードのライセンスをどう考えるかは、ライセンス条文とは別の論点になります。

09.公開する側の選び方

自分のコードを公開する場合は、「どこまで使われたいか」から逆算すると決めやすくなります。最も広く使われたいなら許諾型、改良を還元させたいならコピーレフト型、事業として保護したい部分があるならソース公開型という順で検討します。

許諾型を選ぶ場合、企業からの貢献を受け入れる予定があるならApache 2.0が扱いやすくなります。特許条項に加えて、貢献物の扱いを定めた条文が用意されているためです。個人プロジェクトや、他のプロジェクトに気軽に取り込んでほしいライブラリであれば、MITの短さがそのまま採用の後押しになります。

ソース公開型を選ぶ場合に気をつけたいのは呼称です。オープンソースの定義を満たさないライセンスを「オープンソース」と説明すると、利用者との認識が食い違い、RedisやElasticが受けたような反発につながります。「ソースコードを公開しています」と事実だけを書き、条件をライセンス名とあわせて明示する書き方が誤解を招きません。

10.ライセンス違反はどう扱われるか

オープンソースライセンスの違反は、著作権侵害としてだけでなく、契約違反としても扱われうると判断した裁判例があります。米国カリフォルニア州北部地区連邦地方裁判所は2017年4月、Artifex Software対Hancomの事件で、GPLに署名がないことを理由に契約が成立していないとするHancom側の主張を退けました。法律事務所Wilson Sonsiniの解説によると、この判断はオープンソースライセンスの条件が著作権侵害と契約違反の両面から追及されうることを示したものと整理されています。

実務上のリスクは訴訟だけではありません。違反が判明した場合、GPL系であれば公開したくないソースコードの公開を求められる、あるいは該当するライブラリを取り除いて作り直す必要が生じます。いずれも、採用時に数分かけて確認していれば避けられた種類の手戻りです。ライセンスの確認は、法務の作業である前に、後工程の作り直しを避けるための設計判断だと位置づけると、開発フローに組み込みやすくなります。

11.よくある質問（FAQ）

12.まとめ

オープンソースライセンスは数多くありますが、使う側の判断は著作権表示だけで済む許諾型か、ソースコードの公開義務が伴うコピーレフト型か、そもそもオープンソースではないソース公開型かの3系統でほぼ整理できます。MITとBSDは条件が著作権表示だけ、Apache 2.0はそこに特許条項と変更点の明記が加わります。GPLは配布時に、AGPLはSaaS提供時に公開義務が生じ、LGPLとMPLはその範囲を限定します。

判断が変わる分岐点は、成果物を第三者に届けるかどうかです。社内利用にとどまるならライセンス間の差はほとんど出ませんが、配布やSaaS提供を始めた時点で条件が効いてきます。採用時にライセンス名をSPDX識別子で記録し、依存関係を機械的に検査する仕組みを持っておくと、後から遡って確認する手間を避けられます。

依存ライブラリのライセンス確認やSBOMの整備は、開発の合間に後回しになりがちな作業でもあります。弊社では、こうした継続的な運用も含めて開発・サイト運用の伴走支援を行っています。