オープンソースプロジェクトを始める際、最初に直面する重要な決断の一つが「どのライセンスを選ぶか」です。
MIT、Apache、GPL、BSDなど多くの選択肢があり、それぞれ異なる特徴を持っています。

本記事では、プロジェクトの特性に応じて最適なライセンスを選ぶための実践的なガイドと選択基準を解説します。

目次 [ close ]
  1. ライセンス選択が重要な理由
  2. ライセンス選択の手順
  3. プロジェクト特性別の推奨ライセンス
    1. 企業向けライブラリ・フレームワーク
    2. 個人開発の小規模ツール
    3. コミュニティ駆動のプラットフォーム
    4. SaaS/クラウドサービス
  4. 特殊な考慮事項
    1. デュアルライセンス戦略
    2. ライセンスの互換性
    3. 企業のポリシー
  5. よくある質問
  6. まとめ

ライセンス選択が重要な理由

ライセンスの選択は、プロジェクトの将来に大きな影響を与えます。

  • コミュニティの形成：選んだライセンスによって、貢献者や利用者の層が変わります
  • 商用利用の可否：企業がプロジェクトを採用できるかどうかが決まります
  • 法的保護：開発者と利用者双方の権利と責任が明確になります
  • エコシステム：他のOSSとの組み合わせやすさが変わります

一度公開したライセンスの変更は困難なため、最初の選択が極めて重要です。

ライセンス選択の手順

以下の質問に答えていくことで、あなたのプロジェクトに最適なライセンスを見つけましょう。

STEP1
著作権を主張するか？
コードの著作権を完全に放棄したいですか？

YES → パブリックドメイン（Unlicense / CC0）を検討

  • 誰でも自由に使え、帰属表示も不要
  • 法的な責任を一切負わない
  • 小規模なユーティリティやサンプルコードに適しています

NO → ステップ2へ

STEP2
コピーレフトの程度
派生物にも同じライセンスの適用を求めたいですか？

YES（強いコピーレフト） → ステップ3へ

NO（パーミッシブ） → ステップ4へ

STEP3
コピーレフトの範囲（YESの場合）
ネットワーク越しの利用にもソースコード開示を求めますか？

YES → AGPL v3

  • SaaSやクラウドサービスでの利用時もソースコード開示が必要
  • 企業に採用されにくい可能性がある
  • MongoDB、Grafanaなどが採用（後に変更も）

NO → 次のQへ

ライブラリとして使われる可能性が高いですか？

YES → LGPL v3

  • ライブラリ自体の改変は開示が必要
  • ライブラリを使うだけなら開示不要
  • 商用ソフトウェアでも採用しやすい

NO → GPL v3 または GPL v2

  • 派生物すべてに同じライセンス適用が必要
  • Linuxカーネル（v2）、GCC（v3）などが採用
  • コミュニティ重視のプロジェクトに最適
STEP4
パーミッシブライセンスの選択（NOの場合）
特許条項が必要ですか？

YES → Apache License 2.0

  • 明示的な特許ライセンス付与
  • 特許訴訟への防衛条項あり
  • 企業での採用に強い（Google、Apache財団など）

NO → 次のQへ

シンプルさを最優先しますか？

YES → MIT License

  • 最も短く理解しやすい
  • 広く採用されている（jQuery、Node.js、Railsなど）
  • 企業でも個人でも使いやすい

NO → BSD 3-Clause または BSD 2-Clause

  • MITより若干詳細な条項
  • 宣伝条項の有無で2種類（3-Clauseは宣伝禁止条項あり）
  • BSD Unixの伝統を持つプロジェクト向け

プロジェクト特性別の推奨ライセンス

企業向けライブラリ・フレームワーク

推奨：MIT / Apache 2.0

商用製品に組み込まれやすく、エコシステムが広がりやすいです。

  • MIT: React、Vue.js、.NET Core
  • Apache 2.0: Kubernetes、Android、TensorFlow

個人開発の小規模ツール

推奨：MIT / Unlicense

シンプルで管理しやすく、多くの人に使ってもらえます。

コミュニティ駆動のプラットフォーム

推奨：GPL v3 / AGPL v3

改変版も公開されるため、コミュニティ全体が恩恵を受けます。

  • GPL v3: WordPress、Git
  • AGPL v3: Mastodon（以前）、OnlyOffice

SaaS/クラウドサービス

推奨：AGPL v3（オープン重視）/ Apache 2.0（採用重視）

ビジネスモデルによって選択が分かれます。

特殊な考慮事項

デュアルライセンス戦略

オープンソース版とは別に商用ライセンスも提供する方法です。

パターンGPL + 商用ライセンス
採用例MySQL、Qt、Elasticsearch（以前）
メリットOSSコミュニティと商用収益の両立

ライセンスの互換性

既存のOSSライブラリを使う場合、ライセンスの互換性を確認しましょう。

組み合わせ可能な例
  • MIT + Apache 2.0 → Apache 2.0で統一
  • MIT + BSD → どちらでも可
組み合わせ不可の例
  • GPL + Apache 2.0（GPLv2の場合）
  • MIT → GPLは可、GPL → MITは不可

企業のポリシー

企業によっては特定のライセンスを禁止している場合があります。

一般的に避けられるライセンス：

  • AGPL（ソース開示リスク）
  • GPL（プロプライエタリ製品への組み込み困難）

歓迎されるライセンス：

  • MIT、Apache 2.0、BSD（制約が少ない）

よくある質問

後からライセンスを変更できますか？

既存のコードのライセンス変更は極めて困難です。すべての貢献者の同意が必要になるためです。最初の選択を慎重に行いましょう。

複数のライセンスを選べますか？

はい、デュアルライセンスやマルチライセンスが可能です。利用者が選べる形にすることで、より多くの用途に対応できます。

迷ったらどれを選ぶべき？

一般的なプロジェクトであればMIT Licenseが無難な選択です。短く理解しやすく、広く受け入れられています。

コピーレフトとパーミッシブ、どちらが良い？

コピーレフト（GPL系）:

  • メリット: 改変版も公開され、コミュニティが成長
  • デメリット: 企業での採用ハードルが高い

パーミッシブ（MIT/Apache系）:

  • メリット: 広く採用され、エコシステムが拡大
  • デメリット: 改変版がプロプライエタリ化される可能性

プロジェクトの目的と価値観に応じて選びましょう。

まとめ

ライセンス選択は、プロジェクトの性質と目標に応じて決まります。

選択のポイント
  1. コミュニティ重視 → GPL/AGPL
  2. 広く使ってもらいたい → MIT/Apache
  3. 特許保護が必要 → Apache 2.0
  4. とにかくシンプル → MIT/Unlicense

どのライセンスも一長一短があります。あなたのプロジェクトが何を重視するかを明確にし、それに合ったライセンスを選びましょう。迷った場合は、類似プロジェクトがどのライセンスを採用しているかを参考にするのも良い方法です。

適切なライセンス選択により、健全なOSSエコシステムの一員として、長く愛されるプロジェクトを育てていきましょう。

この記事は一般的な情報提供を目的としており、法的アドバイスではありません。具体的な法的問題については、専門家にご相談ください。