Glibc開発者がリリース 最近彼らが作ったメーリングリストを通して 変更を受け入れ、著作権を譲渡するための規則に対するいくつかの特定の変更、 これにより、コードに対する所有権のオープンソース財団への強制的な譲渡が取り消されました。
GCCプロジェクトで以前に採用された変更と同様に、GlibcのFree Software FoundationとのCLA契約の署名は、開発者の要求に応じて実行されるオプションの操作のカテゴリに移動されました。
ルールに加えられた新しい変更により、 パッチの受け入れは、FOSSFoundationに権利を譲渡することなく許可されるようになります、Gnulibを介して他のGNUプロジェクトと共有されるコードを除いて。
FSFの著作権を割り当てられている寄稿者は、変更する必要はありません。 なんでも。 からの開発者証明書の使用を希望する寄稿者 Origin [2]は、確認に「署名者」メッセージを追加する必要があります。
Gnulibを介して他のGNUパッケージと共有されるコードは継続されます FSFへの割り当てを要求します。
財産権の譲渡に加えて オープンソース財団へ、 開発者は、コードをGlibcプロジェクトに転送する権利を確認する機会があります Developer Certificate of Origin（DCO）メカニズムを使用します。 DCOによると、作成者の追跡は、各変更に「署名者：開発者名と電子メール」の行を添付することによって行われます。
この署名をパッチに添付することにより、開発者はその作成者を確認します 転送されたコードについて、プロジェクトの一部として、または無料ライセンスの下でコードの一部としてその配布を受け入れます。 GCCプロジェクトのアクションとは異なり、Glibcでの決定は、上からの統治評議会によって発行されたのではなく、すべてのコミュニティの代表者との予備的な話し合いの後に行われました。
必須の署名のキャンセル オープンソース財団との合意の 開発への新しい参加者の組み込みを大幅に簡素化します プロジェクトをオープンソース財団のトレンドから独立させます。 個々の参加者によるCLAの署名は、不必要な手続きで時間の無駄を生み出すだけでしたが、大企業の企業や従業員にとって、STR財団への権利の譲渡は、多くの遅延と法的承認を伴い、必ずしも完了していませんでした。正常に。
ライセンスを変更するには、フリーソフトウェアファウンデーションに権利を譲渡していない各開発者の個人的な同意を得る必要があるため、コード権利の集中管理を拒否すると、最初に受け入れられたライセンス条件も統合されます。
しかし、 Glibcコードはまだ「LGPLv2.1以降」でライセンスされています、追加の承認なしにLGPLの新しいバージョンへの移行を可能にします。 ほとんどのコードの権利はフリーソフトウェアファウンデーションの手に委ねられているため、この組織は引き続き、無料のコピーレフトライセンスの下でのみGlibcコードの配布を保証する役割を果たします。
たとえば、Free Software Foundationは、コードの作成者との個別の契約を通じて、商用/デュアルライセンスの導入の試みやクローズドプロプライエタリ製品の発売をブロックする場合があります。
集中管理の放棄の欠点の中に コードの権利、ライセンス問題の交渉で混乱が生じています。 以前にライセンス条件の違反に関するすべての主張が組織との対話を通じて解決された場合、意図しないものを含む違反の結果は予測不可能になり、個々の参加者との合意が必要になります。
例として、個々のカーネル開発者が個人的な利益を目的とするものを含め、法的措置を講じるLinuxカーネルの状況。
ルールの変更は2月XNUMX日に発効します そして、それらは開発に利用できるすべてのGlibcブランチに影響します。最後に、それについてもっと知りたい場合は、詳細を参照してください。 次のリンクで。