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