ゲームのオープンソース化：ライセンスの選び方
遊びを届ける執筆にClaudeを使用しています。
自作ゲームをオープンソースにしようと思ったとき、最初に迷うのは「どのライセンスを選ぶか」です。MITやGPLといった名前は聞いたことがあっても、ゲームに適用したときに何が変わるのかがわかりにくく、結局ライセンスを明記しないまま公開してしまうケースは少なくありません。ライセンスを付けないと「すべての権利を留保している著作物」として扱われるのが一般的な考え方ですから、他者がコードを使いたくても使えない状態になります。 この記事では、ゲームを作る人がオープンソース化を決めたあとに直面する「どのライセンスが自分の目的に合うか」という問いに絞って、判断基準と手順を整理します。著作権の基礎やオープンソースの概念そのものは扱わず、ライセンス選択という一点に集中します。なお、法的な判断が必要な場面では専門家や公式情報を参照してください。
この記事の目次
ゲームのオープンソース化で扱う対象を分ける
ゲームのリポジトリには、複数の種類の成果物が混在しています。ライセンスを選ぶ前に、何をオープンソースにするのかを整理することが先決です。
- ソースコード（JavaScript・Python・C#など）：プログラムの論理そのもの
- アセット（画像・音楽・フォントなど）：著作物だが「ソフトウェアライセンス」が想定していない場合がある
- ゲームデザインドキュメント（仕様書・レベルデータなど）：文書や構造データ
ソースコードにはMITやGPLのようなソフトウェアライセンスが適切です。一方、画像や音楽にはCreative Commonsライセンス（CC）が広く使われています。「リポジトリ全体にMITを付ければいい」と思われがちですが、アセットの権利者が別人の場合や、購入したアセットに再配布禁止の条件が付いている場合には、そのアセットをMITリポジトリに含めることができません。最初に「コードだけ公開する」「アセットも含める」「それぞれ別ライセンスにする」のどれかを決めることが、ライセンス選択のスタート地点です。
主要ライセンスの特徴と向いている場面
ソースコードのライセンスとして頻繁に使われるものを比較します。
- MIT、利用・改変の自由度：非常に高い、派生物への条件：なし（コピーライト表示のみ）、商用利用：可
- Apache 2.0、利用・改変の自由度：高い、派生物への条件：特許に関する追加条項あり、商用利用：可
- GPL v3、利用・改変の自由度：高いが条件付き、派生物への条件：派生物も同じライセンスで公開が必要（コピーレフト）、商用利用：可（条件付き）
- LGPL v3、利用・改変の自由度：GPLより緩い、派生物への条件：ライブラリとして組み込む場合はGPL強制が緩和、商用利用：可（条件付き）
- AGPL v3、利用・改変の自由度：GPLに近い、派生物への条件：ネットワーク越しに使用した場合もソース開示が必要、商用利用：可（条件付き）
MITを選ぶ理由は「誰でも自由に使ってほしい」「ゲームエンジンやフレームワークとして再利用されることを歓迎する」という場合です。派生作品に何も要求しないため、商業スタジオが素材として採用しやすくなります。
GPL v3を選ぶ理由は「自分のコードを使うなら、派生物も同じく公開してほしい」という考え方に基づきます。コピーレフト（copyleft）と呼ばれる仕組みで、派生作品が同じGPLで公開されることを法的に要求します。自分の貢献が「クローズドな商品に吸収されて終わり」になることを避けたいときに有効です。
AGPL v3はウェブゲームに特に関係が深いライセンスです。GPLはソフトウェアを「配布」するときにソース開示が必要ですが、サーバー上で動かすだけなら配布に当たらないとされることがあります。AGPLはこの抜け穴を塞ぎ、ネットワーク越しに提供するサービスにもソース開示義務を課します。ブラウザゲームのサーバーサイドをオープンに保ちたいなら選択肢に入ります。
判断フローで自分の目的を確認する
ライセンスを選ぶ際は、次の問いに順番に答えるとほぼ絞れます。
- 「誰でも何にでも使ってほしい」か？ → YES なら MIT または Apache 2.0。特許侵害への防御条項が欲しければ Apache 2.0 が有力です。
- 「派生物もオープンであってほしい」か？ → YES なら GPL 系へ。
- ゲームがサーバー上で動くか？ → YES でコード公開も求めるなら AGPL v3。
- ライブラリ・エンジン部分だけを公開し、ゲーム本体への適用を緩めたいか？ → LGPL v3 が該当します。
- アセットはどうするか？ → コードとは別に CC BY や CC BY-SA をアセットフォルダに付ける。CC BY-SA はコピーレフト型です。
この問いに答えたあとで、選んだライセンスの原文（OSIが承認しているものは公式リポジトリに英語で掲載されています）を一度読んでおくことを勧めます。読みにくい場合は「平易な言葉で解説したページ」も多くの団体が提供しています。
ライセンスをリポジトリに組み込む手順
選んだあとの適用手順は以下のとおりです。
- LICENSEファイルをリポジトリのルートに置く。ファイル名はLICENSEまたはLICENSE.txtが慣例です。OSIやFSFの公式テキストをそのままコピーし、著者名と年を記載します。
- 各ソースファイルの先頭にSPDX識別子を入れる（任意だが推奨）。例：// SPDX-License-Identifier: MIT。これにより自動解析ツールがライセンスを正しく認識できます。
- READMEにライセンスの節を設ける。アセットとコードで異なるライセンスを使う場合は、それぞれどのファイル群にどのライセンスが適用されるかを明記します。
- 使用している外部ライブラリのライセンスと矛盾がないか確認する。GPL v3のライブラリを組み込んでいる場合、MIT で配布しようとしても条件が衝突します。npm lsやpip-licensesといったツールで依存関係を一覧化してから選択するのが確実です。
失敗しやすい点として、「フォント」の扱いがあります。ゲーム内で使うフォントにSIL Open Font License（OFL）が付いていることが多く、これ自体はオープンですが再配布条件があります。フォントの取り扱いはライセンス文書を個別に確認してください。
「後から変えられるか」を知っておく
一度ライセンスを付けて公開したコードを別のライセンスに変更することは、技術的には可能ですが条件があります。すべてのコミットの著作権者が自分一人なら比較的容易です。他者がコントリビュートしている場合は、全コントリビューターの同意が必要になることが一般的な考え方です。このためOSSプロジェクトの中には、コントリビューター・ライセンス・アグリーメント（CLA）と呼ばれる同意書を事前に取得する運営体制を採るものもあります。
MITで公開したコードは「既に配布された時点の許諾」は取り消せないと解釈されることが多く、過去の受領者はMITで使い続けられます。将来の配布分だけライセンスを変えることは可能です。「とりあえずMIT」で公開してから後悔するケースを避けるため、最初に目的を整理することに時間をかける価値があります。
次の行動
まず「コード・アセット・ドキュメントの三つのうち何を公開するか」を書き出し、それぞれに対して本記事の判断フローを当ててみてください。選択したライセンスのSPDX識別子はOSI（Open Source Initiative）の公式サイトで確認でき、正式なライセンス本文もそこから取得できます。法的な判断が必要な場合は弁護士など専門家に相談してください。
参考資料
- Open Source Initiative（OSI）公式ライセンス一覧
- Free Software Foundation（FSF）GPL/AGPL/LGPL 解説ページ
- Creative Commons ライセンス説明ページ（日本語版あり）
- SPDX License List（Linux Foundation）
