アプリケーション開発におけるライセンスの種類とその違い

ソフトウェアライセンスとは？

ソフトウェアライセンスとは、アプリケーションやソースコードを他者がどのように使用できるかを説明する一連のルールです。

ライセンスを通じて、アプリケーション作成者は以下を決定できます。

• アプリケーションを無料で使用できるか。
• ソースコードを変更できるか。
• アプリケーションを再販できるか。
• コードを商用プロジェクトで使用できるか。
• 二次的著作物を作成できるか。
• 変更後にソースコードを非公開にできるか。
• 変更したソースコードを共有しなければならないか。

つまり、ソースコードがGitHubで公開されていても、制限なく自由に使用できるわけではありません。

ライセンスがない場合、著作権ルールが自動的に適用されます。つまり、コードの所有者がすべての権利を保持し、他者は基本的にコードのコピー、変更、配布の許可を持たないことになります。

オープンソースはルールなしで自由という意味ではない

多くの人は、オープンソースはソースコードを条件なしで何にでも使用できると考えています。実際には、各オープンソースライセンスには異なるルールがあります。

一般的に、オープンソースライセンスはソフトウェアの使用、調査、変更、共有を許可します。しかし、一部のライセンスは非常に広い自由を認める一方、他のライセンスは派生物をオープンソースのままにすることを要求します。

ソフトウェアライセンスは通常、いくつかの主要なグループに分類されます。

1. パーミッシブライセンス
2. コピーレフトライセンス
3. 弱いコピーレフトライセンス
4. プロプライエタリライセンス
5. パブリックドメインライセンス

ソフトウェアライセンス比較表

ライセンス	種類	商用利用許可	変更許可	クローズドソース化可能	ソースコード公開必須	特許保護	適している用途
MIT	パーミッシブ	可	可	可	不可	明示されていない	ライブラリ、アプリケーション、個人プロジェクト
Apache 2.0	パーミッシブ	可	可	可	不可	可	企業プロジェクトやテクノロジー
BSD 2-Clause	パーミッシブ	可	可	可	不可	明示されていない	システム、ライブラリ、アプリケーション
BSD 3-Clause	パーミッシブ	可	可	可	不可	明示されていない	作成者名の保護が必要なプロジェクト
ISC	パーミッシブ	可	可	可	不可	明示されていない	小規模プロジェクトやJavaScriptライブラリ
GNU GPL	強いコピーレフト	可	可	派生物は不可	配布時には必須	バージョンによる	完全にオープンソースなアプリケーション
GNU LGPL	弱いコピーレフト	可	可	特定条件で可	ライブラリの特定部分のみ	バージョンによる	オープンソースライブラリ
GNU AGPL	強いネットワークコピーレフト	可	可	原則不可	ネットワークサービスを含めて必須	AGPLv3では可	サーバー、SaaS、ウェブアプリケーション
MPL 2.0	ファイルレベルのコピーレフト	可	可	個別ファイルでは可	MPLライセンスの修正ファイルのみ	可	オープンソースとプロプライエタリの混在プロジェクト
Unlicense	パブリックドメインスタイル	可	可	可	不可	不可	自由に解放することを意図したシンプルなコード
Proprietary	クローズドソース	所有者の許可による	通常不可	可	不可	契約による	内部アプリケーションや有料製品

1. MITライセンス

MITライセンスは最もシンプルで柔軟なオープンソースライセンスの一つです。

このライセンスは他者に以下を許可します。

• ソフトウェアを使用すること。
• ソースコードをコピーすること。
• ソースコードを変更すること。
• ソフトウェアを販売すること。
• コードを有料アプリケーションに含めること。
• アプリケーションをクローズドソースにすること。

主な要件は、著作権表示とMITライセンスのテキストをソフトウェアのすべてのコピーまたは重要な部分に含め続けることです。

MITライセンスの利点

• ライセンステキストが短い。
• 理解しやすい。
• 商用利用に友好的。
• クローズドソースアプリケーションで使用可能。
• ライブラリやフレームワークで広く使用されている。

MITライセンスの欠点

• 他者がコードを取得し、変更してクローズドソースアプリケーションとして販売できる。
• Apache 2.0ほど明確な特許保護がない。
• コード所有者は修正版をオープンソースのままにするよう要求できない。

適している場合

MITは、多くの制限を課さずにソースコードを可能な限り広く使用してもらいたい開発者に適しています。

2. Apache License 2.0

Apache License 2.0はMITと類似した特性を持っています。ソフトウェアの使用、変更、配布、商用アプリケーションへの組み込みが可能です。

主な違いは、Apache 2.0には特許付与に関する条項が含まれていることです。また、このライセンスはLICENSEファイルや、存在する場合はNOTICEファイルを通じた帰属表示を要求します。

Apache 2.0の利点

• 商用プロジェクトで使用可能。
• クローズドソースアプリケーションに組み込み可能。
• より明確な特許保護と条項がある。
• 企業プロジェクトに適している。
• ユーザーは行われた重要な変更を文書化する必要がある。

Apache 2.0の欠点

• ライセンステキストがMITより長い。
• 帰属表示とNOTICEファイルの管理が複雑になる可能性がある。
• 派生物をオープンソースにする必要はない。

適している場合

Apache 2.0は、より明確な特許保護を備えた柔軟なライセンスを求めるプロフェッショナルなプロジェクトや企業に適しています。

3. BSDライセンス

BSDライセンスはMITと同様のパーミッシブライセンスです。いくつかのバージョンがありますが、最も一般的なのはBSD 2-ClauseとBSD 3-Clauseです。

どちらもソースコードおよびバイナリ形式での使用、変更、配布を許可します。

BSD 2-Clause

BSD 2-Clauseは簡略化BSDライセンスとも呼ばれます。

主な要件：

• 著作権表示を維持すること。
• ライセンステキストと免責事項を維持すること。

BSD 3-Clause

BSD 3-Clauseには追加のルールが一つあります。作成者や貢献者の名前を許可なく派生物の宣伝に使用してはなりません。

BSDライセンスの利点

• シンプルで柔軟。
• 商用利用可能。
• クローズドソースアプリケーションに組み込み可能。
• ライブラリやシステムソフトウェアに適している。

BSDライセンスの欠点

• コード変更の共有が不要。
• Apache 2.0ほど明確な特許条項がない。
• 他者がコードを使用してプロプライエタリ製品を作成できる。

4. ISCライセンス

ISCライセンスは非常に簡潔なパーミッシブライセンスです。機能的にはMITやBSD 2-Clauseとほぼ同じです。

ユーザーは、著作権表示と許可テキストを維持する限り、ソフトウェアの使用、コピー、変更、配布が可能です。

ISCライセンスの利点

• 非常に短いテキスト。
• 適用が容易。
• 商用利用可能。
• クローズドソースアプリケーションで使用可能。

ISCライセンスの欠点

• 修正版をオープンソースにする必要はない。
• 特許条項がApache 2.0ほど明確ではない。
• 作成者が派生物のコードのオープン性を維持したい場合にはあまり適さない。

ISCはJavaScriptエコシステムのパッケージやライブラリでよく見られます。

5. GNU General Public License（GPL）

GNUは単一のライセンス名ではありません。GNUには以下のような複数種類のライセンスがあります。

• GNU GPL
• GNU LGPL
• GNU AGPL

GNU General Public License（GPL）は強いコピーレフトライセンスです。つまり、GPLソフトウェアを変更して派生物として配布する場合、そのアプリケーションのソースコードも互換性のあるGPLライセンスで提供しなければなりません。

GPLは商用利用を禁止していません。開発者はGPLソフトウェアを販売することも可能です。ただし、ソフトウェアの受領者はGPLが付与する権利（ライセンスが要求する条件の下でのソースコードへのアクセスを含む）を受け取らなければなりません。

GNU GPLの利点

• ソフトウェアとその派生物をオープンに保つ。
• 改良や発展がコミュニティに還元される。
• 他者がコードを取得して派生物のソースを非公開にするのを防ぐ。
• コミュニティベースのプロジェクトに適している。

GNU GPLの欠点

• プロプライエタリ製品での使用が困難。
• 他のライセンスのコードとの組み合わせに注意が必要。
• 製品のソースコードを非公開にしたい企業にはあまり適さない。

内部コードを公開する必要はあるか？

常にではありません。

GPLアプリケーションを内部でのみ使用し、他者に配布しない場合、一般的にはソースコードを公に開示する必要は自動的に生じません。

GPLの主な義務は通常、ソフトウェアまたは派生物を配布する際に発生します。

6. GNU Lesser General Public License（LGPL）

LGPLはGPLに比べてより柔軟なコピーレフトバージョンです。

このライセンスは通常、ライブラリに使用されます。プロプライエタリアプリケーションは、ライセンス条件に従う限り、LGPLライブラリを使用またはリンクできます。GNUは、LGPLライブラリはプロプライエタリアプリケーションとリンク可能であると述べています。これは、派生物に対してより強いコピーレフト効果を持つGPLとは異なります。

GNU LGPLの利点

• オープンソースライブラリに適している。
• クローズドソースアプリケーションで使用可能。
• LGPLライブラリへの変更は引き続きLGPLルールに従う必要がある。
• すべてのコピーレフト保護を放棄せずにライブラリの利用を拡大する。

GNU LGPLの欠点

• 統合ルールがMITより複雑。
• リンクと配布の方法に注意が必要。
• ライブラリへの直接の変更は、ライブラリのソースコード共有義務を引き起こす可能性がある。

適している場合

LGPLは、オープンソースアプリケーションとプロプライエタリアプリケーションの両方で使用可能にしたいライブラリを作成する場合に適しています。

7. GNU Affero General Public License（AGPL）

AGPLは、ネットワーク経由で使用されるソフトウェア（例：ウェブアプリケーション、SaaS、API、サーバー、オンラインプラットフォーム）向けに特別に設計されたコピーレフトライセンスです。

通常のGPLでは、企業はソフトウェアを変更してサーバー上で実行しても、アプリケーションを配布しない限り、GPLのソースコード配布要件が適用されない場合があります。

AGPLは、ネットワーク経由でのソフトウェア使用に関する義務を追加します。ネットワーク経由で修正版のソフトウェアとやり取りするユーザーは、対応するソースコードにアクセスする機会を得なければなりません。

GNU AGPLの利点

• SaaSアプリケーションをオープンソースに保つのに適している。
• 他者がサーバーアプリケーションを修正してコードを非公開にするのを防ぐ。
• より強力なコピーレフト保護を提供する。

GNU AGPLの欠点

• プロプライエタリアプリケーションでの使用が困難。
• サーバーソースコードを公開したくない企業によって避けられることが多い。
• 統合には慎重な検討が必要。

8. Mozilla Public License 2.0

Mozilla Public License（MPL 2.0）はファイルレベルのコピーレフトライセンスです。

つまり、すでにMPL下にあるファイルを修正した場合、そのファイルはMPL下で利用可能なままにしなければなりません。ただし、それらのファイルは同じアプリケーション内の他のプロプライエタリファイルと組み合わせることができます。

したがって、MPLはMITのようなパーミッシブライセンスとGPLのような強いコピーレフトライセンスの中間に位置します。MPL 2.0はOpen Source Initiativeによって承認されたオープンソースライセンスでもあります。

MPL 2.0の利点

• GPLより柔軟。
• 修正されたオープンソースファイルはオープンのまま。
• クローズドソースコードと組み合わせ可能。
• オープンとプロプライエタリの両方のモジュールがあるプロジェクトに適している。

MPL 2.0の欠点

• MITやBSDより複雑。
• 開発者はどのファイルがMPL下にあるかを把握する必要がある。
• 派生物全体をオープンソースにしたい場合にはあまり適さない。

9. Unlicense

Unlicenseは、作成者が法律で許される最大限の範囲でコードをパブリックドメインに公開したい場合に使用されます。

一般的に、ユーザーは以下を行うことができます。

• コードをコピーする。
• コードを変更する。
• コードを販売する。
• コードを配布する。
• 帰属表示なしでコードを使用する。

Unlicenseはユーザーに非常に少ない条件を課します。

Unlicenseの利点

• 非常に自由。
• 帰属表示の義務がほぼない。
• 小さなコードスニペットやサンプルコードに適している。

Unlicenseの欠点

• パブリックドメインの概念は国によって扱いが異なる可能性がある。
• 企業プロジェクトには理想的ではない。
• 明確な特許保護を提供しない。
• 企業の貢献者はMITやApache 2.0を好む可能性がある。

10. プロプライエタリライセンス

プロプライエタリライセンスはクローズドソースアプリケーション向けのライセンスです。ソフトウェアを使用する権利は完全にアプリケーションの所有者によって決定されます。

ユーザーは通常、アプリケーションを使用する許可のみを受け取り、ソースコードを所有したり変更したりする許可は受け取りません。

例：

• サブスクリプションアプリケーション。
• 社内ソフトウェア。
• 有料のレジアプリケーション。
• ホテル管理システム。
• クライアント固有のアプリケーション。
• 有料のデスクトップソフトウェア。

一般的なルール

• アプリケーションをコピーできない。
• アカウントを共有できない。
• ソースコードを閲覧または変更できない。
• アプリケーションを再販できない。
• 使用はデバイス、ユーザー、会社、時間によって制限される。
• サブスクリプションが停止すると使用権が終了する。

適している場合

プロプライエタリライセンスは、アプリケーションがビジネス製品であり、ソースコードを非公開に保つ必要がある場合に適しています。

11. デュアルライセンス

デュアルライセンスは、同じソフトウェアに対して2つのライセンスオプションを提供する方法です。

例：

• オープンソースプロジェクト向けにGPLで無料。
• GPLに従わずにソフトウェアを使用したい企業向けに商用ライセンスで有料。

このモデルにより、ソフトウェア作成者はオープンソースコミュニティから利益を得ると同時に商用ライセンスを販売できます。

ただし、デュアルライセンスはソースコードの著作権が単一の企業または団体によって完全に所有されている場合に実装が容易です。多くの貢献者がいる場合、貢献権の管理を明確に確立する必要があります。

ソースコードにCreative Commonsを使用できますか？

Creative Commons（CC）は以下のものにより適しています。

• 記事。
• 画像。
• 動画。
• 音楽。
• ドキュメント。
• 学習教材。
• デザインやクリエイティブコンテンツ。

Creative Commonsは、ソフトウェアやハードウェアにCCライセンスを使用することを推奨していません。ソースコード、配布、変更などの問題に適切に対処する専用のソフトウェアライセンスが存在するためです。

単一のアプリケーションプロジェクトでは、以下のように使用できます。

• ソースコードにはMIT、Apache、GPL。
• ドキュメント、画像、その他の素材にはCreative Commons。

各部分を個別に説明し、ユーザーを混乱させないようにしてください。

パーミッシブとコピーレフトの違い

側面	パーミッシブライセンス	コピーレフトライセンス
例	MIT, Apache 2.0, BSD, ISC	GPL, AGPL
商用利用	許可	許可
コード修正	許可	許可
クローズドソース化可能	一般的に許可	派生物は一般的に不可
変更の共有義務	なし	特定条件下で必須
制限のレベル	よりシンプル	より厳格
企業への適性	非常に適している	ビジネスモデルによる
オープンソースコミュニティへの適性	適している	非常に適している
コード公開保護	低い	高い

どのライセンスを選ぶべきか？

MITを使用する場合

• シンプルなライセンスが欲しい。
• コードを可能な限り広く使用してもらいたい。
• コードがクローズドソースアプリケーションで使用されても構わない。
• ライブラリや個人プロジェクトを作成している。

Apache 2.0を使用する場合

• MITの自由が欲しい。
• より明確な特許条項が必要。
• 企業プロジェクトを作成している。
• 多くの貢献を受け入れる予定がある。

BSDを使用する場合

• シンプルなパーミッシブライセンスが欲しい。
• システムソフトウェアやライブラリを作成している。
• 作成者の名前が派生物の宣伝に使用されるのを避けたい。

GPLを使用する場合

• 派生物をオープンソースのままにしたい。
• 企業がコードを取得して非公開にするのを防ぎたい。
• コミュニティプロジェクトを作成している。

LGPLを使用する場合

• ライブラリを作成している。
• ライブラリをプロプライエタリアプリケーションでも使用可能にしたい。
• ライブラリへの変更はオープンに保ちたい。

AGPLを使用する場合

• SaaSやサーバーアプリケーションを作成している。
• ネットワーク経由で使用される変更を共有したい。
• 企業がサーバー上で修正版を非公開で実行するのを防ぎたい。

MPL 2.0を使用する場合

• コードの一部をオープンに保ちたい。
• コードをプロプライエタリモジュールと組み合わせたい。
• MITとGPLの中間が必要。

プロプライエタリライセンスを使用する場合

• ソースコードを公開できない。
• アプリケーションがビジネス目的で作られている。
• ソフトウェアの使用を制限したい。
• アプリケーションがライセンスまたはサブスクリプションシステムで販売される。

GitHubでのライセンス適用例

通常、ライセンステキストは以下のファイルに保存されます。

LICENSE

または：

LICENSE.md

そのファイルはリポジトリのメインまたはルートフォルダに配置されます。GitHubはまた、プロジェクトがクローン、ダウンロード、配布されたときに利用できるように、ライセンスファイルをリポジトリに直接含めることを推奨しています。

プロジェクト構造の例：

app-name/
├── app/
├── public/
├── src/
├── README.md
├── LICENSE
└── package.json

README.mdに簡単な情報を追加することもできます。

## ライセンス

このプロジェクトはMITライセンスの下で提供されています。
詳細はLICENSEファイルを参照してください。

ライセンスを選ぶ前に確認すべきこと

ライセンスを決定する前に、以下を考慮してください。

1. アプリケーションは商用利用可能か？
2. 他者はソースコードを変更できるか？
3. 変更を共有する必要があるか？
4. 派生物をクローズドソースにできるか？
5. アプリケーションはSaaSとして使用されるか？
6. プロジェクトはサードパーティライブラリを使用しているか？
7. 各依存関係のライセンスは互換性があるか？
8. 他の貢献者からのコードはあるか？
9. 特許保護は必要か？
10. アプリケーションはクライアントに販売されるか？

人気があるからという理由だけでライセンスを選ばないでください。プロジェクトの目標とアプリケーションの使用方法に基づいてライセンスを選択してください。

結論

各ソフトウェアライセンスは異なる権利と義務を提供します。

MIT、BSD、ISCはユーザーに広い自由を与えたいプロジェクトに適しています。Apache 2.0は同様の自由に加えてより明確な特許条項を提供します。

GPLは派生物をオープンソースに保つのに適しています。LGPLはライブラリにより適しており、AGPLはウェブアプリケーション、サーバー、SaaSに追加の保護を提供します。

MPL 2.0は特定のファイルのみをオープンに保つため、中間的な立場と言えます。一方、プロプライエタリライセンスはソースコードを非公開に保たなければならないビジネスアプリケーションにより適しています。

ライセンスの選択は開発の早い段階で行うべきです。アプリケーション作成者を保護するだけでなく、明確なライセンスはユーザーや貢献者が何が許可され、何が許可されていないかを理解するのにも役立ちます。

注記： この記事は一般的な説明を提供するものであり、法的アドバイスではありません。大規模な商用アプリケーション、依存関係の多用、または多くの貢献者がいるプロジェクトについては、ライセンス選択に関して知的財産法に詳しい人に相談してください。