GitHubプロジェクトで複数のライセンスを宣言する

何年もの間、私はオンラインで共有されたものにライセンスを付けて、他の人がそれらを再利用できるかどうか、そしてそれらを再利用できるかどうかを簡単に判断できるようにしました。GitHubがユーザーにリポジトリにLICENSEファイルを含めるように優しく「プッシュ」し始める前は、コード（特にGitHubで公開されているコード）でこれを行う最善の方法を知りませんでした！–しかし、それ以来、LICENSEファイルをうまく利用しようと試みました。

私は現在、いくつかのライセンスについて言及する必要がある（サードパーティのコードとライブラリ、および非コードファイルのために）他の人々と小さなプロジェクトに取り組んでいる状況にあります。私のパートナーはこの問題をかなり「ずさんな」方法で進めていますが、「コードをそのままオンラインに置くだけで、誰も気にしないだろう」と提案されました。問題は、GitHubでいくつかの（異なる）ライセンスについて言及する方法がわからないことです。

GitHubでいくつかの異なるソリューションを見てきました。そのため、このわずかに異なる質問に対する答えが信頼できるものかどうかを判断するのは困難です。私が知りたいのは、次のうちどれが最も一般的であるか、または他の追加の方法がある場合です。

単一のLICENSEファイルを作成し、そこにすべての異なるライセンスの説明を入れます。（質問：それらは特定の順序で配置する必要がありますか？より良い概要のために、含まれるすべてのライセンスの名前を記載してファイルから始めますか？）
作成したライセンスごとに1つのライセンスファイルを使用し、それらに名前を付けLICENSE.md、LICENSE.LibNameA.md、LICENSE.AssetsB.mdなどのリンクの答えで提案されているように。（質問：命名はプロジェクト名に基づきますか？ライセンス名ではありませんか？自己投稿素材に複数のライセンスを使用した場合、それらをすべて「メイン」で言及しLICENSE.mdますか？そうでない場合、代わりに何をしますか？）
2つのLICENSEファイルを作成します。1つは「メイン」コンテンツのライセンスをリストします。つまり、自分で作成したすべてのコード/アセット。1つはすべてのサードパーティの資料用です。（上記の質問：使用する特定の命名スキームと、サードパーティの資料をリストする順序はありますか？）

最後に、License APIに関するさまざまなGitHubの説明とプロジェクトを正しく理解していれば、レポのライセンスを決定するときに「メイン」のLICENSEファイルのみが考慮されます（どのライセンスが選択されるかはわかりませんが）いくつか言及された場合）。

licensing github

— ケイ
ソース

そのため、READMEと1つ以上のライセンスファイルが必要です。これはロケット科学ではありません。

— ロバートハーヴェイ

リンクされたページに関して：ライセンスファイルの配布とは何の関係もありません。レポジトリのライセンスを判断/報告するGitHubのライセンスAPIと関係しています。GitHubでのライセンス/ LICENSEファイルの使用について、特にオープンソースやgit全般ではなく、尋ねていたので、オープンソースプロジェクトがそこでライセンスされる「描写」方法も関連しています。「これはロケット科学ではありません」は、特に役に立ちません。私のGitHubに焦点を当てた質問ではありません。

— ケイ

READMEにライセンスに関するセクションがあり、複数のライセンスがあることを示し、各ライセンスにライセンスファイルの名前を通知することをお勧めします。

— エリックエイド

@i 私は、「人間にとって最も意味のある方法」に関する回答を求めていました（GitHub上）。

— ケイ

@immibis：「コンパイラはそれを読みません」-問題は厳密に言えば、これはGithubには当てはまらないということです。Githubは自動ツールを使用して、リポジトリのコンテンツに適用される「the」ライセンスを決定します。このようにして決定されたライセンスの名前は、プロジェクトの基本的な印象を訪問者に提供する非常に一般的な情報（寄稿者やリリースの数など）とともに、リポジトリのタイトルバーに表示されます。

— またはマッパー

回答:

プロジェクトの訪問者に、どのライセンスがプロジェクトのどの部分に適用できるかが明らかになる限り、任意のメカニズムを使用して、好きなライセンスを含めることができます。

私の好みは次のとおりです。

使用する各サードパーティライブラリを独自のディレクトリに配置します。このディレクトリには、ライセンスおよびreadmeファイルを含む、ライブラリの配布の一部であるすべてのファイルが含まれている必要があります。
独自のライセンスファイルでは、独自のコードのライセンスのみを参照してください
プロジェクトのreadmeファイルで、使用するサードパーティライブラリと、各ライブラリが配布されるライセンスを明記してください。ライセンスの詳細については、ライブラリのディレクトリにあるライセンスファイルを参照してください。

— バートファンインゲンシェナウ
ソース

このシナリオで独自のコンテンツの二重ライセンスの場合、独自のライセンスファイルをどのように処理しますか？つまり、プロジェクトのさまざまな部分（コードとメディアファイル）で異なるライセンスを使用した場合、または 2つ（またはそれ以上）の異なるソフトウェアライセンスでコードを配布したい場合はどうでしょうか。READMEに追加情報を入れることは非常に理にかなっており、私もやろうとしていますが、GitHubのLICENSEファイルを処理する方法に特に興味があります（私の目には、プロジェクトの簡単な概要）。

— ケイ

自分のコードの（一部）がデュアルライセンスである場合、プロジェクトごとに2つ（またはそれ以上）のライセンスファイルを追加し、ライセンスごとに1つずつ、readmeファイルでどのライセンスが適用されるかを明確にします。

— バートヴァンインゲンシェナウ

バート、あなたがそれをどうやってやるのかを共有してくれてありがとう-それは私が得たコメントのいくつかよりもはるかに役立ちます。:)その間、実際にGitHubに連絡しましたが、何か問題が発生した場合に備えて、この質問は今のところ公開しています。

— ケイ

Githubから回答を受け取ったら、この質問に対する自己回答としてその情報を投稿してください。

— バートヴァンインゲンシェナウ

他の人にも知っておくと面白いかもしれないので、彼らと一緒なら大丈夫です！

— ケイ

SPDXクリエーターのプレゼンテーション（スライド12）では、非常に明確です。

の内容LICENSE：

Apache-2.0 OR GPL-2.0-or-later

その後、2つの追加のLICENSEファイルを追加できます：LICENSE.Apache-2.0とLICENSE.GPL-2.0-or-later。

すべての場合、SPDXライセンス識別子README.mdが含まれている必要があります。

SPDX-License-Identifier: Apache-2.0 OR GPL-2.0-or-later

次のようにできます：

## License

This work is dual-licensed under Apache 2.0 and GPL 2.0 (or any later version).
You can choose between one of them if you use this work.

`SPDX-License-Identifier: Apache-2.0 OR GPL-2.0-or-later`

なお、Apache-2.0 OR GPL-2.0-or-laterとApache-2.0 AND GPL-2.0-or-later大きな違いになります。前者は、ユーザーが両方を選択できることを意味し（これは通常のケースです！）、2番目はユーザーが両方のライセンスに従う必要があることを示します。ウィキペディアのマルチライセンスもご覧ください。

ここでは、新しい（2017-12-28現在）SPDX License List 3.0 を使用していることに注意してください。2017年のバージョンにはGPL-2.0GPL 2.0の識別子がありましたが、それが「GPL 2.0のみ」または「GPL 2.0またはそれ以降のバージョン」を意味するかどうかは明確ではありませんでした。

— コッポル
ソース

私は最終的に私の質問に関してGitHubサポートに直接連絡しましたが、彼らの答えが提案ではなく提案であることを明確にした場合、彼らは引用しても構わないと言いました。

私たちのチームには現時点で特別な推奨事項はありませんが、他に何か共有できるものがあるかどうかを確認し、更新してください！

元の返信には次のものがありました。

1つの提案は、コードの大部分に対して1つのLICENSEファイルを用意し、READMEファイルに残りのサードパーティのマテリアルのライセンスのテキストを追加することです。

別の方法は、各パスが理にかなったときに独自のLICENSEファイルを持つことです。したがって、たとえば、リポジトリに次のパスがある場合：libs / awesome-lib-v2 / libs / awesome-lib-v2 / LICENSEを使用できます。

後者の場合は、ルートのREADMEファイルまたはLICENSEファイルにそのことを記載してください。

また、リポジトリのルートで1つのLICENSEファイルを使用することを検討し、サードパーティのマテリアル、コードなどのサブセクションを追加することもできます。

— ケイ
ソース