「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でも発信しています。