オープンソース ライセンスの概要

オープンソース ライセンス は、オープンソース ソフトウェアの使用方法、変更方法、配布方法を定義する法的契約です。 すべてのオープンソース プロジェクトには、ユーザーに付与される権限と、ユーザーが満たす必要がある義務を指定するライセンスが含まれています。 ライセンスを理解することは、組織のコンテキストでオープンソース ソフトウェアを法的かつ安全に実装するために不可欠です。

オープン ソース ライセンスで定義される内容

オープンソース ライセンスは、ソース コードに付属し、次を指定する法的ドキュメントです。

付与されたアクセス許可

ライセンスは、ユーザーに特定の権限を明示的に付与します。

• 使用権限: 商用アプリケーションを含む任意の目的で本ソフトウェアを使用する許可。
• 変更権限: 特定のニーズに合わせてソース コードを変更したり、バグを修正したり、機能を追加したりするアクセス許可。
• 配布権限: 元の形式または変更された形式で、他のユーザーとソフトウェアを共有するためのアクセス許可。
• サブライセンス権限: 場合によっては、異なる条件で他のユーザーにソフトウェアのライセンスを付与するアクセス許可が付与される場合があります。

明示的なライセンスがない場合、著作権法はソフトウェアの使用、変更、または配布を禁止します。 ライセンスは、これらのアクティビティに対する法的アクセス許可を提供します。

課される義務

通常、ライセンスはユーザーに次の要件を課します。

• 属性の要件: 著作権に関する通知とライセンス テキストを配布コピーに保持する必要があります。
• ソース コードの開示: 一部のライセンスでは、バイナリを配布するときにソース コードを提供する必要があります。
• ライセンスの保持: 分散コピーを含むライセンス テキストを含める必要があります。
• 派生作品ライセンス: 一部のライセンスでは、派生作品が同じライセンス (コピーレフト) を使用する必要があります。
• 特許付与: 一部のライセンスには、明示的な特許付与または防御的終了条項が含まれます。

責任と保証に関する免責事項

ほぼすべてのオープンソースライセンスは、責任と保証を放棄します。

• 保証なし: ソフトウェアは、商品性、目的への適合性、または非侵害の保証なしに「現状のまま」提供されます。
• 一切の責任を負いません: 著者および著作権者は、ソフトウェアの使用に起因する損害について責任を負いません。
• ユーザー リスク: ユーザーは、本ソフトウェアの使用に関連するすべてのリスクを受け入れます。

これらの免責事項は、オープンソース開発者を法的責任から保護し、ソフトウェアは通常、補償なしで自由に提供されることを認識しています。

オープン ソース定義

オープン ソース イニシアチブ (OSI) は、ライセンスが真にオープンソースと見なされる条件を指定する、権限のあるオープン ソース定義を保持します。

コア要件

オープン ソース定義に従って、オープン ソース ライセンスは次の要件を満たす必要があります。

無料再配布:

• 制限なし: ライセンスは、集計配布の一部としてソフトウェアを販売または提供するユーザーを制限することはできません。
• 使用料なし: ライセンスは、そのような販売に使用料や手数料を必要とすることはできません。

ソース コードに含まれるもの:

• 可用性： 分散プログラムにはソース コードを含めるか、無償で入手するための明確な指示を提供する必要があります。
• 推奨される形式: ソース コードは、変更に適した形式である必要があります。
• 難読化なし: 意図的に難読化されたソース コードは要件を満たしていません。

派生作品:

• 許可される変更: ライセンスは、変更と派生作品を許可する必要があります。
• 同じ用語: ライセンスは、元のソフトウェアと同じ条件で変更を配布できるようにする必要があります。

作成者のソース コードの整合性:

• パッチ ファイル: ライセンスでは、変更を元のソースと共にパッチ ファイルとして配布する必要がある場合があります。
• 命名： ライセンスでは、元のバージョンと異なる名前またはバージョン番号を使用するために派生した作品が必要になる場合があります。

人やグループに対する差別なし:

• ユニバーサル アクセス: ライセンスは、個人または個人のグループを区別することはできません。
• 等しい権限: ソフトウェアを使用するには、すべてのユーザーが同じ権限を持っている必要があります。

努力の分野に対する差別なし:

• 任意の目的: ライセンスは、ビジネスや遺伝子研究などの特定の分野で使用されるソフトウェアを制限することはできません。
• 商用使用: ライセンスは、商用アプリケーションでの本ソフトウェアの使用を禁止することはできません。

ライセンスの配布:

• 自動アプリケーション: プログラムに添付された権利は、プログラムが再配布されるすべてのユーザーに適用される必要があります。
• 追加ライセンスなし: ユーザーは、これらの権限を受け取るために追加のライセンスを実行する必要はありません。

ライセンスは、製品に固有のものではありません。

• スタンドアロン権限: 権利は、特定のソフトウェア配布の一部であるプログラムに依存してはなりません。
• 独立した実行: 元のディストリビューションから抽出された場合、ソフトウェアは同じ権限を持つ必要があります。

ライセンスは、他のソフトウェアを制限してはなりません:

• 汚染なし: ライセンスは、ライセンスされたソフトウェアと共に配布される他のソフトウェアに制限を課すことはできません。
• 集計が許可されます。 ライセンスは、異なるライセンスの下でソフトウェアと共にソフトウェアを配布することを妨げることはできません。

ライセンスは、テクノロジに依存しない必要があります。

• インターフェイスの制限なし: ライセンスでは、特定のテクノロジやインターフェイス スタイルを必要とすることはできません。
• 実行メソッドに依存しない: ライセンスでは、アイコン、コマンド ライン、または Web インターフェイスをクリックしてソフトウェアを実行するかどうかは気にしないでください。

これらの要件が重要な理由

オープン ソース定義は、ライセンスが意味のある自由を提供することを保証します。

ユーザーの自由を保護します。 要件により、ライセンスは、オープンソースの原則を損なう隠れた制限を課すのを防ぎます。

商用使用を有効にします。 この定義は、努力の分野に対する差別を禁止することで、企業がオープンソースソフトウェアを使用して製品を構築できることを保証します。

互換性を高めます。 ライセンスが他のソフトウェアに与える影響を制限する要件により、互換性の問題が軽減されます。

断片化を防ぎます。 合理的な用語を要求することにより、定義は互換性のない準オープンライセンスの急増を防ぎます。

オープン ソース ライセンスのカテゴリ

多くの異なるオープン ソース ライセンスが存在しますが、一般に、次の 2 つの大きなカテゴリに分類されます。

制限付きライセンス

制限の緩やかなライセンスでは、 派生製品に最小限の要件が課されます。

• 特性： 独自のソフトウェアをオープンソースにする必要なく、独自のソフトウェアにコードを組み込むことを許可します。
• 必要条件： 通常、属性のみを必要とします (著作権表示とライセンス テキストの保持)。
• 商用使用: 商用ソフトウェア開発と完全に互換性があります。
• 例： MIT ライセンス、Apache License 2.0、BSD ライセンス。

制限の緩やかなライセンスにより、ユーザーは自由に使用でき、オープンソース コードを組み込んだクローズド ソースの商用製品を作成できます。

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

コピーレフト ライセンスでは、 同じライセンスを使用するために派生的な作業が必要です。

• 特性： 変更されたバージョンと派生物がオープンソースのままであることを確認します。
• 必要条件： ソース コードを配布し、派生物に同じライセンスを使用する必要があります。
• 商用使用: 商用ソフトウェアで使用できますが、派生物はオープンソースである必要があります。
• 例： GNU General Public License (GPL)、GNU Lesser General Public License (LGPL)、Mozilla Public License (MPL)。

コピーレフトライセンスは、ユーザーの自由よりもソフトウェアの自由を優先し、オープンソースソフトウェアが進化してもオープンソースのままであることを保証します。

弱いコピーレフト

一部のライセンスは中間地点を占めています。

• ライブラリの使用許可: アプリケーションをオープン ソーシングすることなく、独自のアプリケーション内のライブラリへのリンクを許可します。
• 変更の制限: ライブラリ自体に対する変更は、オープン ソースである必要があります。
• 例： GNU LGPL、Mozilla パブリック ライセンス。

弱いコピーレフトライセンスは、オープンソース開発を促進し、商用利用を可能にするバランスを取っています。

プロジェクト別のライセンス選択

オープンソース プロジェクトでは、目標に基づいてライセンスを選択します。

導入の最大化: 一般的に、広範な導入を優先するプロジェクトでは、ユーザーに重大な義務を課さない許容ライセンスが選択されます。

自由を確保する: ソフトウェアの自由を優先するプロジェクトは、派生物がオープンソースのままであることを保証するコピーレフトライセンスを選択します。

独自のフォークの防止: コピーレフト ライセンスを使用すると、企業はオープンソース ソフトウェアの独自バージョンを作成できなくなります。

特許保護: 特許に関するプロジェクトでは、より明確な特許権を提供する明示的な特許付与 (Apache 2.0 など) を持つライセンスを選択します。

互換性： プロジェクトでは、依存している他のソフトウェアと互換性のあるライセンス、または統合する必要があるライセンスを選択できます。

複数のライセンス

一部のプロジェクトでは、複数のライセンス戦略が使用されます。

デュアル ライセンス: オープンソースライセンスと商用ライセンスの両方でソフトウェアを提供し、適用する条件をユーザーが選択できるようにします。

ライセンススタック: プロジェクトのコンポーネントによってライセンスが異なる場合があります。

ライセンスの進化: プロジェクトは時間の経過と同時にライセンスを変更することがありますが、これにはすべての共同作成者からの同意が必要です。

透明度のパラドックス

ソース コードの透明性により、セキュリティ上の利点とリスクの両方が生まれます。

透明性のセキュリティ上の利点

パブリック ソース コードを使用すると、セキュリティが強化されます。

• 多くの目: 何千人もの開発者が脆弱性のコードを確認でき、検出の可能性が高まっています。
• 迅速な開示: 脆弱性が見つかった場合は、公開および修正プログラムを公開し、すべてのユーザーに通知することができます。
• コミュニティパッチ: セキュリティに配慮した開発者は、脆弱性を修正するためのパッチを提供します。
• 監査機能: 組織は、オープンソースの依存関係を監査してセキュリティの問題を監査できます。これは、クローズド ソース ソフトウェアでは不可能です。

透明性のセキュリティ リスク

パブリック ソース コードは、攻撃者を支援します。

• 脆弱性検出: 悪意のあるアクターは、ソース コードを分析して悪用可能な脆弱性を見つけることができます。
• エクスプロイト開発: 実装の詳細を理解することは、攻撃者が悪用を開発するのに役立ちます。
• ターゲット ID: 攻撃者は、どのアプリケーションが脆弱なバージョンのオープンソース コンポーネントを使用するかを特定できます。
• ゼロデイ悪用: 攻撃者は、公開される前に脆弱性を検出して悪用する可能性があります。

残高

研究は、透明性がネットセキュリティ上の利点を提供すると示唆しています:

ライナスの法則: 「十分な目玉を与えると、すべてのバグは浅いです。オープン レビューでは、一般に、クローズド ソース開発よりも迅速に脆弱性が検出され、修正されます。

あいまいさはセキュリティではありません。 ソース コードシークレットを保持しても脆弱性は防止されず、攻撃者が最終的に見つかるまでそれらを隠すだけです。

責任ある開示: オープンソース コミュニティは、セキュリティと透明性のバランスを取る責任ある開示プラクティスを開発しました。

実用的な現実: 最も深刻なセキュリティ侵害には、オープンソースの脆弱性ではなく、クローズド ソースソフトウェアや構成ミスが含まれており、透明性が本質的にセキュリティを低下させるわけではないことを示唆しています。

オープン ソース ライセンスとそのカテゴリについて理解することは、特定のライセンスを評価するための基礎となります。 次のユニットでは、一般的なオープンソース ライセンスについて詳しく説明し、一般的なライセンスが課す用語とその違いを理解するのに役立ちます。