web-dev-qa-db-ja.com

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

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

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

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

ボーナス：ルートで確立されたライセンスをそのまま維持する必要があると一般的に合意しているのに、FSFのOSIがあなたにライセンスを承認していないのはなぜですかURLで参照していますが、誰かがそのライセンスを作成するのを妨げているものは何ですか？

licensingopen-sourcemit-licenseapachebsd
10
samthebrand

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

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

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

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

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

（強調鉱山）

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

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

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

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

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

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

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

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

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

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

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

24
apsillers

しかし、今日、私たちはクラウド時代に生きています。たとえば、完全なライセンスを自分の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.
6
Chadversary

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

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

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

3
Bryan Oakley