OSSライセンスの歴史についてメモ — BSD・GPL・MIT・Apache・AGPL

人工知能 Linux コラム

スタックチャンを触っていたら「ライセンス」が気になった

　最近、デスクトップロボット「スタックチャン」を購入しました。M5Stack というデバイスを使った小型のロボットで、自分なりに自作のAIソフトと連携させようと開発しています。そのなかで、公式のソフトを眺めていてふと気になることがありました。それが「ソフトウェアのライセンス」です。

　今日は、そのとき調べたことをきっかけに「OSS（オープンソースソフトウェア）のライセンスってどう生まれてきたんだろう？」というのを、簡単にまとめてみました。自分も含む、初心者向けに書いています。

　なお、AIも活用（Claude / Codex / Gemini をマルチエージェント的に調査とクロスチェック）した上で、自分自身でもなるべく信頼をおけるソースをもとに、何度かチェックと修正を行っていますが、私はライセンスの専門家ではなく、この記事には間違いが含まれている可能性があることはご了承ください（了承できない場合は、以降は読まないでください）。

　今回はあくまで「きっかけになれば」というスタンスで書いています。

MITだと思ったらGPLが混じっていた

　スタックチャンの公式ソフトを見てみると、「MIT ライセンス」というのが随所に書かれていました。MIT は OSS の中でも特に自由に使いやすいライセンスです。ところがよく見ていくと、ソフトの一部に「GPL v3」というライセンスのライブラリが混じっていたのです。

　 GPL v3 というのは、結構強力なライセンスで「このソフトを取り込んで改造したものを配布するときには、ソースコードを公開する義務があるよ」というルールが付いています。しかも、そのルールは結合した派生物の範囲に及んでいくので、よく「伝染する」と表現されたりします（厳密には派生物の判定はそんなに単純ではないのですが、ここでは単純化して説明しています）。

　つまり、知らずに公式ソフトをフォーク（コピー）して改造して配布してしまうと、自分のソフトも GPL になってしまいます。個人で楽しむ分（配布せずに自分の手元で動かすだけ）には、基本的に大きな問題はないのですが、知らずに公開すると予期せぬトラブルになる可能性もあります（特にビジネスがからむ場合）。

　余談ですが、今回なぜ私がライセンスに気づいたかというと、過去に任天堂さんがマリオカート ライブというラジコンをARと組み合わせて遊ぶゲームでドライバ周りのソフトに GPL のライブラリが使われていて、その部分のソースコードを Web 上で公開していた記憶があったためです。加えて、ライセンスファイルの位置が分かりづらかったので「スタックチャンもドライバまわりに何かあるのでは？」と勘で見てみたら、ビンゴで GPL v3 のライブラリが見つかりました。

　なお、このスタックチャンのGPLライセンスは、こちらのissueによると異なるライセンスのソフトに置き換えられています。あと、なぜかissueで The Karaage Emperor said と私のツイートへのリンクが貼られていました。

「ライセンスがある」と何がうれしいの？

　そもそも「ライセンス」って何だっけ？なんで GPL は厳しいんだっけ？という話を、ライセンスの歴史を振り返りながら説明していきます。

　まず大前提として「ライセンスなんて面倒だから付けない方がいいのでは？」と思う人がいるかもしれません。私も昔はそう思っていました。でも実は逆で、ライセンスがないソフトが一番使いづらかったりします。

　というのも、著作権法のデフォルトでは、ソフトを作った人だけが「複製・改変・再配布」を決められる状態になっています。ライセンスがない＝この許諾がどこにも書いていないわけです。誰かが勝手にコピーや改造をすると、理屈の上では著作権侵害として作者に訴えられる可能性が残ります。作者本人にそんなつもりがなくても、例えばビジネスで会社としてソフトを使おうとすると、訴訟の可能性がある以上、ライセンスがないソフトを黙って使うというのは、事実上不可能となります。

　許可を作者にとるという方法もありますが、連絡して「使っていいですか？」と確認するのも大変ですし、契約を取り交わす必要が出てきたらもっと大事になります。そこで「このソフトはこんな条件なら自由に使っていいですよ」という約束事をあらかじめ書いておくのがライセンス、というわけです。これがあると、作者も使う人もハッピーになれます。

OSSライセンス、その始まり

1980年代前半：元祖はBSDライセンス

　OSS ライセンスの元祖は BSD ライセンスです。これは UC Berkeley という大学が作っていた BSD Unix というプロジェクト発のもので、「使いたきゃ使え、ただし責任は知らんよ」という大学カルチャーをそのまま文章にしたようなライセンスです。

　ある意味とてもざっくりしていて「自由に使ってね」というメッセージが強いライセンスです。

1980〜90年代：MITライセンスが「最短にして最強」

　もう一つ、ほぼ同じ時期から育っていったのが MIT ライセンスです。これは MIT という大学の X Window System というソフトのライセンスがルーツです。

　MIT ライセンスの最大の特徴は、ものすごく短いことです。「著作権表示だけ残せば、あとは何してもいいよ」というシンプルさで、商用利用も改変も再配布も自由です。

　React、Node.js、Ruby on Rails、VS Code…私たちが普段触れている有名な OSS の多くがこの MIT を採用しています。OSS のライセンスの中で今やデファクトスタンダードと言ってもいい存在です。私も自分のOSSには、とりあえずこのMITライセンスをつけることが多いです。

GPLとリチャード・ストールマン — 「自由」にこだわった男の話

　ここでちょっと、OSS の歴史を語る上で絶対に外せない人物の話をします。リチャード・ストールマンです。

MITハッカー文化の終わりに立ち会った人

　ストールマンはもともと、1970 年代に MIT の人工知能研究所でハッカー（当時は単に「優れたプログラマ」の意味）として活動していた人です。当時の MIT は、研究者同士でソースコードを自由に見せ合って、必要なら改造して使うのが当たり前という文化がありました。

　ところが 1980 年代に入ると、研究所のメンバーが次々とベンチャー企業に引き抜かれ、ソフトウェアは商用化されていきます。ある日、研究所に新しい Xerox 9700 のレーザープリンタが入ってきて、ストールマンが「ドライバの調子が悪いからソースを見せてほしい」と頼んだら、相手から「NDA（秘密保持契約）があるから出せない」と断られた、という有名なエピソードがあります。

　ストールマンにとって、これは「自分の周りで当たり前だった自由なソフトウェアの文化が、目の前で消えていく」という許しがたい大事件だったようです。

GNUプロジェクト発表（1983年）

　そこでストールマンは「失われた自由なソフトの世界を自分の手で作り直すことを決意して、1983 年にGNU プロジェクトを発表しました。これは「Unix と完全に互換性を持ちつつ、すべて自由に使えるソフトだけで構成された OS を作る」という、当時としては気の遠くなるような計画です。

　GNU は「GNU's Not Unix」の略で、これ自体が再帰的になっています。ストールマンはここから、Emacs（エディタ）、GCC（C コンパイラ）、GDB（デバッガ）など、今でも開発の最前線で使われている有名なソフトを次々と書いていきます。

Free Software Foundation設立（1985年）

　1985 年には Free Software Foundation（FSF）を設立します。「自由ソフトウェア」の思想を世に広めるための非営利組織です。ここで打ち出された思想が、のちに「フリーソフトウェアの 4 つの自由」として整理されていきます。

  • 自由 0：どんな目的でも、自由にソフトを実行する自由
  • 自由 1：ソフトの仕組みを研究し、自分の好きなように改造する自由
  • 自由 2：コピーを他人に再配布する自由
  • 自由 3：改造したバージョンを他人に配る自由

（自由 0〜3 の番号は後から整理されたもので、最初からこの形だったわけではないのですが、今は FSF 公式の定義としてこの 4 つになっています。）

　よく誤解されますが、ストールマンが言う「Free」は無料のフリーではなくて、言論の自由（Free speech）のフリーです。「無料」じゃなくて「自由」の意味合いが強いようです。

コピーレフト発明（1989年：GPLv1）

　そしてストールマンは、ここでとんでもないことを考えつきます。

　普通に「自由に使ってね」とだけ言って公開すると、企業がそのソフトを取り込んで、クローズドソースの製品にしてしまう可能性があります。せっかくの自由が、誰かの利益のために閉ざされてしまいます。

　そこでストールマンが発明したのが、コピーレフトという概念です。

  • このソフトは自由に使っていいよ
  • 改造してもいいよ、再配布してもいいよ
  • ただし、改造した派生版も同じ GPL で公開してね

　つまり「自由は譲るが、その自由は次の人にも譲ること」を強制する。著作権（コピーライト）の仕組みをあえて使って、逆に自由を強制する。だから「コピーライト」をひっくり返して「コピーレフト」と呼ぶわけです。とてもユニークな発想ですね。この思想を文章にしたのが GPL（GNU General Public License）で、最初のバージョンが 1989 年に登場しました。

　GPL は単なるルールを定めた文書ではなくて、ストールマンの思想がこめられているということを知っておくと、ライセンスの持つ意味合いの理解が深まるかと思います。

GPLv2とLinuxの世界制覇（1991〜1992年）

　1991 年に改良版の GPLv2 が登場します。同じ 1991 年にリーナス・トーバルズが Linux カーネルを発表しました。

　ただし、Linux 最初のリリース（0.01）は実は GPL ではなく、「商用配布禁止」の独自ライセンスでした。リーナスが Linux のライセンスを GPLv2 に切り替えたのは翌 1992 年の話で、正式に GPLv2 で公開されたのはバージョン 0.95（1992 年 3 月）からです（Wikipedia: History of Linux）。リーナス自身、後に「Linux を GPL にしたのは、自分がやった一番良いことだった」と振り返っています。

　今はLinuxは、スマートフォンのAndroidでも、データセンターのサーバーでも使われているので、ストールマンの「自由なソフトを作るぞ」というプロジェクトは、形を変えて世界中に伝播したと言えるかもしれません。

2004年：Apache 2.0が「企業向けの保険」を加える

　もう一つの大物が Apache License です。Apache License 自体は 1995 年の 1.0、2000 年の 1.1 と進化してきましたが、特に有名なのが 2004 年に出た Apache License 2.0 です。これは Apache Software Foundation という、Web サーバーで有名な組織が作ったライセンスです。

　Apache 2.0 は MIT のような「ゆるさ」を保ちつつ、特許権についての扱いを明示しているのが特徴です。「貢献者は、このソフトに関する特許ライセンスを利用者に対して許諾しますよ（しかも特許訴訟を起こしたら自動的にその許諾を失いますよ）」とライセンス本文の Section 3 に書いてあるので、企業が安心して使いやすいライセンスとなっています。

　Android、Kubernetes、TensorFlow など、Google が関わる OSS のほとんどがこの Apache 2.0 です。

コピーレフト系の進化：GPLv3とAGPL

　GPL は時代の流れに合わせて進化しています。

2007年：GPLv3（家電の改造制限と戦う）

　GPLv3 は 2007 年に登場しました。きっかけは「TiVo 事件」というもので、米国の HDD レコーダー TiVo が Linux カーネル（GPLv2）を使いつつ、本体にハードウェア署名チェックを仕込んで「ソースは公開するけど、改造版はうちのハードで動かせなくしてるよ」という構造を作っていたのです。

　FSF（ストールマンが作った Free Software Foundation）は「これは GPL の精神に反する！」と激怒して、GPLv3 では「ハードウェアでの改造制限を禁止する条項」を追加しました。

　ところがこれにリーナス・トーバルズ（Linux の作者）が反発して、「Linux カーネルは GPLv2 のままで行く」と宣言しました。これは今でも変わっていません。Apple も GPLv3 を全社的に避けるようになって、macOS の bash が古いバージョンで止まって、今は zsh がデフォルトになったのも、これが一因のようです。

2002年・2007年：AGPL（SaaSの抜け穴を塞ぐ）

　もう一つ、AGPL（Affero GPL）というのもあります。これは GPL の「抜け穴」を塞ぐために生まれました。

　というのも、GPL は「ソフトを配布したとき」にソース公開義務が発動する仕組みです。ところが SaaS（Web サービス）でホスト提供する場合、ユーザーは Web 経由で使うだけで「配布」にはあたらないので、SaaS にしてしまえば、GPL のソースを使っていても公開義務が発生しませんでした。

　AGPL は「ネットワーク越しに使わせた瞬間にソース公開義務が発生する」とルールを追加して、この抜け穴を塞いだ強力なライセンスです。

　ちょっとややこしいのですが、この AGPL には 2 つの世代があります。元祖の Affero GPL v1 が 2002 年に Affero 社から出て、その後 FSF が GNU プロジェクトに取り込んで GNU AGPLv3 として 2007 年 11 月に発行しました。今普通に「AGPL」と言ったときに指されるのは、ほぼこの GNU AGPLv3 のことです。MongoDB が昔これを採用していたことで一気に有名になりました（MongoDB はその後、2018 年 11 月に独自の SSPL に切り替えています）。

AIの世界の「ライセンス」

　ライセンスはレガシーな話に見えて、実は今の AI 開発でも結構話題になっています。自分がよく目にする例ですと「YOLO」という画像認識のソフトがあります。

　YOLO は手軽で性能も良く、AI の画像認識でよく使われているのですが、ライセンスの歴史がかなりややこしいです。

  • 初代 YOLO（2016）は限りなく自由な独自ライセンスです
  • YOLOv4 以降は作者もコードベースもライセンスもバラバラになります。GPL 系もあれば、別研究者発の独立系もある
  • 特に Ultralytics 社の YOLOv5 が2023 年 4 月に GPL-3.0 から AGPL-3.0 へ変更され、同社系の v8 / v11 は最初から AGPL-3.0。商用利用には別途お金を払って商用ライセンスを購入する形になりました

　知らずに「YOLO 使えば認識バッチリじゃん！」と PoC（試作）で導入してしまって、いざ製品化の段階で「あれ、お金払うかソース全部公開しないとダメだぞ」と気づくケースを、聞いたことがあるようなないような…

　なので私自身は、画像認識を使うときには YOLO は基本的に選ばないようにしています。代わりのモデルとしては、前試したときは RT-DETRが速くて性能高くよかったです。

AI時代になって変わってきた話

　最近は AI コーディングが普及してきて、ライセンスをとりまく環境もかわりつつあるように感じます。

　例えば「GPL のソフトを AI で書き換えて、別のライセンスで公開する」ようなことが現実に起こっています。これはアリなのか？倫理的にどうなの？という議論があります。

　そもそも、GPL コードを学習している AI が生成したコードは、ライセンス違反にならないのか？という話もあったりもします（結論や判例はまだ十分ないというのが現状の認識です）。

　じゃあ安全策はと言うと、これは「人間が GPL のソースを一切読まずに、ゼロから独自に再実装する」やり方で、クリーンルーム実装という表現をされることがあります。

　ただ、これもちょっといびつな構造な気はします。本来「みんなで自由にシェアしよう」という GPL の精神があるのに、クローズドソースで使いたいだけのために、同じソフトを組織ごとに別々に作り直している。生産性も低いし、開発する人もそんなに嬉しくない気がします（お金がもらえるから OK、という考え方もあるでしょうが）。

　ストールマンが「自由なソフトを作るんだ」と GPL を発明した時代から 35 年以上経って、今度は AI 学習データという形でその「自由」が再び揺さぶられている。歴史が繰り返しているような気もしますね。

　どうせやるなら、みんなでシェアして多くの人が喜んでくれるソフトを作ったほうが幸せじゃないかな、というのは理想論かもしれませんが、私の正直な気持ちです。AI の登場でこのあたりがどう変わっていくのか、引き続き注目していきたいところです。

まとめ

　今回はスタックチャンの開発をきっかけに、OSS ライセンスの歴史を簡単に振り返ってみました。ライセンスの話は、難しく見えますがソフトウェアの歴史と思想がそのまま詰まっていて、知るとなかなか面白かったです。。

　エンジニアでも結構ライセンスを知らない人も多い印象がありますが、全く知らずにいると、ある日突然問題になったりすることもあるので、この記事で興味を持つ人を増やして、不幸を減らすことができたら幸いです。

参考リンク

　今回の記事を書くにあたって参照したリンクです。もっと正確に踏み込みたい方はこちらをどうぞ。

関連記事