GNU C Library（glibc）系統庫的開發者對接受變更和轉讓版權的規則進行了更改，取消了將程式碼的產權強制轉讓給開源基金會的規定。 類比之前GCC專案中採用的改變，Glibc中與開源基金會簽署CLA協議已經轉移到了應開發者要求進行的可選操作的範疇。 規則變更允許在不將權利轉讓給開源基金會的情況下接受補丁，將於 2 月 XNUMX 日生效，並將影響所有可用於開發的 Glibc 分支，但透過 Gnulib 與其他 GNU 專案共享的程式碼除外。
除了將產權轉讓給開源基金會外，開發者還有機會使用開發者原產地證書（DCO）機制確認將程式碼轉讓給 Glibc 專案的權利。 根據 DCO，作者追蹤是透過在每次更改後附加「簽署者：開發人員姓名和電子郵件」行來進行的。 透過將此簽名附加到補丁中，開發人員確認了所傳輸程式碼的作者身份，並同意將其作為專案的一部分或作為免費許可證下的程式碼的一部分進行分發。 與 GCC 計畫的行動不同，Glibc 的決定不是由理事會自上而下決定的，而是與社區所有代表進行初步討論後做出的。
取消與開源基金會強制簽署協議，大大簡化了新參與者的開發過程，並使專案獨立於開源基金會的趨勢。 如果個人參與者簽署CLA 協議只會導致在不必要的手續上浪費時間，那麼對於公司和大公司的員工來說，開源基金權利的轉讓會帶來許多法律上的延誤和批准，而這些法律延誤和批准並不重要。總是成功完成。
放棄代碼權利的集中管理也強化了最初接受的許可條件，因為更改許可現在需要每個未將權利轉讓給開源基金會的開發人員個人同意。 但是，Glibc 程式碼繼續在「LGPLv2.1 或更新版本」授權下提供，允許遷移到更新版本的 LGPL，無需額外批准。 由於大部分程式碼的權利仍然掌握在自由軟體基金會手中，因此該組織繼續扮演僅在免費 Copyleft 授權下分發 Glibc 程式碼的保證人的角色。 例如，開源基金會可能會阻止嘗試引入雙重/商業許可證或根據與程式碼作者簽訂的單獨協議發布封閉式專有產品。
放棄代碼權利集中管理的缺點之一是在就許可證相關問題達成一致時會出現混亂。 如果以前所有違反許可條件的索賠都是透過與一個組織的互動來解決的，那麼現在違規的結果（包括無意的違規）變得不可預測，並且需要與每個參與者達成協議。 以 Linux 核心為例，個別核心開發者發起訴訟，包括為了獲取個人利益。
來源： opennet.ru