web-dev-qa-db-ja.com

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

私は何年もの間、オンラインで共有されたものにライセンスを設定して、他の人がそれらを再利用できるかどうか、またどのように再利用できるかを簡単に判断できるようにするのが大好きでした。 GitHubがユーザーにLICENSEファイルをリポジトリに含めるように穏やかに「プッシュ」するようになる前は、コードを使用してこれを行うには最適な方法がわかりませんでした。特に、GitHubで公開されているコードはわかりませんでした。 –それ以来、私はLICENSEファイルを有効に利用しようとしました。

いくつかのライセンスの言及（サードパーティのコードとライブラリ、および非コードファイルのため） ）。私のパートナーはこの問題について「だらしなく」問題に取り組んでいますが、「コードをそのままオンラインに置くだけで、誰も気にしない」ことが示唆されましたが、私はむしろこれを適切に行います。問題は次のとおりです：GitHubでいくつかの（異なる）ライセンスについて言及する方法がわかりません。

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

  1. 1つのLICENSEファイルを作成し、そこにすべての異なるライセンスの説明を入力します。 （質問：特定の順序で並べるべきですか？全体を把握するために、ファイルに含まれるすべてのライセンスの名前を記載したファイルから始めますか？）
  2. 作成ライセンスごとに1つのLICENSEファイル使用し、それらに名前を付けますLICENSE.md、LICENSE.LibNameA.md、LICENSE.AssetsB.mdなど、リンクされた回答で提案されています。 （質問：ネーミングはプロジェクト名に基づいていますか？ライセンス名ではありませんか？自分で寄稿した資料に複数のライセンスを使用した場合、それらすべてを 'main 'LICENSE.md？そうでない場合、代わりに何をしますか？）
  3. 作成2つのLICENSEファイル：「メイン」コンテンツのライセンスをリストしたもの、つまり、自分が作成したすべてのコード/アセット。 1つはすべてのサードパーティの資料用です。 （上記の質問：使用する特定の命名規則、およびサードパーティの資料をリストする順序はありますか？）

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

licensinggithub
31
Kay

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

私の好みは：

  • 使用する各サードパーティライブラリを独自のディレクトリに配置します。このディレクトリには、ライセンスやreadmeファイルなど、ライブラリの配布の一部であるallファイルを含める必要があります。
  • 自分のライセンスファイルでは、自分のコードのライセンスのみを参照してください
  • プロジェクトのreadmeファイルで、使用するサードパーティライブラリと、各ライブラリが配布されるライセンスについて言及します。ライセンスの詳細については、ライブラリのディレクトリにあるライセンスファイルを参照してください。
14
Bart van Ingen Schenau

[〜＃〜] spdx [〜＃〜] 作成者（ スライド12 ）のプレゼンテーションでは、非常に明確です。

LICENSEの内容：

Apache-2.0 OR GPL-2.0-or-later

次に、2つのLICENSEファイルを追加できます：LICENSE.Apache-2.0およびLICENSE.GPL-2.0-or-later。

すべての場合において、README.mdにはa [〜＃〜] spdx [〜＃〜] ライセンス識別子を含める必要があります。

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.0がGPL 2.0の識別子でしたが、 それは明確ではありませんでした それが「GPL 2.0のみ」または「GPL 2.0以降のバージョン」を意味していたかどうか。

12
koppor

私は最終的に私の質問に関してGitHubサポートに直接連絡しました、そして彼らは私が彼らの答えが提案としてのみ意味されていることを明確にしたならば彼らを引用しても大丈夫だと言いましたnot推奨事項。

現在のところ、チームに提供する特定の推奨事項はありませんが、他に何か共有することがあるかどうかを尋ねて更新するようにしています。

彼らの最初の返答は以下を提供するものでした：

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

もう1つの方法は、各パスが意味のあるときに独自のLICENSEファイルを持つことです。たとえば、リポジトリのパスがlibs/awesome-lib-v2 /の場合、libs/awesome-lib-v2/LICENSEを使用できます。

後者の場合は、READMEファイルまたはルートのLICENSEファイル、あるいはその両方でそのことを言及する必要があります。

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

3
Kay