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