一般的なオープンソース ライセンスを調べる

  • 8 分

数百のオープンソース ライセンスが存在しますが、ほとんどのオープンソース ソフトウェアでは、比較的少数の一般的なライセンスが使用されています。 これらの一般的なライセンス、その条件、およびその影響を理解することは、組織がソフトウェアに安全に組み込むことができるオープンソース コンポーネントに関する情報に基づいた意思決定を行うのに役立ちます。

ライセンスの範囲

オープン ソース ライセンスは、非常に寛容なものから厳格なコピーレフトのものまで、広範なスペクトラムに存在します。

ライセンススペクトルのスクリーンショット。

制限付き (属性) ライセンス

スペクトルの左側 には、最小限の制限を課す許容ライセンスがあります。

  • 特性： 独自のソフトウェアをオープンソースにする必要なく、独自のソフトウェアでコードを使用できるようにします。
  • 主な要件: 帰属—著作権表示とライセンステキストを保持します。
  • 商用使用: 独自の商用ソフトウェアの構築と販売に完全に互換性があります。
  • ダウンストリームの自由: ユーザーは派生作品をオープンソースにするかどうかを選択できます。

例： MIT ライセンス、Apache License 2.0、BSD ライセンス。

コピーレフト (Copyleft) ライセンス

スペクトルの右側には、 強い相互的要件を持つコピーレフトライセンスがあります。

  • 特性： 派生物と組み合わせた作品には、同じライセンスを使用することが求められます。
  • ウイルス性: ライセンスは、ライセンスされたコードを組み込むか、または組み合わせたソフトウェアに "伝達" します。
  • ソース コードの要件: バイナリを配布するには、ソース コードを使用できるようにする必要があります。
  • 自由の保持: ソフトウェアが進化し、他のプロジェクトに組み込まれるにつれて、ソフトウェアがオープンソースのままであることを確認します。

例： GNU General Public License (GPL v2 および v3)、GNU Affero General Public License (AGPL)。

弱いコピーレフト ライセンス

このスペクトルの真ん中には 、オープン性と商用の実行可能性のバランスを取る弱いコピーレフト ライセンスがあります。

  • 特性： ライセンスされたコンポーネントをオープンソースに変更する必要がありますが、より大きな独自の作品にコンポーネントを組み込むことを許可します。
  • ライブラリに対応: 独自のアプリケーションで使用できるライブラリ用に設計されています。
  • ファイル レベルまたはモジュール レベルのコピーレフト: 要件は、アプリケーション全体ではなく、ライセンスされたコンポーネント自体に適用されます。
  • 実用的なバランス: コンポーネントの改善をオープンソースのまま維持しながら、商用使用を有効にします。

例： GNU Lesser General Public License (LGPL)、Mozilla Public License (MPL)、Eclipse Public License (EPL)。

一般的な制限付きライセンス

MIT ライセンス

MIT ライセンスは、最も単純で最も制限の少ないオープンソース ライセンスの 1 つです。

主な用語:

  • 権限： ソフトウェアの使用、コピー、変更、マージ、公開、配布、サブライセンス、および販売。
  • 条件： すべてのコピーまたは実質的な部分に著作権表示とライセンス テキストを含めます。
  • 制限： いかなる保証も、損害に対する責任も負いません。

プロジェクトが MIT を選択する理由:

  • 最大導入数: 最小限の制限により、広範な使用が促進されます。
  • シンプルで明確: わかりやすい短いライセンス テキスト。
  • 商用: MIT ライセンスのコードを専用ソフトウェアに組み込む障壁はありません。
  • 柔軟性： ユーザーは、ソフトウェアの使用方法と配布方法を完全に自由に利用できます。

一般的な MIT ライセンス プロジェクト: React、Angular、Node.js、jQuery、Rails、.NET Core。

組織への影響:

  • 商用利用に安全: MITライセンスのコンポーネントを制限なく専用ソフトウェアに組み込むことができます。
  • 属性が必要: 著作権表示を保持する必要があります。通常は、アプリケーションの文書や [バージョン情報] ダイアログにライセンス テキストを含めることで満たされます。
  • 特許付与なし: MIT ライセンスは特許に明示的に対処しないため、あいまいさが生じる可能性があります。

Apache License 2.0

Apache License 2.0 は、明示的な特許保護を備えた許容されるライセンスです。

主な用語:

  • 権限： 使用、再現、派生作品の準備、表示、実行、サブライセンス、配布。
  • 条件： 著作権に関する通知、ライセンス テキスト、および変更の通知を含める。特許通知を保持する。属性を指定します。
  • 特許付与: 共同作成者からの特許権の明示的な付与。
  • 特許報復: 特許権付与は、ライセンシーが共同作成者に対して特許訴訟を開始した場合に終了します。
  • 制限： 保証、責任、商標の権利はありません。

プロジェクトが Apache 2.0 を選択する理由:

  • 特許の明確さ: 明示的な特許付与は、法的確実性を提供します。
  • 変更の透過性: 変更を文書化する必要は、透明性を高めます。
  • 企業の信頼度: 明確な条件と特許保護により、企業は快適に貢献できます。
  • 互換性： GPL v3 と互換性があります (ただし、GPL v2 には対応していません)。

一般的な Apache 2.0 プロジェクト: Kubernetes、TensorFlow、Android、Spring Framework、Apache Hadoop、Apache Kafka。

組織への影響:

  • 特許保護: 明示的な特許付与は、共同作成者からの特許訴訟のリスクを軽減します。
  • 変更に関する通知: ファイルがいつ変更されたかを示す必要があります。
  • 属性の要件: MIT よりも少し複雑で、NOTICE ファイルの保存が必要です。
  • 防御終了: 特許権侵害の投稿者を訴えると、特許付与は終了し、平和的な共存を促進します。

BSD ライセンス (2 項および 3 項)

BSD (バークレイソフトウェアディストリビューション) ライセンスは、MIT と同様に許容されるライセンスです。

BSD 2 条項 (簡略化された BSD):

  • 権限： ソースフォームおよびバイナリ形式での再配布と使用(変更ありまたは変更なし)。
  • 条件： 著作権表示、条件の一覧、免責事項を保持する。バイナリディストリビューションのドキュメントで属性を保持します。
  • 制限： 保証なし、一切の責任を負いません。

BSD 3条 (修正BSD):

  • 追加の条件: 著作権者の名前を使用して、派生製品を許可なく推奨することはできません。
  • 商標保護: 元の作成者による承認を暗示しないようにします。

一般的な BSD ライセンス プロジェクト: FreeBSD、OpenBSD、macOS および iOS の一部。

組織への影響:

  • MIT に似ている: 最小限の制限、商業に優しい。
  • 名前の使用制限: 3-Clause BSD ライセンスでは、無許可でプロジェクト名をマーケティングに使用することが禁止されています。
  • よく確立された: 学術および商用ソフトウェアの長い歴史。

一般的なコピーレフト ライセンス

GNU General Public License (GPL) v2 および v3

GNU一般公衆ライセンスは、最もよく知られているコピーレフトライセンスです。

GPL v2 の主な用語:

  • 権限： ソフトウェアを使用、変更、配布します。
  • 条件： バイナリを使用してソース コードを配布する。派生作品はGPL v2を使用する必要があります。著作権表示を保持する。
  • コピーレフト スコープ: GPL のコードとリンクする派生作品と組み合わされた作品に適用されます。
  • 制限： 保証なし、一切の責任を負いません。

GPL v3 の機能強化:

  • 特許保護: Apache 2.0 と同様の明示的な特許付与。
  • ティボ化防止: ユーザーが修正されたソフトウェアを実行することをハードウェア制限により妨げるのを防ぎます。
  • 国際互換性: 国際的な管轄区域の法的明確さが向上しました。
  • Apache 2.0 の互換性: GPL v3 コードと Apache 2.0 コードを組み合わせることができます。

プロジェクトが GPL を選択する理由:

  • 自由を確保する: GPL は、変更がオープンソースのままであることを保証し、独自のフォークを防ぎます。
  • コミュニティの構築: コミュニティへの共有の改善を奨励します。
  • 哲学的なアラインメント: ソフトウェアは自由であり続けるべきであるという自由ソフトウェアの哲学に沿っています。

一般的な GPL ライセンス プロジェクト: Linux カーネル (GPL v2)、Git (GPL v2)、WordPress (GPL v2)、GCC (GPL v3)、Bash (GPL v3)。

組織への影響:

  • 派生的な作業要件: GPL のコードを変更したり、派生物を作成したりする場合は、配布時に GPL の下でオープンソースにする必要があります。
  • リンクに関する懸念事項: 独自のコードを GPL のライブラリにリンクすると、コピーレフトの要件がトリガーされる可能性があります (解釈は異なります)。
  • 商用配布: GPL のソフトウェアを販売できますが、顧客にソース コードを提供する必要があります。
  • SaaS に関する考慮事項: GPL v2 と v3 では、AGPL を使用しない限り、サービスとしてのソフトウェアのソース コードの開示は必要ありません。

GNU Affero General Public License (AGPL)

AGPL は、ネットワーク使用プロビジョニングを使用して GPL v3 を拡張します。

追加の AGPL 要件:

  • ネットワーク コピーレフト: AGPL のソフトウェアを変更し、ユーザーがネットワーク (SaaS) 経由でそれを操作する場合は、それらのユーザーにソース コードを提供する必要があります。
  • ASP の抜け穴を閉じる: 企業がソフトウェアを変更したり、変更を共有することなくサービスとして提供したりできないようにします。

プロジェクトが AGPL を選択する理由:

  • SaaS 保護: クラウド サービスがオープンソース ソフトウェアを利用するには、利用した部分をコミュニティに貢献することが求められます。
  • より強力なコピーレフト: 商用利用に対する最大の保護。

一般的な AGPL ライセンス プロジェクト: MongoDB (AGPL から変更)、RocketChat、Grafana。

組織への影響:

  • SaaS の場合は避けてください。 ほとんどの組織では、オープン ソーシングの変更が必要なため、サービス オファリング用の AGPL ライセンスソフトウェアを使用することを避けます。
  • 内部使用: ネットワーク経由でユーザーに公開されていない場合は、要件をトリガーせずに内部的に使用できます。
  • リスク評価: ソフトウェアが "ネットワーク経由で対話する" と見なされるかどうかを慎重に評価します。

一般的な弱いコピーレフト ライセンス

GNU Lesser General Public License (LGPL)

LGPL を使用すると、完全な GPL 要件をトリガーせずにライブラリにリンクできます。

主な用語:

  • ライブラリの使用: 独自のアプリケーションをオープンソース化することなく、独自のソフトウェアからLGPLのライブラリにリンクできます。
  • ライブラリの変更: LGPL のライブラリ自体に対する変更は、オープン ソースである必要があります。
  • 動的リンク: LGPL は、独自のコードを使用した動的リンクを明示的に許可します。
  • 派生作品: 完全なアプリケーションは、LGPL のライブラリを使用するからといって、派生的な動作ではありません。

プロジェクトが LGPL を選択する理由:

  • ライブラリの導入: ライブラリ自体を保護しながら、専用ソフトウェアでの使用を推奨します。
  • 妥協の位置: オープン性と商業的な実行可能性を両立させます。
  • 標準ライブラリの適合性: 標準コンポーネントとして使用するライブラリに適しています。

人気のある LGPL ライセンス プロジェクト: Qt (商用オプションでデュアル ライセンス)、GTK、GStreamer、多くの C ライブラリ。

組織への影響:

  • 独自のアプリケーションで使用できます。 商用アプリケーションで LGPL のライブラリを安全に使用できます。
  • ライブラリ ソースを指定する必要があります。 LGPL のライブラリを変更する場合は、変更用のソース コードを指定します。
  • 静的リンクの複雑さ: 静的リンクは、より厳密な要件を引き起こす可能性があります。動的リンクの方が安全です。

Mozilla パブリック ライセンス (MPL) 2.0

MPL 2.0 には、ファイル レベルのコピーレフトが用意されています。

主な用語:

  • ファイル レベルのコピーレフト: 要件は、もともと MPL の下にあるファイルにのみ適用されます。
  • 大規模な作業除外: 同じアプリケーションで MPL のファイルと独自のファイルを組み合わせることができます。
  • ソース コードの開示: MPL ファイルのソース コードを指定する必要があります。
  • 特許付与: 明示的な特許付与と防御的終了が含まれます。
  • GPL の互換性: MPL 2.0 は GPL と互換性があります。

プロジェクトが MPL 2.0 を選択する理由:

  • バランス： 許容されるライセンスよりも強力で、GPL よりも柔軟性が高い。
  • 商用使用: オープンソース コンポーネントを保護しながら商用使用を有効にします。
  • ファイル追跡: ファイル レベルのコピーレフトにより、コンプライアンスの追跡が容易になります。

一般的な MPL ライセンス プロジェクト: Firefox、Thunderbird、LibreOffice。

組織への影響:

  • 独自のコードと混在させることができます。 GPL よりも専用ソフトウェアとの統合が容易です。
  • ファイル レベルの追跡: MPL ファイルと専用ファイルの間の明確な境界を維持する必要があります。
  • 共有された変更: MPL ファイルに対する変更は共有する必要がありますが、別のファイルへの追加は共有されません。

ライセンスの互換性

ライセンスごとに互換性規則が異なります。

互換性のある組み合わせ

  • MIT + Apache 2.0: Compatible — 同じプロジェクトで組み合わせることができます。
  • MIT + GPL v3: Compatible — MIT ライセンスコードを GPL v3 プロジェクトに組み込むことができます。
  • Apache 2.0 + GPL v3: 互換性 — GPL v3 には Apache 2.0 コードを組み込むことができます。
  • LGPL + GPL: 互換性: LGPL を GPL にアップグレードできます。

互換性のない組み合わせ

  • GPL v2 + Apache 2.0: 互換性がありません。同じ作業で組み合わせることはできません。
  • GPL + 専用: 互換性がありません。GPL では、派生関数が GPL である必要があります。
  • 異なるコピーレフト ライセンス: 一般的に互換性がありません。通常、GPL、AGPL、LGPL コードを、両方を満たす方法で異なるコピーレフト ライセンスと組み合わせることはできません。

互換性に関する考慮事項

依存関係を選択する場合:

  • ライセンス インベントリ: すべての依存関係のライセンスを把握します。
  • 互換性チェック: さまざまなコンポーネントのライセンスに互換性があることを確認します。
  • 法的レビュー: 複雑なケースでは、互換性を評価するために法的専門知識が必要です。

デュアル ライセンス戦略

一部のプロジェクトには、複数のライセンス オプションが用意されています。

オープンソース + 商用

  • 戦略： GPL (コピーレフト) または商用ライセンスに基づくオファー。
  • 根拠： プロプライエタリソフトウェアに組み込みたい企業は商用ライセンスを購入しますが、オープンソースコミュニティではGPLバージョンが使用されます。
  • 例： Qt、MySQL、MongoDB (変更されたアプローチ)。

複数のオープンソース ライセンス

  • 戦略： ユーザーが複数の互換性のあるライセンスから選択できるようにします。
  • 根拠： さまざまなプロジェクトとの互換性を最大化します。
  • 例： 一部のライブラリには、Apache 2.0 または MIT のライセンス オプションが用意されています。

一般的なオープンソース ライセンスとその条件、および互換性を理解することは、使用するオープンソース コンポーネントと、ライセンス コンプライアンスを維持するためにソフトウェアを構成する方法に関する情報に基づいた意思決定を行うのに役立ちます。 次のユニットでは、リスクの評価と意思決定に役立つライセンスへの影響と評価について説明します。