オープンソースソフトウェアライセンスをルートに保持する必要があるのはなぜですか？

ほぼすべてのオープンソースソフトウェアライセンスは、ユーザーが保護しているプロジェクトのルートに完全なライセンスを含めることを要求します（または少なくとも弁護士が要求することを推奨します）。

私が話したある弁護士は、これはCD時代の遺産であり、宝石のケースに完全なライセンスを含めることが必要だったと示唆しています。

しかし、今日、私たちはクラウド時代に生きています。たとえば、完全なライセンスを自分のWebサイトでホストし、そのライセンスのタイトル+ URLをソースファイルのヘッダーに含めることができないのはなぜですか？

おまけ：確立されたライセンスをそのままルートに保持する必要があると一般的に合意している場合、FSFのOSIがURLで参照できるライセンスを承認していないのはなぜですか。

GPL FAQから（ただし、アドバイスはすべてのライセンスに適用されます）：

プログラムのすべてのコピーにGPLのコピーを含める必要があるのはなぜですか。

作品にライセンスのコピーを含めることは、プログラムのコピーを取得するすべての人が自分の権利が何であるかを知ることができるようにするために不可欠です。

ライセンス自体ではなく、ライセンスを参照するURLを含めたくなるかもしれません。しかし、URLが今から5年後または10年後も有効であることを確信できません。今から20年後、今日私たちが知っているURLは存在しなくなる可能性があります。

プログラムのコピーを持っている人が、ネットワークで発生するすべての変更にもかかわらず、ライセンスを引き続き表示できるようにする唯一の方法は、プログラムにライセンスのコピーを含めることです。

（強調鉱山）

ライセンスをホストしているサイトがダウンしたり、URLパスを変更したりすると、ソフトウェアのコピーを持っている人は、安全に行使できる権限を確認できなくなります。その正確なURLがいつまでもオンラインであることをなんとかして保証できるとします。ユーザーがソフトウェアの使用が合法であることをユーザーが確認できるかどうかは、その特定のURLに接続できるかどうかにかかっています。この要件は、特定の都市/国/惑星では面倒ではないかもしれませんが、他の場所では面倒な場合があります。特に回避策（完全なライセンステキストを含む）が取るに足らない場合は、この要件を課すべきではありません。

「それで、URLがダウンしたりアクセスできない場合は、 'GNU GPL v3'のような明確な記述子で十分です。GPLのフルテキストコピーで十分です。ユーザーは調べることができます。ライセンス自体。」いくつかの問題がすぐに思い浮かびます：

1. これは、あまり明確でないライセンス識別子に一般化されません（「BSDライセンス」というフレーズが思い浮かびます）。

2. これは、あまり一般的でない、またはカスタマイズされたライセンスにはうまく一般化しません（「リンク例外を伴うGPL」が思い浮かびます：どのリンク例外ですか？）。ユーザーが名前でそれを確実に見つけることを期待することが合理的である前に、ライセンスはどれくらい一般的である必要がありますか？

3. これには、ユーザーがソフトウェアを入手したときに接続があったとしても、ユーザーがインターネット接続を持っている必要があります。（そして、ソフトウェアを入手したときにインターネットにアクセスできなかった可能性があります。「CD時代」はまだ世界の多くの地域で終わっていません。追加のケースとして、広範囲のインターネットアクセスを持っているが、その大部分を検閲している国民を考えてみてください。 。）自由に再頒布可能なソフトウェアの結果として、受取人があなたから直接、または当初予期していた配布チャネルを通じて、ソフトウェアのコピーを受け取ることができなくなります。

ライセンスリンクに対する最後の議論の1つは、以下のMichaelTのコメントに示されています。これにより、ライセンスを動的に遡及的に変更できます。これは意図的に行うこともできますが、ソフトウェアのバージョン間でライセンスを変更したが、両方のバージョンに同じライセンスリンクを使用したために、古いライセンスが存在しなくなった場合にも、誤って行われる可能性があります。そのような切り替えは、現在のバージョンとは異なるライセンスの下で古いコピーを入手したことを証明する必要がある人々にとって困難を加えます。

では、なぜプロジェクトのルートにライセンスを保持する必要があるのですか？

私は弁護士ではありませんが、プロジェクトのルートにライセンスを保持する必要があるという説得力のある議論は見たことがありません。ライセンスが作品の各コピーに付随しなければならないことを指定しているGPLでさえ、どのように作品に付随しなければならないかについては触れていません。（これは、GPLが「ルートディレクトリ」の概念が意味を持たない非ソフトウェアコンテキストに適用される可能性があるためです。）

ルートディレクトリにライセンスを保持することは、ユーザーに表示される可能性を最大化し、ユーザーの不満と不明瞭なディレクトリでライセンスを非表示にしようとすることに対する苦情の可能性の両方を最小化するため、おそらく良いアイデアです。多くのライセンスがある場合は、それらすべてを独自のフォルダーに配置し、各コンポーネントのライセンスを見つけるためのファイルパスを含む明白なプロジェクトREADMEを含める方が理にかなっている可能性があります。

ライセンスをディレクトリルートに配置することは、全体として機能する場合とは異なる方法でライセンスされるモジュールのライセンスを明確にすることができるため、有用な方法です。プロジェクトFooProjがスタンドアロンモジュールBarModを使用するとします。FooProjはGPLライセンスである可能性がありますが、スタンドアロンモジュールはMITライセンスである可能性があります。FooProjを初めて開いたとき、ルートにGPLのコピーが表示され、全体としてGPLライセンスであることがわかります。BarModのフォルダーに移動すると、そこに新しいライセンスファイルが表示され、このフォルダーの内容がMITライセンスであることがわかりました。もちろん、これは役に立つ補助に過ぎません。モジュールのライセンスは常にREADME、NOTICE、または同様のファイルで明示する必要があります。

つまり、ファイルルートを使用することは、利便性と明確さの問題です。私はそれを必要とする法的に拘束力のあるオープンソースライセンステキストを見たことはありません。また、それが法的に必要とされる理由についても知りません。ライセンスは、受信者が簡単に見つけられるものでなければなりません。プロジェクトのルートにライセンスを含めることで、この基準を満たすのに十分ですが、必須ではありません。

しかし、今日、私たちはクラウド時代に生きています。たとえば、完全なライセンスを自分のWebサイトでホストし、そのライセンスのタイトル+ URLをソースファイルのヘッダーに含めることができないのはなぜですか？

それを可能にするライセンスが存在します。たとえば、Apache 2.0。Apache 2.0では、各ソースファイルに、Apache 2.0ライセンスの正規URLを指す小さなヘッダーが含まれている必要があります。ソースツリーに完全なライセンスを複製する必要はありません。

Apache 2.0ライセンス自体から：

APPENDIX: How to apply the Apache License to your work

To apply the Apache License to your work, attach the following boilerplate
notice, with the fields enclosed by brackets "[]" replaced with your own 
identifying information. (Don't include the brackets!) The text should be  
enclosed in the appropriate comment syntax for the file format. We also 
recommend that a file or class name and description of purpose be included 
on the same "printed page" as the copyright notice for easier identification 
within third-party archives.

    Copyright [yyyy] [name of copyright owner]

    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.
    You may obtain a copy of the License at

        http://www.apache.org/licenses/LICENSE-2.0

    Unless required by applicable law or agreed to in writing, software
    distributed under the License is distributed on an "AS IS" BASIS,
    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    See the License for the specific language governing permissions and
    limitations under the License.

プロジェクトのルートにある必要はありません。これは単に最も一般的な場所なので、ライセンスを見つけるために最初に探す場所です。さらに言えば、それが一般的ではなかったとしても、人々が最初に見る可能性は高いです。通知するためのライセンスが存在するため、情報を非表示にすることはあまり意味がありません。

URLの背後にそれを隠す場合、そのURLが常に利用可能であるという絶対的な保証はありません。それがプロジェクトのルートにあるファイルである場合、定義により、常に使用できます。

要するに、これはそれを置くのに最も効果的で最もユーザーフレンドリーな場所です。