このポリシーは、Apache Software Foundationプロジェクトにライセンスに関するガイダンスを提供します。Apache Software Foundation製品にサードパーティのオープンソースコンポーネントを含める際に許容されるライセンスを特定します。
プロジェクトは、法務委員会にライセンスに関する質問を送信できます。JIRAスペース。
次の基準は、このページのカテゴリのガイドラインとして機能します。
a. （レビュー済み：2019-02-16）
概要として、このポリシーはライセンスを3つのカテゴリに分類します。
Apache Software Foundation製品に含めるために、次のライセンスはApache License 2.0と同様の条件であると見なしています。
これらのライセンスの多くには、プロジェクトが遵守する必要がある特定の帰属条件があり、多くの場合NOTICEファイルに追加することによって行われます。これらの作品を含める際には、必ずこれを実行してください。
Apache製品にパブリックドメインの作品（または同様に扱われるライセンスの対象となる作品）を含めることができます。カテゴリーAのリストと同様の方法で、帰属を提供する必要があります。
次のいずれかが適用される場合、作品はパブリックドメインにあると見なされます。
パブリックドメインと同様に扱うライセンス
**注意：**作品がパブリックドメインに該当するかどうかは難しい場合があります。作品の著作権が期限切れかどうかを判断することは簡単ではなく、管轄区域によって異なる場合があります。作品がパブリックドメインに該当するかどうか疑問がある場合は、legal-discuss@またはJIRAの課題を通じて話題を提起してください。
このセクションで説明されているライセンスやプロジェクトは、**もし**指定された条件を満たしている場合、Apache Software Foundation製品に含めることができます。
カテゴリーBのすべてのケースにおいて、ユーザーは製品への包含に驚かされるべきではありません。適切で目立つラベルを配布物に添付することで、ユーザーはApache Licenseとは大きく異なる制限に気付かない可能性が低くなります。適切で目立つラベルとは、ユーザーが配布物について学習中に読むラベルです（たとえば、README内）。これは、サードパーティ製品とそのライセンスを特定し、そのホームページへのURLを提供する必要があります。また、該当する特定のライセンスにおける帰属/通知の要件にも準拠してください。
カテゴリーBライセンス付きの作品は、Apache Software Foundationの利便性バイナリにバイナリのみの形式で含めることができます。ソースリリースには、カテゴリーBライセンス付きの作品を含めないでください。
このセクションの各ライセンスは、ある程度の相互性が必要です。これには、Apache製品のユーザーが、適用される要件に気付かずに、Apache製品の異なるライセンスのセクションの派生作品を作成する可能性を最小限に抑えるための追加の措置が必要になる場合があります。
適切にラベル付けされている場合（上記参照）、次のライセンスに基づくソフトウェアをバイナリ形式でApache製品に含めることができます。
オブジェクト/バイナリ形式のみを含めることで、他の人が作品を派生させる可能性のあるサードパーティ作品の露出面が減少します。これは、このポリシーの2番目の指針に対処しています。
ASF製品がランタイム時に直接使用する少量のソースコードの場合、そのソースが変更されておらず、変更される可能性が低い場合（たとえば、標準によって指定されているため）、適切にラベル付けされたソースコードを含めることができます。その例として、web-facesconfig_1_0.dtdがあり、その包含はJSR 127：JavaServer Faces仕様によって義務付けられています。
クリエイティブコモンズ表示（CC-BY）ライセンス（2.5、3.0、および4.0）に基づく作品には、「効果的な技術的保護措置」に関連する条件が含まれており、ユーザーを驚かせる可能性があります。したがって、適切にラベル付けし、バイナリ形式でのみ含める必要があります。
Apache製品において、クリエイティブ・コモンズ 表示-継承 2.5、クリエイティブ・コモンズ 表示-継承 3.0、およびクリエイティブ・コモンズ 表示-継承 4.0ライセンスに基づく変更されていないメディアを含めることができます。ただし、ライセンスの帰属条項に従い、LICENSE/NOTICE/README の変更が必要となる場合があります。その他の種類のCC-SAライセンスの著作物については、Legal PMCにお問い合わせください。
なお、メディアとは、ドキュメントで使用されるバイナリ形式の画像/動画/音声要素を意味します。ソースコードへの組み込みを意味するものではありません。
いいえ、元の作者に連絡して、Apache License 2.0の下でApacheプロジェクトでそのコードを使用する許可を得ない限り、できません。
Doug Leaのコンカレントライブラリはパブリックドメインですが、パブリックドメインではないSunのファイルが含まれています。上記の「弱いコピーレフト」リストのリソースと同様に、このライブラリをASF製品に含めることができます。「Apache製品内にバイナリ形式で含まれる場合、適切にラベル付けする必要があります」。ソースを使用する場合は、SunがDougにライセンス供与したファイルを削除し、カテゴリAとして扱い（またはHarmonyからファイルを入手してください）。
「カテゴリB」ライセンスのjarファイルにOSGiメタデータを追加できます。ただし、jarファイルの目立つラベルにこの処理が行われたことを記載する必要があります。
ASF配布物にCoberturaレポートを含めることができます。
変更されていないコピーの再配布に関する広範な権利を与えるライセンスがあります。このようなライセンスはオープンソースではありませんが、上記の2番目と3番目の指針を満たしています。
Apacheプロジェクトは、このようなライセンスに基づく資料をバージョン管理システムまたはリリースされたソースパッケージに含めることはできません。ただし、ビルドプロセスがこのような非ソフトウェア素材（フォントや標準化されたデータなど）を自動的にダウンロードし、結果として得られるバイナリに含めることは許容されます。このような使用方法では、これらの依存関係がプロジェクトのオープンソースコードの一部ではないことが明確になります。
上記のように、次のライセンスに基づく素材を使用できます。
多くの言語では、配布用アーティファクトの作成を支援する関連ツールのエコシステムが開発されています。このようなツールは、必ずしも互換性のあるライセンスの下で提供されるとは限りませんが、特定の目的で使用する場合、Apache配布物への組み込みを承認しています。
ツールがプロジェクトのソースコードのライセンスに影響を与えないようにする必要があります。また、ソースコードのビルドにツールを使用することが、その典型的な使用方法であることを期待しています。
現在までに、次のツールの使用を承認しています。
コンパイルされたCコードをリンクして動的にロードされるXSモジュールを作成するPerlバインディングの開発には、Perlライセンス（http://dev.perl.org/licenses/ - GPL-any/Artistic1、例外あり）の下でライセンスされたヘッダーファイルを含める必要があります。
これらのヘッダーファイル（XSUB.h、perl.h、EXTERN.h）を含めることができます（参照：LEGAL-79）。
生成されたコメントを削除する限り、これらのファイルを使用できます。
主にRubyで記述されており、それが明らかなプロジェクトは、MatzのRubyインタプリタ（MRI）、またはRubyライセンスの下でライセンスされたGemに依存関係を持つことができます。
もちろん、他のライセンス（MITなど）の下で記述されたGemも、ライセンスに応じて問題ない場合があります。
また、Rubyライセンスは、上記の「カテゴリB」弱いコピーレフトリストにバイナリ使用について記載されています（例：JRuby）。
Java 9以降、Javadocには、MIT、MITまたはGPL-3.0、またはGPL-2.0 WITH ClasspathException-2.0に基づくJavaScriptを含めることができます。Apacheのバイナリリリース（Maven javadoc jarファイルを含む）およびApacheのWebサイトは、Javadocにこれらを含めることができます。ソースリリースには含めることはできません。
Apache製品に次のライセンスを含めることはできません。
「その他の懸念事項」の詳細
Facebook BSD+Patents license
Facebook BSD+Patentsライセンスには、ソフトウェアの下流の利用者にリスクを転嫁するPATENTSファイルの仕様が含まれており、ライセンシーではなくライセンサーに有利に偏っているため、Apacheの法的ポリシーであるユニバーサルドナーであることに違反しています。Facebook BSD+Patentsライセンスの条項は、ALv2にある条項のサブセットではなく、ALv2としてサブライセンスすることはできません。
NPL
Netscape Public Licenseは、Mozillaの元のライセンスであり、Netscape固有の修正が含まれています。これらの修正により、「Netscape」（現在はAOLの一部）は、他のすべてのライセンシーが遵守しなければならない相互主義の要件を回避できます。これは、ライセンスがオープンソース定義#5（「個人またはグループに対する差別がないこと」）を満たすことを妨げます。
無意味なライセンス
これらのライセンスは、作成者にとって面白いかもしれませんが、法的にも問題があります。多くの場合、主観的な使用範囲の制限（例：「悪事を働くな」）が含まれており、その主観的な制限の仲裁者を定義していません。場合によっては、OSIオープンソース定義に準拠するのに十分な権利を与えていない可能性もあります。下流の利用者を驚かせたくないので、このようなライセンスの使用を禁止しています。
JSONライセンス
2016年11月3日現在、JSONライセンスは「カテゴリX」ライセンスリストに移されました。これ以前は、JSON Javaライブラリの使用が許可されていました。代替案のリストについては、Debianのページを参照してください。代替案のリスト
Apacheプロジェクトは、カテゴリXライセンスのコンポーネントを、ソース形式またはバイナリ形式で、ASFソースコードまたは利便性のためのバイナリで配布することはできません。プラットフォームに関する以前の質問と同様に、コンポーネントのライセンスタイムがApache製品のライセンスに影響を与えない場合は、そのコンポーネントに依存できます。たとえば、ビルド中にGPLライセンスのツールを使用することは問題ありませんが、GPLライセンスのソースコードを含めることは問題ありません。
Apacheプロジェクトは、コンポーネントがオプション機能のみに必要な場合、禁止されているライセンスに基づくコンポーネントに依存できます。その場合、プロジェクトは、ユーザーに、含まれていない作業を入手してインストールする方法に関する指示を提供する必要があります。オプションとは、コンポーネントが製品の標準的な使用、または製品が望ましい品質レベルを実現するために必要ないことを意味します。この状況で自問自答すべき質問は次のとおりです。
そのプラットフォームの条件がApache製品のライセンスに影響しない限り、問題になりません。たとえば、WindowsまたはJavaで実行される製品を作成したり、Google ServicesやYahoo SearchなどのWebサービスを使用したり、JBossやJIRAなどの製品のプラグインを作成することは問題ありませんが、Linuxカーネルモジュールを作成することは問題ありません。Apache製品自体がApache License version 2.0以外のライセンスでライセンスされる必要があるためです。
これは、プラットフォームコード自体を再配布できるという意味ではありません。それはもちろん、そのコードのライセンスに依存します。プラットフォームのライセンスがApacheコードに影響するかどうかについて疑問がある場合は、legal-discuss@アーカイブで既に発生しているかどうかを確認し、発生していない場合はlegal-discuss@にメールを送信して確認してください。
いいえ。
IPクリアランスは、Apache外部からコードベースをインポートして、ここで将来の開発を行うために使用されます。
当該作業のライセンスを含める場合、使用しているライセンスを明記し、選択したライセンスのみを含めます。カテゴリA、カテゴリB、カテゴリXの順に優先順位を付けます。例えば、ソースヘッダーに様々なライセンスオプションが記載されている場合でも、作業自体を変更する必要はありません。
リリースにサードパーティの作業が含まれる場合、それらの作業をカバーするライセンスでは、特定の方法で消費者に情報を伝えるよう求める場合があります。これらのサードパーティ通知は、ライセンスによって異なります。Apacheリリースには、通常LICENSEドキュメントに含まれる各ライセンスのコピーを含める必要があります。多くのライセンスでは、これが十分な通知です。ただし、追加の通知が必要なライセンスもあります。多くの場合、この通知は依存アーティファクトに含めることができます。
必須のサードパーティ通知とは、上記のケースに該当しないサードパーティ通知です。
リリースに別のApache製品が含まれる場合の必須通知については、他のASF製品のバンドルを参照してください。