Glibc 開發者發布 最近通過他們製作的郵件列表 接受更改和轉讓版權的規則的一些具體更改， 取消了將代碼的產權強制轉讓給開源基金會。
與之前在 GCC 項目中採用的更改類比，在 Glibc 與自由軟件基金會簽署的 CLA 協議已移至應開發人員要求執行的可選操作類別。
隨著規則的新變化， 現在將允許補丁接受，而無需將權利轉讓給 FOSS 基金會，但通過 Gnulib 與其他 GNU 項目共享的代碼除外。
擁有 FSF 版權分配的貢獻者無需更改 任何事物。 希望使用開發者證書的貢獻者 Origin [2] 必須在您的確認中添加“簽名者”消息。
通過 Gnulib 與其他 GNU 軟件包共享的代碼將繼續 要求分配給 FSF。
除了轉讓產權 到開源基金會， 開發者有機會確認將代碼轉移到 Glibc 項目的權利 使用開發者原產地證書 (DCO) 機制。 根據 DCO 的說法，作者跟踪是通過在每次更改後附加“簽名者：開發人員姓名和電子郵件”行來完成的。
通過將此簽名附加到補丁程序，開發人員可以確認其作者身份 關於轉移的代碼並接受其作為項目的一部分或作為免費許可下的代碼的一部分進行分發。 與 GCC 項目的行動不同，Glibc 中的決定不是由上面的管理委員會發布的，而是在與所有社區代表進行初步討論後做出的。
取消強制簽名 與開源基金會的協議 大大簡化了將新參與者納入開發的過程 並使項目獨立於開源基金會的趨勢。 雖然個人參與者簽署CLA只是在不必要的程序上浪費了時間，但對於公司和大公司的員工來說，將權利轉移到STR基金會與許多延遲和法律批准有關，這些並不總是完成成功地。
拒絕集中管理代碼權利也鞏固了最初接受的許可條款，因為現在更改許可需要獲得每個未將權利轉讓給自由軟件基金會的開發者的個人同意。
黃大仙禁運， Glibc 代碼仍獲得“LGPLv2.1 或更新版本”許可，這允許遷移到更新版本的 LGPL，無需額外批准。 由於大部分代碼的權利仍掌握在自由軟件基金會手中，該組織繼續充當 Glibc 代碼分發的擔保人，僅在免費的 Copyleft 許可下。
例如，自由軟件基金會可能會通過與代碼作者的單獨協議來阻止引入商業/雙重許可或封閉專有產品的嘗試。
放棄集中管理的弊端之一 代碼權限, 在談判許可問題時出現了混亂. 如果之前所有關於違反許可條件的索賠都是通過與組織的互動來解決的，那麼現在違規的結果，包括無意的結果，將變得不可預測，需要與每個參與者達成一致。
舉個例子，Linux 內核的情況，個別內核開發者觸發法律行動，包括為了個人利益。
規則變更將於2月XNUMX日生效 並且會影響到所有可以開發的Glibc分支，最後有興趣了解的可以諮詢詳情 在下面的鏈接中。