今日、Fossil SCMのメーリングリストを読みました。
BSDの問題は、貢献者がBSDであることを示す署名済みのフォームを各貢献者から実際に取得する必要があることです。GPLでコードを表示するためには、互換性のあるライセンスでコントリビューションをリリースすることが前提条件であるため、これはGPLでは自動的に行われます。これにより、GPLは多くの貢献者がいる高度なコラボレーション環境に最適です。BSDは読者にとって寛容です（負担が少ない）が、執筆者が書類を提出する必要があるため、執筆者にとっては少し厳しいものになります。
誰かがその理由を説明してもらえますか？また、プロジェクトの貢献者からのそのような署名された声明がないことによって起こり得る結果は何ですか？
回答:
GPLは、コードに提供されたコードのプロジェクトへのライセンス供与について明示的に表明していません。いかなる貢献もGPLの対象となる可能性があるため、GPLの対象となる可能性があるため、GPLに基づいてライセンスを供与する必要があります。 。
私が知る限り、寄贈されたコードのライセンスについて明示的に言及している唯一のライセンスはApacheライセンスです（「寄稿」および「寄稿の提出」を参照）。
とはいえ、オープンソースプロジェクトへのすべての貢献者に、プロジェクトへの貢献の著作権を明示的に割り当てることは、一般的には良い習慣です。譲渡フォームには、寄稿者が寄稿の著作権者であること、および/または著作権を譲渡する権限があることを確認するテキストも含まれます。
2番目の部分を含めることにより、法的に貢献を許可されていないコードを誰かが提供したことが発見された場合、プロジェクトはある程度保護されます（たとえば、雇用主から所有権のあるコードをコピーしました）。
著作権が割り当てられないもう1つの一般的なリスクは、将来ライセンスを変更したい場合に、自分の投稿に著作権を保持しているすべての投稿者の許可なくしてはならないことです。たとえば、ライセンスをGPLv2からLGPLv2に変更したい場合、許可なしにはできません。
...enforcement of copyright is generally not possible for distributors: only the copyright holder or someone having assignment of the copyright can enforce the license.」（この回答の他のすべての点も完全に有効ではないというわけではありません。これは、著作権の割り当ての主な利点の1つとしてここには含まれていないことに気づきました。）
BSDでは、概して、BSDライセンスではない派生著作物を許可しています。ここでの危険は、新しいコントリビューター（または実際にはすべてのコントリビューター）がコードの寄稿を提出し、その後彼の寄稿がBSDライセンスではないと主張することです。これが法廷で保留されるかどうかは、おそらく転送の正確な状況に大きく依存します-誰かがメーリングリストにパッチを投稿し、単に「私が書いたこのきちんとした新機能を見てください！」と言うあいまいなケースを想像してください。BSDライセンスの下でプロジェクトに明示的に付与することなく。（署名済みの契約を必要とするプロジェクトは、「ありがとうございます。ただし、これをコードベースに受け入れる前に、寄付がBSDライセンスであることを法的に認めてください。」と応答します。）
GPLライセンスのプロジェクトは、このようなあいまいさに対して脆弱ではありません。GPLの関連する法的歯はセクション8にあります。
このライセンスの下で明示的に提供されている場合を除き、対象の作品を伝播または変更することはできません。それ以外の方法でそれを伝播または変更する試みは無効であり、このライセンスに基づくあなたの権利を自動的に終了します...
あいまいな貢献の私の例では、GPLにあいまいさはありません。修正された著作物は必ずGPLライセンスであり、GPLの権利を付与することなく貢献者は彼の修正をメーリングリストに投稿できませんでした（彼の修正されたバージョンの投稿は転送を構成するため）。そうでないと主張しようとする試みは、彼がGPLに違反していたことを積極的に主張することを彼に要求します。つまり、彼はプロジェクトに対する権利を完全に失い、彼の修正された作品は法的に無効です。
（私は弁護士ではないので、GPLの保護が、自分への法的損害を気にしない訴訟者からプロジェクトを保護するのに十分であるかどうかはわかりませんが、ほとんどの健全な人々を抑止するのに十分です法的措置を押すことから。）