「OSSって、要するにタダで使えるソフトのことでしょ？」
エンジニアなら一度は口にし、そして一度はベテランに真顔で訂正された経験があるはずだ。かく言う私も、若かりし頃に「ソースが公開されてればOSSっすよね」と言い放ち、先輩に静かに首を振られた口である…orz
OSSは「タダのソフト」ではない。OSSとは、レシピを公開した料理本だと思ってほしい。料理（=動くソフト）だけでなく、その作り方（=ソースコード）までまるごと公開し、しかも「自由に作っていいし、自分流にアレンジして配ってもいい」という明確な約束事（ライセンス）がセットになっている。この記事では、その「約束事」を料理本のメタファーで一気通貫に解きほぐしていく。
本記事は2026年6月時点の一次情報（OSI公式定義など）に基づいています。ライセンスは時代とともに変わる「生き物」です。最新情報は必ず公式を確認してください。
この記事の対象読者
- OSSを使ってはいるが、ライセンスの中身を読んだことがない人
- MIT、GPL、Apacheの違いを雰囲気で語っている人
- LLMを「オープンソースモデル」と呼んでいいのか迷ったことがある人
この記事で得られること
- OSSの正体（タダではなく「自由」の話）が腹落ちする
- OSIが定めた10の掟と、ライセンスの選び方の地図が手に入る
- AI時代の「オープンウェイト」と「オープンソース」の違いが分かる
- xz事件に代表される「OSSの影」への解像度が上がる
この記事で扱わないこと
- 個別ライセンスの逐条解説（弁護士の領分です）
- 自社プロダクトのライセンス選定の最終判断（法務に相談を）
1. OSSってなんだ？ — 二大誤解を成仏させる
まず、巷にはびこる二大誤解を成仏させよう。
| よくある誤解 | 実際は |
|---|---|
| 「無料だからOSS」 | 無料かどうかは無関係。OSSを有償で売ってもよい |
| 「ソースが見えればOSS」 | ソース公開だけでは不十分。配布条件が定義を満たす必要がある |
レシピ本の比喩で言えば、こうだ。
- タダで配るかどうかは店の判断。OSSのレシピ本を製本して売ってもまったく問題ない。
- レシピが読めるだけでは「料理本」とは呼べない。「このレシピで作った料理を売っちゃダメ」と書いてあったら、それはただの"見るだけメニュー"であって、本物の料理本ではない。
このあたりの線引きを、誰がどう決めているのか。それを定めたのが次の「10の掟」だ。
CUDAのように「広く使われていて無料」でも、ソースが非公開ならOSSではありません。「無料 = OSS」という思い込みは、ここで卒業しましょう。
2. OSSの10の掟 — レシピ本に求められる必須条件
OSSの定義を世界標準として管理しているのが OSI（Open Source Initiative）という非営利団体だ。1998年にBruce PerensとEric S. Raymondらが設立し、Debian Free Software Guidelinesを下敷きにした The Open Source Definition（OSD） を公開している。
OSDは、あるライセンスが「OSSを名乗ってよいか」を判定するための10個の基準を定めている。料理本に置き換えると、こんな10箇条だ。
| # | 掟（OSD） | レシピ本でいうと |
|---|---|---|
| 1 | 自由な再配布 | このレシピ本、誰に配ってもいいし売ってもいい |
| 2 | ソースコードの公開 | 完成料理だけでなく作り方（材料・手順）も必ず付ける |
| 3 | 派生物の許可 | アレンジ版を作って、同じ条件で配ってよい |
| 4 | 作者ソースの完全性 | 改変は「差分（パッチ）」方式に限定してもよい。ただし別名にすればOK |
| 5 | 個人・集団を差別しない | 誰が作っても怒られない |
| 6 | 利用分野を差別しない | 商用でも研究でも、用途を制限しない |
| 7 | ライセンスの分配 | レシピを受け取った全員が同じ権利を持つ |
| 8 | 特定製品に依存しない | 「この本の付録としてのみ有効」みたいな縛りは不可 |
| 9 | 他のソフトを制限しない | 「同梱する他の料理も全部OSSにしろ」とは言えない |
| 10 | 技術中立 | 特定の調理器具（技術）に依存させない |
ここで第6条がいかにも"OSSらしい"。あえて原文と和訳を置いておく。
原文（OSD 第6条 見出し）: No Discrimination Against Fields of Endeavor
和訳: 利用分野に対する差別をしてはならない
出典: OSI公式 The Open Source Definition（後述の参考文献にリンクカードあり）
つまり「軍事利用はダメ」「悪人は使うな」といった制限すら、OSSの定義上は付けられない。自由を全員に与えるとは、気に食わない相手にも与えることだ、というOSIの硬派な思想がここに現れている。
10箇条はテーマで4グループに整理すると覚えやすい。
前節で「配布条件が定義を満たすか」がOSSの分かれ目だと述べた。その「配布条件」を実際に文章化したものが、次に話すライセンスである。
3. ライセンスという「お約束」— 選び方の地図
ライセンスとは、レシピ本の最初のページに書かれたこのレシピの使い方の約束事だ。世の中には無数のOSSライセンスがあるが、性格で大きく二派に分かれる。
-
パーミッシブ（寛容）系: MIT / BSD / Apache 2.0
- 「俺の名前さえ載せてくれれば、あとは煮るなり焼くなり好きにしてくれ」
- 改変版を非公開にしてもよい（プロプライエタリ化OK）
-
コピーレフト系: GPL / AGPL
- 「俺のレシピで作った料理は、そのレシピも必ず公開してね」
- 改変版も同じ条件で公開する義務がある（伝染性）
「じゃあ自分が公開する側ならどれを選ぶ？」を地図にするとこうなる。これは優劣の比較ではなく、目的別の選定ガイドとして読んでほしい。
代表的な顔ぶれを早見表にしておく。
| ライセンス | 系統 | 改変版の公開義務 | 一言でいうと |
|---|---|---|---|
| MIT | パーミッシブ | なし | とにかく緩い。迷ったらこれ |
| BSD（3条項） | パーミッシブ | なし | MIT類似。宣伝条項に注意 |
| Apache 2.0 | パーミッシブ | なし | 特許条項つきで企業に人気 |
| GPL v3 | コピーレフト | あり（配布時） | レシピも開けと迫る伝染性 |
| AGPL v3 | コピーレフト | あり（ネット提供時も） | SaaSの抜け穴を塞ぐ最強コピーレフト |
コピーレフトの「伝染性」を甘く見ると、自社のクローズドなコードまで公開義務が及ぶ事故が起きます。DockerやKubernetesのような巨大OSSを業務で組み込むときは、依存ライブラリのライセンスまで棚卸ししましょう。
ここまでは「約束事は固定」という前提で話してきた。だが現実のライセンスは、企業の都合でコロコロ変わる生き物だ。その生々しい実例が、次のRedis劇場である。
4. 実例：ライセンスは生き物 — Redis出戻り劇場（2024-2025）
レシピ本の出版社が、ある日突然「来月から、うちのレシピで店を開くのは禁止します」と規約を書き換えたら？ 常連の料理人たちは激怒し、一部は暖簾分け（フォーク）して独立する。これがまさに2024〜2025年にRedisで起きたことだ。
事の発端は、AWSなどのクラウド大手がRedisをマネージドサービスとして提供し、利益を吸い上げていく構図だった。Redis社は2024年3月、寛容なBSDからSSPLv1/RSALv2という"ソースアベイラブル"ライセンスへ切り替え、クラウド勢に課金を迫った。
ところがこのSSPLはOSI非承認、つまり「OSSを名乗れないライセンス」。コミュニティは反発し、AWS・Google・Oracleが後ろ盾となって Valkey という暖簾分け（フォーク）が誕生した。元のBSDライセンスを引き継いだValkeyは、瞬く間に支持を集めた。
結局Redis社は1年で白旗を上げ、2025年5月のRedis 8でOSI承認の AGPLv3 を追加。OSSへ"出戻り"した。Redis生みの親であるantirez氏は、自分の書くコードはオープンソースでなければ気が済まない、という趣旨を熱く語っている。一方で「時すでに遅し」「Valkeyに移った人は戻らない」という冷ややかな声も多く、コミュニティの信頼を一度失う代償の大きさを物語っている。
この一件の教訓はシンプルだ。OSSのライセンスは企業の判断で変わりうる。だからこそ、共通言語である定義OSDと、最終手段であるフォークが、コミュニティの安全装置になっている。
5. AI時代のOSS — 「オープンウェイト」は「オープンソース」じゃない
さて、ここからが本記事の白眉。ローカルLLMをいじっていると、必ずこの疑問にぶつかる。
「HuggingFaceから落としてきたこのモデル、"オープンソース"って名乗っていいの？」
答えを先に言うと、多くの場合ダメ。それらは「オープンソース」ではなく「オープンウェイト」であることがほとんどだ。
OSIは2024年10月28日、Open Source AI Definition 1.0（通称OSAID） を公開した。AIをレシピ本に例えると、構成要素はこうなる。
- モデルの重み（パラメータ） = 完成した秘伝のタレ
- 学習コード・推論コード = タレの作り方・火加減のメモ
- 学習データ = タレの材料と配合
OSAID 1.0が「オープンソースAI」と認めるには、重みとコードを公開し、さらに学習データについて"十分に詳細な情報"を開示することを求める。
原文（OSAID 1.0 / 学習データ要件の核心）: so that a skilled person can build a substantially equivalent system
和訳: 技術に通じた者が実質的に同等のシステムを構築できる程度に（情報を開示すること）
出典: OSI公式 The Open Source AI Definition 1.0（参考文献にリンクカードあり）
ポイントは、学習データそのものの公開までは必須ではないこと（プライバシーや権利の都合に配慮）。だが「同等品を再現できる説明」は要る。
ここで多くの公開モデルが脱落する。MITやApache 2.0で配られていても、それは「タレは分けてあげる、でも作り方は秘密」という状態 ―― すなわちオープンウェイトにすぎない。
llama.cppやvLLMといった推論エンジン自体は堂々たるOSSだ。だが、その上で動かすGGUFモデルが「オープンソースか」は別問題、というのがAI時代の新しい火種である。「うちのモデルはオープンソース」という宣伝文句を見たら、まず重み・コード・データの開示状況を確認するクセをつけたい。
6. OSSの影 — タダより高いものはない（xz事件）
OSSの理想は美しい。が、影もある。2024年3月に発覚した xz Utilsバックドア事件（CVE-2024-3094、CVSSスコア最大の10.0） は、OSSの構造的な弱点を世界に突きつけた。
レシピ本でたとえよう。世界中のキッチンで使われている定番のレシピ本があった。だが、その編集を支えていたのはたった一人の、疲れ果てたボランティアの料理長（実在の人物 Lasse Collin 氏）。
そこへ "Jia Tan" を名乗る人物が現れる。2年がかりで善良な改善提案を続け、料理長の信頼を勝ち取り、ついに共同編集者の座に就いた。そして満を持して ―― レシピにこっそり毒（バックドア）を仕込んだのだ (;ﾟдﾟ)ﾎﾟｶｰﾝ
このバックドアは、特定の鍵を持つ攻撃者にOpenSSH経由でのリモートコード実行を許す代物だった。ほぼ全てのLinuxディストリビューションが汚染される寸前で、MicrosoftのエンジニアAndres Freund氏が「SSHログインが0.5秒ほど遅い」という違和感から偶然発見し、世界はギリギリで救われた。
この事件の本質は技術ではなく メンテナの持続可能性 です。インフラ級のOSSが、報酬のない少数のボランティアに支えられている現実が、ソーシャルエンジニアリングの格好の標的になりました。あなたがタダで使っているライブラリの裏には、燃え尽きかけた料理長がいるかもしれません。
OSSは「みんなのもの」だが、「みんなが面倒を見てくれる」わけではない。使うだけでなく、Issue報告・寄付・小さなPRで料理長を支える側に回ること ―― それがこの事件から我々が学ぶべき教訓だ。
7. よくある誤解・落とし穴と対処法
| 症状・誤解 | 原因 | 対処法 |
|---|---|---|
| 「無料だからOSS」と思っている | 自由（freedom）と無料（free）の混同 | OSSの"free"は「自由」。有償OSSも存在すると理解する |
| ソース公開＝OSSだと思う | OSD未達のソースアベイラブルが多い | OSI承認ライセンスか確認する |
| MITだから何でも自由 | 著作権表示の保持義務を見落とす | LICENSEファイルとコピーライト表記を必ず残す |
| GPLライブラリを社内クローズドに組込み | コピーレフトの伝染性 | 配布有無を確認。SaaSならAGPLにも注意 |
| 「オープンソースモデル」と宣伝 | オープンウェイトとの混同 | 重み・コード・学習データ説明の開示を確認 |
| 依存ライブラリのライセンス不明 | 推移的依存の見落とし | SBOMツールでライセンスを棚卸し |
| フォークすれば元のライセンス無視できる | 派生物にも元のライセンスが及ぶ | フォーク元のライセンス条件を継承する |
| メンテナが消えて詰む | 単一ボランティア依存 | 保守体制・コミュニティの健全性も選定基準に入れる |
8. 学習ロードマップ
OSSとの付き合いは「使う→貢献する→運営する」の三段ロケットで深まる。
- 初級: まずは普段使っているPythonやJavaScriptのライブラリのLICENSEファイルを開いてみる。これだけで世界が変わる。
- 中級: タイポ修正でいい。最初のPRを出してみよう。料理長は地味な貢献ほど喜ぶ。
- 上級: 自分のリポジトリにライセンスを付け、コミュニティを育てる。Redis劇場の当事者意識が芽生える。
用語集（Glossary）
| 用語 | 意味 |
|---|---|
| OSS | Open Source Software。OSD準拠ライセンスで配布されるソフト |
| OSI | OSDを管理する非営利団体。ライセンスのOSS該当性を審査する |
| OSD | The Open Source Definition。OSSを名乗る条件を定めた10箇条 |
| パーミッシブ | 改変版の非公開を許す寛容なライセンス（MIT/BSD/Apache） |
| コピーレフト | 改変版にも同条件の公開を義務づける伝染性ライセンス（GPL/AGPL） |
| ソースアベイラブル | ソースは見えるがOSD未達でOSSではない状態（SSPL等） |
| フォーク | 既存OSSを複製して独立開発すること（暖簾分け） |
| オープンウェイト | 重みのみ公開され、コード・データが伴わないモデル |
| OSAID | Open Source AI Definition。AI版のオープンソース定義 |
| SBOM | Software Bill of Materials。依存とライセンスの部品表 |
まとめ
- OSSは「無料」ではなく「自由」の話。有償OSSも存在する。
- ソース公開だけでは不十分で、OSI定義の 10の掟 を満たして初めてOSSを名乗れる。
- ライセンスはパーミッシブ vs コピーレフトの二派。目的で選ぶ。
- ライセンスは生き物。Redis劇場が示すように、企業の都合で変わり、コミュニティはフォークで対抗する。
- AI時代はオープンウェイト ≠ オープンソース。OSAIDが新しいものさしになった。
- xz事件が示すとおり、OSSの理想はメンテナの献身に支えられている。使うだけでなく支える側へ。
正直に告白すると、私自身もこの記事を書くまで「オープンウェイト」と「オープンソース」を雑に同一視していた。レシピを公開する文化に、こんなに深い思想と生々しい攻防が詰まっているとは ―― OSS、奥が深すぎて草。タダで使わせてもらっている料理長たちに、改めて感謝である。
関連記事
参考文献（一次情報）
The Open Source Definition（OSI公式・10箇条の原典）
The Open Source AI Definition 1.0（OSI公式・AI版定義）
Redis is now available under the AGPLv3 open source license（Redis社公式ライセンスページ）
XZ Utils backdoor / CVE-2024-3094（事件の概要）
最新のAI・GPU・OSS情報はXでも発信しています。