dsp复位后cla不运行_为什么CLA不适合开源

dsp复位后cla不运行

开源中很少有法律主题像贡献者许可协议 （CLA）一样引起争议。 除非您计算Fedora项目贡献者协议的特殊历史案例（我一直将其视为非 CLA），或者像Karl Fogel一样将DCO归类为CLA类型，否则今天Red Hat不会使用它维护的项目的CLA。

并非总是如此。 红帽最早的项目遵循我称为“入站=出站”的传统惯例，在该惯例中，仅根据项目的开放源代码许可提供对项目的捐款，而无需执行外部的非FOSS合同。 但是在2000年代初，红帽开始尝试使用贡献者协议。 Fedora开始要求参与者根据广泛适用的Apache ICLA签署CLA，而自由软件基金会衍生的版权转让协议和一对定制的CLA分别继承自Cygnus和JBoss的收购。 我们甚至采取了一些措施 ，在由Red Hat领导的快速增长的项目集中采用Apache风格的CLA。

这结束了，很大程度上是因为我们在红帽法律团队中的那些人听到并理解了红帽工程师和更广泛的技术社区提出的关注和反对意见。 我们继续成为某些人所说的反CLA运动的事实上的领导者，尤其以我们对Project Harmony的反对以及我们努力使OpenStack用DCO代替其CLA的努力为标志。 （出于实际需要，我们勉强地签署了可容忍的上游项目CLA。）

为什么CLA存在问题

我们不选择使用CLA的选择反映了我们作为一家真正的开源公司的价值观，该公司深深植根于自由软件运动中。 多年来，开放源代码社区中的许多人已经解释了为什么CLA和非常相似的版权分配机制对于开放源代码来说是一个不好的政策。

原因之一是繁文tape节。 通常，开源开发的特征是无摩擦贡献，这可以通过inbound = outbound实现，而无需采取进一步的法律仪式或程序。 这使得新的贡献者相对容易地参与到项目中，从而使贡献者社区更有效地增长，并向上游推动技术创新。 无摩擦贡献是开源开发相对于专有替代产品而言所具有的优势的关键部分。 但是，CLA否定了无摩擦的贡献。 必须先签署不寻常的法律协议，然后才能接受捐款，这会造成官僚主义的障碍，从而减缓发展并阻碍参与。 尽管使用CLA的项目越来越多地使用自动化，但此成本仍然存在。

CLA还导致项目参与者之间法律权力的不对称，这也阻碍了项目周围强大的贡献者和用户社区的增长。 使用Apache样式的CLA，领导该项目的公司或组织将获得其他贡献者无法获得的特殊权利，而其他贡献者必须承担某些法律义务（除了繁琐的手续之外），项目负责人可免除这些义务。 不对称性问题在copyleft项目中最为严重，但即使出站许可是允许的，也存在。

在评估支持和反对CLA的论点时，请记住，与过去一样，今天，任何产品中的绝大多数开源代码都源自遵循inbound = outbound惯例的项目。 相对较少的项目使用CLA会发出信号，表明出于某种原因，开源许可不足以处理流入项目的捐款，从而对所有其他项目造成附带损害。

CLA案例

由于CLA仍然是少数派实践，并且源于外部开源社区文化，因此我认为CLA支持者应承担解释为什么它们相对于其成本而言是必要或有益的负担 。 我怀疑大多数使用CLA的公司都只是在模仿同行公司的行为，而没有进行严格的检查。 对于不愿承担风险的律师，无论业务成本如何，CLA都有一种可以理解的（即使是肤浅的）诉求，他们倾向于使用更大的形式，文书和程序。 尽管如此，一些支持CLA的论点经常被提出并值得考虑。

易于重新许可：如果管理得当，Apache风格的CLA可以有效地赋予项目管理员根据管理员选择的权利来无限制地再许可捐赠。 有时认为这是可取的，因为可能需要根据其他一些开源许可证重新许可项目。 但是，通过指出一些历史案例，大大简化了易于再许可的价值，这些案例涉及由过去贡献者数量异常多的项目进行的大型再许可活动（所有这些都在没有使用CLA的情况下是成功的）。 进行艰难的重新许可有好处，因为它会导致围绕项目的稳定法律期望，并鼓励项目在进行重大法律政策更改之前咨询其贡献者社区。 无论如何，大多数入站=出站开源项目在其生命周期中都不会尝试进行许可，并且对于数量很少的项目，由于过去通常要联系的贡献者的数量不会很大，因此许可将相对容易。

来源跟踪：有时声称CLA使项目能够严格跟踪捐款的来源，据称具有一定的法律利益。 目前尚不清楚通过使用CLA在这方面能实现什么，但是通过诸如保存Git提交历史记录之类的非CLA手段无法更好地处理。 而且，DCO似乎通常更适合跟踪提交，因为它通常在每次提交的基础上使用，而CLA每个贡献者都签名一次，并且在管理上与代码贡献分开。 而且，出处跟踪通常被描述为对公众有利，但是我不知道有任何项目可以向CLA接受记录提供透明，方便的公众访问。

许可证撤销：一些CLA倡导者警告说，有捐助者有一天可能会试图撤销以前的许可证授予的前景。 在某种程度上讲，关注点在于没有公司隶属关系的很大程度上可以判断的个人贡献者，因此，与使用开放源代码许可证相比，尚不清楚为什么Apache风格的CLA针对此结果提供更有意义的保护。 而且，正如在开源法律政策的讨论中提出的许多法律风险一样，这似乎是一种幻影风险。 多年来，我听说只有少数声称撤销许可证的尝试，当贡献者在社区压力下退缩时，所有这些很快就得到解决。

未经授权的员工捐款：这是许可证吊销问题的特例，最近已成为CLA倡导者普遍提出的观点。 当员工为上游项目做出贡献时，通常雇主拥有该项目需要许可证的版权和专利，并且只有某些高管才有权授予此类许可证。 假设一名雇员未经雇主批准就为项目贡献了专有代码，而雇主后来​​发现了这一点，并要求删除该贡献或起诉该项目的用户。 人们认为，通过使用类似Apache CCLA及其表示和签名要求之类的东西，再加上适当的审查过程来确定CCLA签名人可能被授权签名，可以最大程度地减少这种未经授权的捐赠的风险（我怀疑这不是一个步骤）大多数使用CLA的公司有意义地承担了责任）。

基于常识和共同经验，我认为在当今几乎所有情况下，员工的贡献都是在雇主的实际或建设性知识和同意下完成的。 如果围绕开源软件存在高诉讼风险的气氛，也许应该更加认真地对待这种风险，但是由开源项目引起的诉讼仍然非常罕见。

更重要的是，我知道没有任何案例可以通过使用CLA来阻止针对入站=出站项目的版权或专利侵权指控，而该指控并非源于所谓的开源许可证侵权。 特别是当CLA的支持者指出未经授权捐款的风险时，经常会提到专利风险，但是从设计上讲，Apache风格的CLA的专利许可授予范围非常狭窄。 而且，企业对开源项目的贡献通常数量很少，规模较小（因此易于替换），并且随着时间的流逝可能会被丢弃。

备择方案

如果您的公司不赞成反CLA案，并且对inbound = outbound的简单使用不满意，那么可以采用其他方法来解决不对称且给行政带来负担的Apache样式CLA要求。 使用DCO作为Inbound = Outbound的补充，至少可以解决规避风险的CLA倡导者的某些问题。 如果必须使用真正的CLA，则无需使用Apache模型（更不用说它的巨大派生了）。 考虑Eclipse贡献者协议的非规范性核心-本质上是DCO包裹在CLA中-或Software Freedom Conservancy的Selenium CLA ，它仅礼节化了inbound = outbound贡献策略。

翻译自: https://opensource.com/article/19/2/cla-problems

dsp复位后cla不运行