Glibcの開発者たちは最近、メーリングリストを通じて、変更の受け入れと著作権の移転に関する規則にいくつかの具体的な変更を加えたことを発表しました。これにより、コードの所有権をオープンソース財団に強制的に移転するという規定が撤廃されました。
GCCプロジェクトで以前に採用された変更と同様に、GlibcのFree Software FoundationとのCLA契約の署名は、開発者の要求に応じて実行されるオプションの操作のカテゴリに移動されました。
今回の規則変更により、Gnulibを通じて他のGNUプロジェクトと共有されるコードを除き、FOSS Foundationに権利を譲渡することなくパッチを受け入れることが可能になった。
FSFの著作権譲渡を受けている貢献者は何も変更する必要はありません。Origin開発者証明書[2]を使用したい貢献者は、確認書に「署名者」メッセージを追加する必要があります。
Gnulibを通じて他のGNUパッケージと共有されるコードは、引き続きFSFの割り当てを必要とします。
開発者は、オープンソース財団への所有権移転に加えて、開発者証明書（DCO）メカニズムを通じて、コードをGlibcプロジェクトに移転する権利を確認することもできます。DCOによると、各変更に「署名者：開発者名とメールアドレス」という行を追加することで、作成者の追跡が行われます。
この署名をパッチに添付することで、開発者は転送されたコードの著作権者であることを確認し、プロジェクトの一部として、またはフリーライセンスの下でのコードの一部として、そのコードを配布することに同意します。GCCプロジェクトの行動とは異なり、Glibcの決定は上層部による統括委員会からの指示ではなく、コミュニティのすべての代表者との予備的な協議を経て行われました。
オープンソース財団との契約締結を義務付けないことで、開発に新たな参加者を迎え入れるプロセスが大幅に簡素化され、プロジェクトが財団の動向に左右されなくなります。個々の参加者がCLAに署名すると、不必要な書類作成に時間を費やすだけでしたが、大企業やその従業員にとっては、STR財団への権利譲渡には多くの遅延や法的承認が必要となり、必ずしもすべてが順調に完了するとは限りませんでした。
ライセンスを変更するには、フリーソフトウェアファウンデーションに権利を譲渡していない各開発者の個人的な同意を得る必要があるため、コード権利の集中管理を拒否すると、最初に受け入れられたライセンス条件も統合されます。
しかしながら、Glibcのコードは引き続き「LGPLv2.1以降」のライセンスの下で提供されており、追加の承認なしにLGPLの新しいバージョンへの移行が可能です。コードの大部分の権利はフリーソフトウェア財団に帰属するため、同財団は引き続き、Glibcコードの配布をフリーコピーレフトライセンスの下でのみ保証する役割を担っています。
たとえば、Free Software Foundationは、コードの作成者との個別の契約を通じて、商用/デュアルライセンスの導入の試みやクローズドプロプライエタリ製品の発売をブロックする場合があります。
中央集権的なコード権利管理を放棄することによる欠点の1つは、ライセンス関連の問題の交渉における混乱である。以前は、ライセンス条項違反に関するすべての申し立ては単一の組織とのやり取りを通じて解決されていたが、現在では、意図的でないものも含め、違反の結果は予測不可能となり、個々の参加者との合意が必要となる。
例として、個々のカーネル開発者が個人的な利益を目的とするものを含め、法的措置を講じるLinuxカーネルの状況。
規則の変更は8月2日に発効し、開発に利用可能なすべてのGlibcブランチに影響します。詳細については、以下のリンクをご覧ください。