まとめ

GitHubには多くのオープンソースプロジェクトが含まれています。ただ学習して使用するだけであれば、大きな影響はありません。しかし、商用利用する場合は、落とし穴を避けるために、様々なオープンソースライセンスの違いを理解する必要があります。この記事では、GPL、LGPL、BSD、MIT、Apacheの5つのオープンソースライセンスと、その中から適切なライセンスを選ぶ方法を紹介します。

BSDオープンソースライセンス

BSDオープンソースライセンスは、ユーザーに大きな自由を与えます。基本的に、ユーザーはソースコードを自由に使用および改変し、改変したコードをオープンソースソフトウェアまたはプロプライエタリソフトウェアとして再配布することができます。

ただし、この自由を享受するためには、BSD ライセンスを使用したコードを公開したり、BSD ライセンスのコードに基づいて二次開発を行ったりする際に、次の 3 つの条件を満たす必要があります。

1. 再リリースされた製品にソース コードが含まれている場合、元の BSD ライセンスをソース コードに含める必要があります。
2. 再リリースがバイナリ ライブラリまたはソフトウェアのみである場合は、元のコードからの BSD ライセンスをライブラリまたはソフトウェアのドキュメントと著作権表示に含める必要があります。
3. オープンソース コードの作成者または組織の名前、および元の製品の名前をマーケティング目的で使用することはできません。

BSDライセンスは、コード作者の著作権を尊重しながら、コード共有を奨励しています。BSDライセンスは、ユーザーによるコードの改変と再配布を許可しているだけでなく、BSDコードに基づく商用ソフトウェアの開発、頒布、販売も許可しているため、ビジネスフレンドリーです。そのため、多くの企業はオープンソース製品を選択する際にBSDライセンスを好みます。これは、サードパーティのコードに対する完全なコントロール権を持ち、必要に応じて改変やさらなる開発を行うことができるためです。

Apacheライセンス2.0

Apacheライセンスは、著名な非営利オープンソース組織Apacheが採用しているライセンスです。BSDライセンスと同様に、コード共有とオリジナル作者の著作権の尊重を奨励し、コードの改変やオープンソースソフトウェアまたは商用ソフトウェアとしての再配布も許可しています。遵守すべき条件もBSDライセンスと同様です。

1. コードのユーザーには Apache ライセンスを提供する必要があります。
2. コードを変更する場合は、修正したファイルに説明を含める必要があります。
3. 拡張コード（ソース コードから変更および派生したもの）には、ソース コード内の元の作成者が指定した契約、商標、特許通知、およびその他のコンテンツが含まれている必要があります。
4. 再発行された製品にNoticeファイルが含まれている場合、NoticeファイルにはApacheライセンスが含まれている必要があります。Noticeファイルに独自のライセンスを追加することは可能ですが、Apacheライセンスに大幅な変更を加えることはできません。

Apacheライセンスはビジネスにも非常に適しており、ユーザーは必要に応じてコードを変更し、オープンソースまたは商用製品としてリリースまたは販売することができます。

GPL

私たちは皆、GPLライセンスを採用しているLinuxをよく知っています。GPLは、コードの再利用を推奨するBSDライセンスやApacheライセンスとは大きく異なります。GPLの基本原則は、コードのオープンソース化と自由な利用、そして参照、改変、派生コードのオープンソース化と自由な利用です。しかし、改変・派生コードをクローズドソースの商用ソフトウェアとしてリリース・販売することは認められていません。だからこそ、私たちは商用企業のLinuxシステムや、個人、組織、商用ソフトウェア企業が開発した数多くのフリーソフトウェアプログラムなど、様々なフリーLinuxシステムを利用できるのです。

GPLライセンスの要点は、ソフトウェア製品がGPLライセンス製品を使用する場合（「使用」にはライブラリ参照、改変コード、派生コードが含まれます）、そのソフトウェア製品もGPLライセンスの下でライセンスされなければならない、つまりオープンソースかつフリーでなければならないということです。これは「感染性」と呼ばれるものです。GPLライセンスを使用する製品は、スタンドアロン製品として問題なく使用でき、フリーであることのメリットを享受できます。

GPL では、GPL ライブラリを使用するソフトウェア製品は GPL ライセンスの下でライセンスされる必要があることが厳密に規定されているため、オープンソース コード、商用ソフトウェア、または機密性を必要とするコードを GPL ライセンスの下で使用して二次開発を行う部門には適していません。

LGPL

LGPLは、主にクラスライブラリに使用されるオープンソースライセンスです。GPLでは、GPLライブラリを使用、改変、または派生するソフトウェアにもGPLライセンスの適用が義務付けられていますが、LGPLでは、商用ソフトウェアのコードをオープンソース化することなく、ライブラリリンクを通じてLGPLライブラリを商用ソフトウェアが利用することを許可しています。

ただし、LGPLライセンスのコードが改変または派生された場合、改変されたコード、改変部分に影響を与える追加コード、および派生コードはすべてLGPLライセンスの対象となります。したがって、LGPLライセンスのオープンソースコードは、商用ソフトウェアのサードパーティライブラリとして配布・販売するのに適しています。

ただし、LGPL ライセンスは、LGPL ライセンスに基づいてコードを変更および派生することでさらなる開発を目指す商用ソフトウェアには適用されません。

GPL と LGPL はどちらもオリジナルの作成者の知的財産権を保護し、他者がオープンソース コードをコピーして同様の製品を開発することを防ぎます。

マサチューセッツ工科大学

MITライセンスはBSDライセンスと同様に、非常に寛容です。作者は著作権のみを保持したいと考えており、その他の制限はありません。つまり、バイナリ形式でリリースする場合でもソースコード形式でリリースする場合でも、配布物には元のライセンスからの声明を含める必要があります。

MPL

MPLはMozilla Public Licenseの略で、1998年初頭にNetscape社のMozillaチームがオープンソースソフトウェアプロジェクト向けに設計したソフトウェアライセンスです。MPLライセンスが登場した最も重要な理由は、Netscape社がGPLライセンスでは開発者のソースコードに対するニーズと、それを使用することで得られるメリットのバランスが適切に取れていないと考えたことでした。よく知られているGPLやBSDライセンスと比較すると、MPLは権利と義務の面で多くの点で類似しています（いずれもOSIA認定のオープンソースソフトウェアライセンスに準拠しているため）。しかし、MPLにはそれらとはいくつかの重要な違いもあります。

• MPLでは、MPLライセンスの下でリリースされたソースコードへの変更は、他者がMPLの条件の下でソースコードを共有できるようにするために、MPLライセンスの下でライセンスされる必要があります。しかし、MPLライセンスでは「リリース」を「ソースコードとしてリリースされたファイル」と定義しているため、MPLでは企業が既存のソースコードリポジトリにインターフェースを追加することが許可されています。インターフェースプログラムのソースコードはMPLライセンスの下でライセンスされますが、リポジトリ内のソースコードは必ずしもMPLライセンスの下でライセンスされる必要はありません。これにより、商用ソフトウェア開発において他者のソースコードを借用する余地が残されています。
• MPL ライセンス契約の第 3 条第 7 項では、ライセンサーが MPL ライセンスに基づいて取得したソース コードを他の種類の独自のコードと混合して独自のソフトウェア プログラムを作成することを許可しています。
• MPL ライセンス契約は、GPL のようなソフトウェア特許を明確に反対しているわけではありませんが、ソースコードの提供者は、自らが特許権者であり、そのソースコードを無償で一般にライセンス付与しない限り、特許で保護されているソースコードを提供できないこと、また、オープンソース ライセンス契約に基づいてソースコードをライセンス付与した後で、そのソースコードに関連する特許を申請できないことを明確に規定しています。