Glibc 开发者发布 最近通过他们制作的邮件列表 接受更改和转让版权的规则的一些具体更改， 取消了将代码的产权强制转让给开源基金会。
与之前在 GCC 项目中采用的更改类比，在 Glibc 与自由软件基金会签署的 CLA 协议已移至应开发人员要求执行的可选操作类别。
随着规则的新变化， 现在将允许补丁接受，而无需将权利转让给 FOSS 基金会，但通过 Gnulib 与其他 GNU 项目共享的代码除外。
拥有 FSF 版权分配的贡献者无需更改 任何事物。 希望使用开发者证书的贡献者 Origin [2] 必须在您的确认中添加“签名者”消息。
通过 Gnulib 与其他 GNU 软件包共享的代码将继续 要求分配给 FSF。
除了转让产权 到开源基金会， 开发者有机会确认将代码转移到 Glibc 项目的权利 使用开发者原产地证书 (DCO) 机制。 根据 DCO 的说法，作者跟踪是通过在每次更改后附加“签名者：开发人员姓名和电子邮件”行来完成的。
通过将此签名附加到补丁程序，开发人员可以确认其作者身份 关于转移的代码，并接受其作为项目的一部分或作为免费许可下的代码的一部分进行分发。 与 GCC 项目的行动不同，Glibc 中的决定不是由上面的管理委员会发布的，而是在与所有社区代表进行初步讨论后做出的。
取消强制签名 与开源基金会的协议 大大简化了将新参与者纳入开发的过程 并使项目独立于开源基金会的趋势。 虽然个人参与者签署CLA只是在不必要的程序上浪费了时间，但对于公司和大公司的员工来说，将权利转移到STR基金会与许多延误和法律批准有关，这些并不总是能顺利完成.
拒绝集中管理代码权利也巩固了最初接受的许可条款，因为现在更改许可需要获得每个未将权利转让给自由软件基金会的开发者的个人同意。
然而， Glibc 代码仍获得“LGPLv2.1 或更新版本”许可，这允许迁移到更新版本的 LGPL，无需额外批准。 由于大部分代码的权利仍掌握在自由软件基金会手中，该组织继续扮演担保人的角色，仅在免费的 Copyleft 许可下分发 Glibc 代码。
例如，自由软件基金会可能会通过与代码作者的单独协议来阻止引入商业/双重许可或封闭专有产品的尝试。
放弃集中管理的弊端之一 代码权限, 在谈判许可问题时出现了混乱. 如果之前所有关于违反许可条件的索赔都是通过与组织的互动来解决的，那么现在违规的结果，包括无意的结果，将变得不可预测，需要与每个参与者达成一致。
举个例子，Linux 内核的情况，个别内核开发者触发法律行动，包括为了个人利益。
规则变更将于2月XNUMX日生效 并且会影响到所有可以开发的Glibc分支，最后有兴趣了解的可以咨询详情 在下面的链接中。