OSS を使う前のライセンス見極め — 自分のコードに及ぶ義務を理解する

執筆時点: 2026-05 / 対象: OSS ライセンス(ライセンス契約の条文ベースのため法域に依存しにくい。違反・判例は米国・ドイツ・EU が中心)/ last_updated: 2026-05-24 更新履歴: 2026-05-24 初版公開

この記事の射程: 扱うのは「自作 OSS にどのライセンスを付けるか(付与・選定)」ではなく、「他者が公開した OSS を採用・組み込む前に、どのライセンスかを見極め、自分のコードにどんな義務が及ぶかを理解する」ことです。

本シリーズの位置づけ: 「権利関係シリーズ」の OSS 各論です。ハブの 公開前の権利チェック が OSS をソース公開義務の及ぶ範囲が狭い→広いで 4 段に概観したのに対し、本記事は「実際に採用するとき、どこを見て、どう判断するか」を掘り下げます。

用語ミニ解説(はじめての方へ):

• OSS(Open Source Software): ソースコードが公開され、ライセンス条件の範囲で誰でも利用・改変・再配布できるソフトウェア。
• SPDX 識別子: ライセンスを一意に表す業界標準の短い名前(例: MIT / Apache-2.0 / AGPL-3.0-only)。LICENSE ファイル冒頭や package.json の license 欄に書かれます。
• コピーレフト: 派生物を同じ条件で公開する義務を課すライセンス哲学(GPL / LGPL / AGPL が代表)。
• OSI(Open Source Initiative): OSS の定義(OSD)を維持し、ライセンスが「オープンソースか」を認定する非営利団体。
• SaaS(Software as a Service): ソフトを自分の環境にインストールせず、ネットワーク越しにサービスとして利用 / 提供する形態。
• バイナリ: ソースコードをコンパイルした実行ファイル(配布形態の一つ)。
• CLI(Command Line Interface、コマンドラインインターフェース): 画面のボタンでなく、文字のコマンドを打ち込んで操作するツールの形態(例: git、npm)。本記事では「別プロセスとして外部から呼び出す」結合形態の代表例として登場します(リンクのような密結合と区別されます)。
• Docker: アプリを必要な実行環境ごと「コンテナ」という単位にまとめて配布・実行する技術。本記事では OSS の Docker Engine と、商用条件が付く Docker Desktop を区別して扱います(詳細は本文)。
• Dify: LLM を使うアプリやワークフローを GUI で構築できる、AI アプリ開発プラットフォーム。本記事では Apache 2.0 をベースにしつつ商用利用(マルチテナント運用)に追加条件が付く例として登場します(詳細は本文)。

本題の前に、ひとつだけ。OSS は、世界中の作者・メンテナの多大な労力——その多くは無償の貢献——に支えられています。本記事はライセンス上の義務を冷静に整理していきますが、どの段のライセンスであっても、コードを公開してくれた作者やコミュニティへの敬意と感謝は変わりません。義務を正しく理解することは、その成果を気持ちよく使い続け、エコシステムに報いるための作法でもあります。

その上で本題へ。「OSS だから無料で自由に使える」は半分正解で、半分は誤解です。OSS の多くは、自分のコードとどう結合し(リンク)、どう配布するか(バイナリ / SaaS)によって、自社コードのソース公開義務が波及することがあります。結論から言えば、やることは 4 つだけです。(1) SPDX 識別子で段を特定 → (2) ソース公開義務の及ぶ範囲(狭→広)のどこかに位置づけ → (3) 結合形態と突き合わせ → (4) 配布形態と突き合わせる。この記事は、その 4 ステップを段階別に具体化していきます。

まず SPDX で「段」を見極める

OSS 採用の最初の一歩は SPDX◆ 識別子の確認です。LICENSE ファイルの冒頭、package.json の license 欄、Cargo.toml の license フィールドなどに、MIT や Apache-2.0、AGPL-3.0-only のような短い識別子が書かれています(Go は go.mod に license 欄がないため、LICENSE ファイルや pkg.go.dev のライセンス表示で確認します)。SPDX 識別子(ライセンスを一意に表す業界標準の名前)が分かれば、そのライセンスを「ソース公開義務の及ぶ範囲(狭→広)」のスペクトラム上に位置づけられます。

ここで言う「ソース公開義務の及ぶ範囲(狭→広)」は、あなたのコードに「ソースコードの公開義務」がどれだけ広く波及し得るか(コピーレフトの及ぶ範囲)を表す軸です。ソフトの品質や、一般的な意味での「自由度」の優劣ではありません。またどちらの思想が良い・悪いという話でもありません —— パーミッシブは「誰でも再利用できること」を、コピーレフトは「派生物も含めてソースが開かれ続けること」を重視する、目的の違いです(コピーレフト側は「利用者の自由を守る」立場を取ります)。本記事はこの思想論争には立ち入らず、採用時に「どこを見て、自分のコードにどんな義務が及ぶか」を見極める材料だけを示します。自分の利用形態で許容できる段かを確認すれば十分です。

副業・個人開発に加え、企業内で OSS 採用を判断する担当者の視点でも、ソース公開義務の及ぶ範囲が狭い→広いで 5 段に整理したのが次の表です。義務の「核」だけ押さえれば、最初の判断はできます。

出典: OSI Approved Licenses / FSF — Why the AGPL。

ここで大事な注意が 1 つあります。「OSS だから全部自由」は誤読です。近年は「ソースは見えるが OSS ではない」ライセンスが増えています(後の「ソースが見えても OSS ではない」で扱います)。SPDX を見たら、必ず公式ライセンスページで条件の全文に当たるのが確実です。

結合形態で義務が変わる

同じコピーレフトでも、自分のコードと OSS をどう「結合」するかで、ソース公開義務の及ぶ範囲は変わります。ここが OSS 採用でいちばん誤解されやすいところです。軸は大きく 4 つ —— 動的リンク / 静的リンク / 別プロセス(CLI 呼び出しや標準的なプロセス間通信)/ ネットワーク提供(SaaS)です。

ライセンス別に、結合形態がどう効くかを見ていきます。

• LGPL(限定的コピーレフト / weak copyleft): 動的リンクなら義務は限定的で、自分のコードは独自ライセンスのままにできます。注意は静的リンクです。利用者が LGPL ライブラリを自分で差し替え・再リンクできる手段(オブジェクトファイルの提供等)を用意すれば義務を果たせます(LGPL-3.0 §4)。「静的リンクしただけ」で見落としやすい義務です。
• GPL(全体に及ぶコピーレフト / strong copyleft): 「派生著作物(結合作品)」の境界が最大の論点です。FSF はリンク種別を問わず「結合すれば派生」とする立場(動的リンクでも)を取りますが、Linux カーネルの作者である Linus Torvalds は「ユーザー空間プログラムは派生ではない」とし、判例で明確化されていない部分が多いのが実情です。実務では、例えば自分のコードのソースを公開したくない場合は、LGPL を選ぶ、別プロセス + 標準的な入出力でプロセス境界を明確にする、といった方法があります。逆に公開して構わない・むしろ公開したい場合は、GPL のまま結合して差し支えありません。
• AGPL◆(ネットワークコピーレフト): ネットワーク経由でユーザーがプログラムと対話する場合、改変版の対応ソースを提供できる手段(ダウンロードリンク等)の提示が求められ得ます。ただし改変せず単体で使うだけなら義務は限定的になりやすい一方、改変・結合・一体提供の形によって対応ソースの範囲は変わります。発動範囲は結合・改変・配布の形態によって変わるため、公式条文と専門家の確認が要ります(断定は禁物)。

出典: Mozilla MPL 2.0 / OSI LGPL-3.0 / FSF — Why the AGPL。

「ソースが見えても OSS ではない」罠

GitHub でソースが公開されていても、それが「オープンソース」とは限りません。ソースアベイラブル(source-available、ソースは見えるが OSS ではない)と呼ばれるライセンスが、2018 年(MongoDB の SSPL)以降、目立つようになりました。クラウド事業者によるホスト型再販(ただ乗り)を抑止する狙いです。OSI は、これらを主に OSD 第 6 項(用途・分野での差別の禁止)に反するとして OSS とは認めていません(他ソフトを制限しないとする第 9 項も論点として挙げられます)。代表例を挙げます。

• BSL 1.1(Business Source License): 一定期間(最長 4 年)経過後に GPL 等の OSS へ自動で切り替わる。それまでの利用範囲は各プロジェクトが定める「追加利用許諾(Additional Use Grant)」次第で、実際の制限(本番利用や競合サービス提供の可否など)はプロジェクトごとに異なります。MariaDB 由来で、HashiCorp が 2023 年に採用。
• SSPL(Server Side Public License): サービスとして提供する場合、管理 UI やストレージまで含めた全体のソース公開を求める。MongoDB(2018)、Elastic(2021、ただし 2024 に AGPLv3 を選択肢として追加。ELv2〔Elastic License v2〕/SSPL は継続)、Redis(2024、ただし Redis 8 以降は AGPLv3 も選択可)が採用。
• ELv2 / RSAL / CCL: ホスト型サービスの提供禁止や、競合 SaaS の提供禁止などを条件にする(Elastic / Redis / Confluent)。

ここでの実務ポイントは、そのソフト自体をホスト型サービスとして外販すると違反になり得る一方、社内利用や、自分のサービスの一部品として使うだけなら問題にならないことが多いという点です(ただし禁止される提供形態はライセンスごとに異なるため、採用前に各条文を確認)。自分の使い方を見極めれば、過度に恐れる必要はありません。

そしてライセンスは動きます。Redis は 2024 年 3 月に BSD から SSPL/RSAL へ移行し、直後に Linux Foundation が Valkey をフォークしました。2025 年 5 月には AGPLv3 を追加(RSALv2 / SSPLv1 との選択制)し、AGPLv3 を選べば OSI 認定 OSS として使えるようになりました。採用前に「ライセンス変更の履歴」を確認する習慣が効きます。

身近で間違えやすい例を 2 つ挙げます。AI アプリ開発基盤の Dify は Apache 2.0 をベースにしつつ、「マルチテナント環境としての運用」には別途の商用ライセンス(書面承認)が必要(Dify では 1 テナント = 1 ワークスペース)で、コンソール / アプリのロゴ・著作権表示の保持も求めます(フロントエンドを使わない利用は対象外)。テストや単一ワークスペースの内部利用は通常問題になりにくい一方、複数ワークスペースを分けて全社や複数顧客に提供する形は該当し得ます。「どこで何が動いているか」を把握していないと気づかず条件に触れるため、線引きは公式規約で確認しましょう。

ライセンス絡みの「無料の罠」は OSS に限りません。Docker Desktop は個人・教育・非商用 OSS・小規模企業(従業員 250 人未満かつ年間売上 1,000 万ドル未満)は無償ですが、それを超える規模の業務利用には有償サブスクリプションが必要です。一方 Docker Engine(オープンソースのコンテナ実行基盤)は無償のままなので、規模の大きい組織は「Docker Desktop に課金する / Engine + 別手段で代替する」の判断になります(これは OSS の段の話ではなく、製品ごとの商用ライセンス設計の例です)。

細部の落とし穴 — 特許条項と寄稿のルール

ここからは一歩踏み込んだ各論です。まずパーミッシブの中にも差があります。MIT や BSD は特許について明文がなく、寄稿者の特許で訴えられる余地が残ります。一方 Apache 2.0 は特許の明示的な付与 + 特許訴訟を起こすと権利が終了する報復条項を持ち、NOTICE ファイルの保持も求めます。なお Apache 2.0 と GPLv2 は条項の相性が悪く非互換です(GPLv3 とは片方向で互換)。「パーミッシブだから何でも同じ」ではない、という点は押さえておきましょう。

次に寄稿(コントリビュート)する側のルールです。OSS には、同じコードを複数ライセンスで配るデュアル / トリプルライセンス(例: MySQL は GPL + 商用、Redis 8 は 3 種)があり、商用版で収益を得つつ OSS 版でコミュニティを確保する戦略がよく使われます。ここで効いてくるのが CLA と DCO の違いです。

• CLA(Contributor License Agreement): 寄稿者がプロジェクトに広い著作権ライセンス(または譲渡)を与える契約。その内容次第で、運営側は後からライセンスを変更しやすくなります(どこまで可能かは CLA の条項による)。MongoDB・Elastic・Redis・HashiCorp はいずれも CLA を採用しており、再ライセンス時にこれが働いたとされます。
• DCO(Developer Certificate of Origin): コミット末尾の Signed-off-by で「自分にライセンスする権利がある」と宣誓する軽量な手続き。著作権の移転はせず、各寄稿者が著作権者のまま残ります。そのため CLA と違い運営側が一方的にライセンスを変更することはできず、変更には原則として全寄稿者の同意が要り、大規模プロジェクトでは事実上困難です(例えば Linux カーネルが GPLv3 へ移行していないのは、主要開発者が GPLv3 の tivoization 条項などに反対し "GPLv2 only" を選んでいることが主因で、加えて数千人規模の著作権者の同意を要する分散所有の構造もあり一方的な再ライセンスができません)。

自分が貢献するプロジェクトが将来どうライセンスを変え得るか、CLA の有無で見当がつきます。

判例が示す「ライセンスは飾りではない」

OSS ライセンスは宣言だけの飾りではなく、裁判で繰り返し有効と認められてきた強制力のある条件です。米国の Jacobsen v. Katzer(2008、連邦巡回控訴裁。OSS ライセンスの一種である Artistic License を巡る事案)は、OSS ライセンスの条件は「強制可能な著作権上の条件」であり、違反は単なる契約違反ではなく著作権侵害として差止できると確立しました。組み込み機器では GPL 違反が頻発し、BusyBox をめぐる一連の訴訟(2007〜)では、ソース未提供のベンダーが和解やソース公開に追い込まれ、欠席した Westinghouse には 3 倍賠償が命じられています。

一方で、エンフォースメントには限界や論点もあります。ドイツの VMware 訴訟(2015〜2019)では、Linux 開発者が、自己の保護対象となる改変部分とそれが VMware の vmklinux に取り込まれたことを十分具体的に示せず、訴えは退けられました(争点は集合著作物ではなく、vmkernel と GPL 由来コードが結合著作物=二次的著作物に当たるかでしたが、その判断に至る前に立証段階で退けられています)。多人数開発の GPL コードで個別の寄与と取り込みを具体的に立証する負担が重い、という論点です。また、軽微な違反を盾に和解金を求める収益化目的の活動(McHardy のケース)は、コミュニティ志向のエンフォースメントとは区別され、裁判所に退けられています。

もう 1 つの教訓は、ソースアベイラブルへの移行はフォークを誘発することです。Elastic は OpenSearch を、Redis は Valkey を、HashiCorp(Terraform)は OpenTofu を生みました。Elastic のケースでは商標も絡み、AWS は自社の managed サービスを Amazon Elasticsearch Service から Amazon OpenSearch Service へ改称しています(名称=商標と、ソースコードのライセンスは別レイヤである点も押さえておくと混乱しません)。採用しているプロダクトがライセンス変更したとき、フォーク先へ移れるかも含めて見極めるのが賢明です。

まとめ — OSS 採用前チェックリスト

やることは「SPDX で段を特定 → 結合形態 → 配布形態 → 変更履歴」の順です。下のリストを LICENSE ノートや PR の説明欄に貼り付けて、公開前に確認してください。なお、このリストは最終的な法的判定ではなく、専門家へ相談すべきかを見極めるための一次スクリーニングです。

□ 1. SPDX 識別子を確認した(LICENSE 冒頭 / package.json / Cargo.toml 等。Go は LICENSE ファイルや pkg.go.dev)
□ 2. 自分の成果物が許容できる公開義務の度合い(=ソースをどこまで公開してよいか)を先に決めた
□ 3. その OSS がソース公開義務の及ぶ範囲(狭→広)のどの段かを特定した(PD〔パブリックドメイン〕/ パーミッシブ / 限定的・全体に及ぶコピーレフト / AGPL / ソースアベイラブル / 商用)
□ 4. 結合形態を確認した(動的 / 静的リンク / 別プロセス / SaaS)
□ 5. 配布形態を確認した(バイナリ / SaaS / 社内のみ。AGPL は改変版のネットワーク提供で対応ソース提供が要る場合あり)
□ 6. 義務を満たす準備をした(著作権表示・NOTICE 保持・改変部のソース提供 等)
□ 7. 推移的依存関係(transitive dependencies)も SBOM(ソフトウェア部品表)で棚卸しした
□ 8. 「ソースが見えても OSS でない」ライセンスでないか確認した(SSPL / BSL 等)
□ 9. ライセンス変更履歴を確認した(将来の移行リスク)
□ 10. 採用判断の根拠を記録した(なぜ OK と判断したか)

出典 / References

公式・定義

• OSI — Licenses
• OSI — The SSPL is Not an Open Source License
• FSF — Why the GNU Affero GPL

ライセンス原文

• Apache License 2.0
• GPL-3.0 / LGPL-3.0 / AGPL-3.0
• MariaDB BSL 1.1 / MongoDB SSPL / Elastic License v2

製品・サービスの利用条件(規約は変更され得るため、いずれも 2026-05 時点で確認)

• Docker Desktop ライセンス条件(Docker 公式)
• Dify Open Source License

判例・ライセンス移行

• Jacobsen v. Katzer(535 F.3d 1373、CourtListener)（一次）/ Jacobsen v. Katzer（Wikipedia）（補助）
• BusyBox GPL 訴訟 — Westinghouse 差止(SFC, 2010-08-03)（一次）/ BusyBox（Wikipedia）（補助）
• SFC — VMware Lawsuit FAQ
• Redis — What is Valkey?
• OpenTofu — Fork of Terraform

AI 補助の透明性: 本記事は、執筆者がもともと把握していた論点を出発点に、Claude(Anthropic 製 LLM)へ調査・整理・要点化を依頼してまとめ、その後に執筆者が各ライセンス原文・判例の一次情報を確認しながら加筆・修正したものです。法的助言ではない点と扱わない範囲は、冒頭の注意書きを参照してください。

著者について

大手電機メーカーで制御工学から 20 年以上の電機・ソフトウェア開発、加えて個人開発 約 10 年の実務経験を持ちます。ハードとソフト、企業と個人の両面で「知らないとリスクになる」基礎から発信し、いずれは AI の実践的な活用法なども扱っていく予定です。詳しくは このブログについて。