FLOSSライセンスがdiff / deltaではなくファイルに適用されるのはなぜですか？
貢献が以前の作品に基づいているオープンソースソフトウェア開発の場合、各著作権所有者がファイルの著作権ではなく、貢献した差分/デルタの著作権を保持する方が賢明だと思います。寄稿者がファイルを作成しない限り、寄稿は変更です。
AFAIK、Linuxカーネルのように、CLAのないプロジェクトでは、さまざまなソースからの投稿の著作権はファイルごとに処理されます。
この概念を実装すると、ライセンスをGit/Mercurial/Bazar/Fossil/SVNに統合する必要があり、最初は、各ファイルにライセンス付きのコメント付きヘッダーを追加するよりも複雑になります。
ソフトウェアライセンスがdiff/deltaではなくファイルに適用される理由（法的、技術的、政治的、慣習的またはその他）は何ですか？特にバージョン管理システムが広く使用されている現在はどうですか？それともこれは斬新なアイデアですか？
注1：明らかに、この質問は、コントリビューターライセンス契約がある場合には適用されず、FLOS以外のソフトウェアにも適用されません。
注2：Stackoverflowで誤って質問しましたが、ここに移動する代わりに閉じられたため、ここで質問しています。
注3：差分は、単一のファイルへの変更、複数のファイルへの変更、新しいファイル、以前のファイルの任意の組み合わせのいずれか以上にすることができます。
注4：提案は主に2つの状況を対象としています。
- コピーレフトとコピーレフトの両方の貢献を同じソースツリーに維持し、ライセンスに基づいてフィルタリングすることによって達成される、コピーレフトの唯一の理由で、コピーレフトプロジェクトのコピーレフトフォークの作成を阻止します。
- 必要なすべての人の承認を得て、余分な人がいなくてもライセンスの切り替えを有効にします（例：Linusが気が変わって、LinuxのライセンスをGPLv2からGPLv2 +に切り替えたい場合はどうすればよいですか？誰を追跡して許可を求める必要がありますか。彼は寄付が破棄された人々に許可を求めますか？）
著作権保護が変更セットではなくファイルのレベルで適用されるのは、主に実際的な理由によるものです。
まず第一に、著作権法とそれに含まれるアイデアのほとんどは、電子コピーが存在するずっと前の時代に由来しています。当時、著作権で保護された作品に変更を加え、それらの変更を配布するだけの効果的なメカニズムはありませんでした。 だった可能だったのは、BさんがAさんから作品を受け取り、それにいくつかの変更を加えて、バージョン変更を配布したことです。そのため、著作権法は、こうした種類のプロセスを規制するために作成されました。
さらに、多くの著作権法は、変更されたバージョンがそれ自体で著作権の対象となる前に、変更にある程度の独創性を課しています。
その結果、次のような状況になりました。
- 単一の投稿は、著作権保護の対象となるのに十分な実質的/オリジナルではない場合があります（変数の名前を変更するだけでは対象とならない場合があります）
- 単一の寄稿が著作権保護に十分な実質的/オリジナルである場合、寄稿を適用した結果は、元の作品とは別に、著作権保護のための別個の作品と見なされます。
- 一人の人がいくつかの小さな貢献をし、それぞれがそれ自体で著作権保護の対象とならない場合でも、最終製品にその人からの十分な資料が含まれている可能性があります。その素材の著作権。
それを念頭に置いて、あなたの提案には次の実際的な問題があります。
すべての寄稿を適用した結果、著作権法の下で著作権で保護された作品と見なされるため、寄稿ごとに異なる著作権ライセンスを許可すると（これらの寄稿はそれぞれ十分に重要であると想定）、ファイル内の各トークンが異なる著作権ライセンスの対象となる可能性があります。あなたが何をすることが許されるかを言うことはほとんど不可能でしょう。
多くの個々の寄稿は、それ自体で著作権を取得するにはあまりにも重要ではない可能性が高いため、管轄によっては、それらの寄稿にライセンス条項を添付することは不可能です。
- まとめると、1人の人からのいくつかの小さな貢献により、その人は結果のファイルの著作権を主張します。個々の貢献が小さすぎて他の条件を指示できないため、ライセンス条件は元の著作権ライセンスの条件になります。
これは、変更が法的に派生作業と見なされているためです。これは、変更が既に行われた作業に基づいて依存しているためです。これにより、元の作成者は、自分の作品に基づいて人気のある新機能を追加し、その機能をクローズドソースにすることから保護されます。作成者がソフトウェアのクローズドソース拡張を許可したい場合は、Linuxカーネルがクローズドソースモジュールを許可する方法など、明示的にすることができますが、「汚染された」とマークする必要があります。
おそらくエンドユーザーは差分ではなくファイルを使用しているであり、ライセンスはソフトウェアと一緒に配布されることになっています（ソース、バイナリ、その他の形式）。ソフトウェアを一連の注釈付き差分として配布していませんか？
法的な理由もあるかもしれませんが、それは別のウェブサイトへの質問です。
ライセンスと著作権を混同していると思います。著作権が割り当てられていない共有プロジェクトへの各寄稿者は、自分の寄稿に対する著作権、つまり、作成する各差分に対する著作権のみを所有します。寄稿者は、他の誰もそのファイルに寄稿していない場合にのみ、ファイル全体の著作権を所有します。その結果、ほとんどのファイルは複数の作成者間で著作権を共有しています。
では、なぜライセンスが必要なのですか？ソフトウェアが他の人によって使用されることを意図している場合、ライセンスが必要です。ライセンスには、他の人がソフトウェアを使用できる条件が記載されています。たとえば、通常、一部のソフトウェアを変更して変更を公開することは許可されていません。一部のソフトウェアのソースにアクセスできる場合でも、作成した拡張機能を公開することはできません。人々に貢献してもらいたいプロジェクトがある場合、プロジェクト全体がこれを許可するライセンスの下で利用可能である必要があります。また、他の人もこれらの貢献に基づいて構築できるように、すべての貢献もこのライセンスの下で提供される必要があります。
1つのプロジェクトまたは1つのファイルに、複数の異なるライセンスの下でコードを含めることは現実的ではありません。手始めに、多くのライセンスは、ファイルごとまたはプロジェクトごとに適用されることを前提としています。また、潜在的なユーザーまたは寄稿者がソフトウェアを使用できるかどうかを判断しようとしていると想像してください。以前のすべての投稿を調べて、ソフトウェアを使用、変更、および配布できるかどうかを確認することは現実的ではありません。プロジェクト全体のライセンスを1つ記載する方がはるかに簡単であり、寄付もそのライセンスの下で提供する必要があります。