蚊章汇 - 开源智慧
type: channel
link: https://linuxcn.bwsl.wang/category/2585/
items: 开源项目的版权声明已无存在必要？
items: 如何寻找可行之路？开源律师如是说
items: 关系造就成功——律师护航开源的三种方式
items: 源码被倒卖，大厂薅羊毛，开源真的只能被予取予求？
items: 共享、免费还是公有？开源软件的真正定义
items: 开源软件许可出毛病了？
items: 中国 GPL 诉讼第一案：关于 GPL 问题的探讨
items: 开源与标准：为什么对待专利如此不同？
items: 为何《贡献者许可协议》不利于开源社区？
items: 《贡献者许可协议》是“人魔”般的怪物？

开源项目的版权声明已无存在必要？
type: item
date: 2021-02-04T16:57:48+08:00
description: 保留简略的版权声明即可，无需投入过多资源维护。 版权声明 （ Copyright Notice ） 在源代码中的应用并不一致且维护不善，结果导致它无法成为良好的信息来源。那是否应该投入更多资源来维护版权声明呢？答案是不需要。版权声明是单行字符串，通常包括单词“版权”（或某些替代词，如 ©）、名称（通常是个人或公司）和年份。在本文中，我不关注许可证或许可证声明（有时可能包括版权声明）。我关于版权声明维护的资源投入应该保持低优先级的建议不适用于许可证信息。许可证信息应清晰呈现并保持准确。如果你邀请其他人使用你的软件并对其进行操作，请通过提供并维护清晰的许可证信息来明确其授予的权限。再说回版权声明：它们的法律意义是什么呢？如果你认为版权声明符合法律要求或至少提供了重要的法律权益，请三思。此类声明在开源软件中的法律意义是如此之小，以至于人们可以轻易地找到超出其法律意义的实际做法。尽管此类声明可能看起来很重要，但它们在当今源代码中的存在很大程度上是过去美国版权法的残余影响。曾经有一段时间，如果未在已出版的材料中包含版权声明，依据美国版权法，版权人可能会完全丧失权利；当美国最终加入《伯尔尼公约》并成为缔约国时，情况发生了变化（美国于 1988 年 11 月 16 日加入该条约，并于 1989 年 3 月 1 日在美国生效）。如果开源软件中的此类声明要想具备实效，则一个项目可以采用能够以更少的投入来维护并且仍然获得一些实用价值的约定，不必为了满足美国对“版权声明”的法定要求而去维护版权声明。由于美国版权法一直是推动版权声明使用的重要因素，因此我将在此进行更深入的探讨。美国版权局发布了名为《通函-3号-版权声明》的指导文件，包括：“在 1989 年 3 月 1 日之前首次出版的所有作品都必须放置版权声明，但下面讨论的某些情况例外。如果省略了该声明或在使用该声明时出现了错误，则通常该作品在美国将失去版权保护。版权声明对于 1989 年 3 月 1 日或之后出版的作品、未出版的作品和外国作品是可选的；但是，将版权声明包括在你的作品中将享有法律权益。”上面我加粗强调的那句话清楚地表明，在 1988 年的美国，版权声明就非常重要。但是，当美国与其他许多国家一起加入《伯尔尼公约》时，美国法律对版权声明的关键作用被消除了。公约规定：“享有和行使这些权利不需经过任何手续……”麻省理工学院的软件项目（The X Window System）和加州大学伯克利分校的软件项目（Berkeley Software Distribution）中诞生了早期的开源许可证文本，彼时严格的“放置版权声明否则丧失权利”要求仍然有效（或至少在为这些许可证文本做出贡献的人们心中是明确的）。诞生于这种时机的结果是，许可证文本中仍存在有关复制版权声明的明确描述。随着基于早期文本的许可证的继续广泛使用，大多数开源软件开发人员已经看到，版权声明似乎在许可证中显得很重要。但是这些文本是在考虑较早的法律制度的情况下创建的。现在，距《伯尔尼公约》（大多数其他国家已经接受）的“无需手续性要求”规定首次适用于美国的时间已经过去 30 年了。要了解《伯尔尼公约》的通过程度，请参阅管理该公约的世界知识产权组织维护的缔约方清单。你可能想知道上面引用中提到的那些“法律权益”具体指什么，答案在 3 号通函的末尾：尽管对于未出版的作品、外国作品或于1989年3月1日或之后出版的作品，版权声明是可选的，但使用版权声明具有以下好处：版权声明使潜在用户意识到该作品拥有版权。对于已发表的作品，版权声明可能会阻止版权侵权诉讼中的被告试图减轻其基于无辜侵权辩护的损害赔偿或禁令救济的责任。版权声明标识了在首次发布作品时版权所有者的权利，供寻求使用该作品的许可方使用。版权声明标识首次出版的年份，对于匿名作品、假名作品或出租作品而言，可用于确定版权保护期限。版权声明可能会通过标识版权所有者并设定版权期限来防止其成为孤儿作品。上面就是所谓的那些“法律权益”。我引用了美国版权局第 3 号通函，因为与基本法规相比，它对要求的措辞更具可读性。美国联邦一级的成文法被编入所谓的《美国法典》，该法典被组织为一组 “卷” （ Title ） 。第 17 卷是版权。版权声明的详细信息位于该卷的第 401-406 部分。可以从 17 USC 401 开始。在版权声明中需包含三个要素描述的有关法规要求，请参见 17 USC 401（b）。如果要查看“疏忽对无辜侵权者的影响”的详细信息，请参见 17 USC 405（b）。为了提供更准确的信息，为什么不清理代码库中的版权声明？尴尬的是，17 USC 506（c）（欺诈性版权声明）、17 USC 506（d）（欺诈性删除版权声明）和 17 USC 1202（a）（虚假版权管理信息）提供了一些不利因素（即使…

如何寻找可行之路？开源律师如是说
type: item
date: 2020-09-29T05:03:00+08:00
description: 开源法规对成功有不同寻常的要求。一起来了解开源组织的律师如何帮助其雇主找到可行路径。正如我在这个分为两部分的系列文章的第一部分中所分享的那样，我是 红帽公司 （ Red Hat ） 的一名开源律师。我工作中的一个重要部分是向其他公司（包括其内部法律顾问）提供有关红帽公司如何采用完全开源的开发模式来构建企业级产品的信息，并回答他们有关开源许可的一般问题。在听了红帽公司的成功经验之后，这些律师与我对话的话题常常转变为其所在组织如何发展成为更具开源意识和能力的组织，他们也经常询问我如何改善他们的做法，以便更熟练地为其组织的雇员提供开源法律咨询。在这两篇文章中，我将分享我通常在这些主题上告诉内部法律顾问的那些内容。总是要找到一条可行路径我的雇主红帽公司在使用开源软件方面的独特之处在于，我们的开发模式始于具有数千名贡献者的开源社区，并产生了经受过尝试、测试和信任的最终产品。更具体地说，通过我们独特的开发模式，我们从社区创建的开源软件开始，并在每个项目的基础上加强安全性，修复错误，修补漏洞并添加新功能。然后，我们将这些改进回馈给每个项目，以便使整个开源社区受益。此方法的效用非常重要，包括：通过内部团队与组织外部其他人之间的协作来利用外部创新；当现有或潜在的社区与您在同一问题上开展工作而且能够合作时，可以避免您自己开发和维护开源解决方案的成本和效率低下的问题；通过与合作伙伴和上游项目社区的富有成效的合作，能够避免维护主项目下游分支的昂贵代价。一些公司发现创建上游代码的非公共分支很诱人，因为它是解决特定 用例 use case 的快速方法，或者因为它们不愿意在社区中进行协作。然而，由于增加的开发成本、互操作性损失和其他原因，这种分支的长期维护负担可能是令人望而却步的。相比之下，将开发集中在原始上游社区中，可以在所有参与者之间分担开发成本。除少数例外（例如红帽公司）外，大多数使用开源软件的组织可能都拥有专有软件许可模式（或与 SaaS 等效的概念），并在其业务中对专有软件进行许可。这些组织认为他们拥有可以提供某些竞争优势的软件组件，并且不希望看到这些组件在开源条款下对其他人可用。这是可以理解的。但是，我会鼓励任何咨询此类问题的开源律师来敦促其客户采用开源开发模式，尤其是对于所有无差异且通用的软件。例如，如果您的公司开发了用于手机的应用程序，并且您需要一个软件模块来读取和写入 PNG 图像文件，那么使用 GitHub 上流行的开源 PNG 软件模块之一将便宜得多。对于您的业务而言，对 PNG 图像进行编码和解码可能是无差别的，那么为什么要花费宝贵的工程时间来编写自己的版本？此外，为此功能编写自己的模块也可能会导致与使用常用开源模块的其他软件的兼容性问题。这是为什么呢？尽管您的模块和开源模块可能已被编写为对已发布的 PNG 规范进行编码和解码，但有时对规范的解释可能会有所不同，也可能会出现实施错误。使用同一模块执行此功能的每个人都可以确保大多数用户的兼容性，并降低开发和维护成本。还必须意识到，您可能需要某些软件来保持专有性，并且不受开源条款的约束。取决于您系统的软件体系架构和所使用的开源许可证，除非采取某些措施（超出本文的范围），否则打算保留专有权的软件代码可能会受到开源许可证条款的约束。在这里向客户提供一些有关许可证选择和体系架构的咨询服务将变得很有用。寻找灵活的解决方案之前主要许可专有软件的组织逐渐增加了对开源软件的使用，但审核和批准的要求可能会增长（以我的经验甚至成倍增长）。由于资源限制，这样的组织可能会陷入困境。下面介绍了一些可以采用的灵活的解决方案。授权并委托他人律师不能也不应成为看门人。那样效率低下，并且肯定会导致开发和发布时间出现瓶颈，从而产生挫败感和收入损失。相反，应将审批权限授予产品或项目管理和工程领域有能力的个人。这可以让组织有效地保持灵活性。对客户进行教育（请参阅下一节）对于成功实现这一点至关重要。我采用的一种方法是为整个工程组织提供开源培训，以便他们可以进行基本的许可模式和体系架构选择，同时为软件开发人员提供更专业的培训，以使他们能够提供更复杂的指导和决策。也要考虑在每个级别上对权限进行明确限制，包括哪些类型的问题和决定必须上报给作为他们开源律师的您。您组织的特定授权级别将取决于您团队在开源方面的经验以及对某些开源问题的敏感性。教育客户我发现培训是将您的组织迁移到更具开源意识组织的最有效工具之一。培训您的软件工程师和产品经理至关重要。让我详细说明。尽管您的软件工程师处在最前沿，并且通常可能对开源问题和软件许可非常了解，但是基于您组织的特定要求对他们进行培训仍然很重要。例如，您的公司可能只允许使用宽松的开源许可证，并且可能对其版权声明和源代码可用性有某些要求。为避免开发中出现随后必须纠正的问题（一种昂贵且耗时的实践），最好培训…

关系造就成功——律师护航开源的三种方式
type: item
date: 2020-09-06T18:02:36+08:00
description: 开源法规之所以独特，是因为它对成功的要求比较特殊。一起来了解开源组织的律师如何帮助其雇主达成目标。我是 红帽公司 （ Red Hat ） 的一名开源律师，我工作中的一个重要部分是向其他公司（包括其内部法律顾问）提供有关红帽公司如何采用完全开源的开发模式来构建企业级产品的信息，并回答他们有关开源许可的一般问题。在听了红帽公司的成功经验之后，这些律师与我对话的话题常常转变为其所在组织如何发展成为更具开源意识和能力的组织，他们也经常询问我如何改善他们的做法，以便更熟练地为其组织的雇员提供开源法律咨询。在本文和下一篇文章中，我想阐述一下针对这些话题我通常对企业内部法律顾问是怎么说的。如果你不是内部法律顾问，而是在软件领域为客户提供法律服务的律师事务所，你可能还会发现此信息也很有用。（如果你正在考虑上法学院并成为一名开源律师，则应在进入开源律师职业之前阅读 Luis Villa 的出色文章《在入坑成为开源律师之前先要知道的那些事儿》）我的观点基于我在各种工程实践、产品管理和律师职位上的个人经验，并且这种经验可能非常独特。我的非典型背景意味着我能通过与大多数律师不同的视角看世界。因此，下面介绍的想法可能不是传统做法，但是在我的实践中它们对我很有帮助，希望对你也有所帮助。一、与开源组织保持联系许多开源组织对开源律师来说特别有用，其中不少组织对开源许可协议的观点和解释具有可以衡量的影响。可以考虑加入一些著名组织，例如 开源促进组织 （ Open Source Initiative ） （OSI）、 软件自由保护组织 （ Software Freedom Conservancy ） 、 软件自由法律中心 （ Software Freedom Law Center ） 、 自由软件基金会 （ Free Software Foundation ） （FSF）、 欧洲自由软件基金会 （ Free Software Foundation Europe ） 和 Linux 基金会 （ Linux Foundation ） 。还有许多有用的邮件列表值得追踪甚至参与，例如 OSI 有关许可协议讨论和许可协议审查的邮件列表。参加这些组织和列表将帮助你了解在落实开源法规时可能遇到的无数独特问题，比如社区如何解释开源许可协议文本里的各种术语。没有什么判例法可以指导你，但是有很多人乐于帮助你回答问题，这些资源是最好的指导来源。这也许是落实开源法规的非常独特而令人惊奇的一个方面——开发社区的开放性与法律社区提供观点和建议的开放性相匹配。你只要问就行啦！二、采用业务经理的思维方式，并找到实现目标的途径产品经理最终要对产品或服务的全周期负责，其中当然也包括让其产品或服务进入市场。由于我的职业生涯的大部分时间都花在服务产品管理型组织上，所以我的思路是无论如何要寻找一条途径，将可行的产品或服务推向市场。我鼓励所有律师都采用这种思维方式，因为产品和服务是所有企业的命脉。因此，在发现问题并为面临风险的客户提供建议的法律实践中，我一直采用的方法是始终以寻找通向“YES”的途径为目标，尤其是当我的分析影响产品/服务开发和发布时。在为企业内部评估法律问题时，我的团队或我有时可能会认为风险过高。在这种情况下，请继续鼓励每个人都致力于去解决问题，因为以我的经验，解决方案最终会以一种意想不到的方式呈现出来。确保利用你的所有资源，包括你的软件开发客户（参见下文），因为它们可以成为解决问题（通常使用技术来解决问题）的创造性方法的绝佳来源。我对这种方法感到非常高兴，我的客户似乎也对此感到满意。我鼓励所有律师考虑这种做法。可悲的是，内部法律顾问出于自我保护总是很容易说“NO”，并消除可能对企业造成任何风险的因素。我总是发现这种回应是站不住脚的。所有商业交易都有风险。作为法律顾问，你必须了解这些风险并将其呈现给你的客户，以便他们做出有根据的业务决策。在存在任何风险时简单地说“NO”，而没有提供任何缓解风险的其他情境或途径，对组织的长期成功不利。企业需要提供产品和服务才能生存，你应该尽可能地帮助它找到通向“YES”的道路。当然，在某些情况下，你可以负有道德责任地说“NO”，但首先请穷尽所有合理的选择。三、与开发人员建立积极关系与你的软件开发客户建立积极关系绝对至关重要。融洽和信任是加强这些关系的两种重要方法。1、融洽你作为开源律师的成功通常是与软件开发人员建立积极关系的直接结果。在许多情况下，你的软件开发人员是你的法律建议的直接或间接接受者，他们将寻求你的指导和咨询。不幸的是，许多软件开发人员对律师持怀疑态度，并经常将律师视为其开发和发布软件能力的障碍。克服这种弊端的最好方法是与客户建立融洽的关系。对于大多数人来说，操作方式有所不同，但是这里有一些建议。对客户的工作表现出兴趣：对他们项目的细节、项目的工…

源码被倒卖，大厂薅羊毛，开源真的只能被予取予求？
type: item
date: 2020-03-24T18:05:00+08:00
description: 今天看到一篇文章《开源项目在闲鱼、b 站上被倒卖？这是什么骚操作？》，我突然想起了之前两个类似的案例，发现群众的开源知识普及依然不足，借这个机会再聊聊开源，从开源著作权人的角度做一次讨论。案例 1：倒卖开源代码本案例中，作者十三发现自己开源的代码被贩卖，一脸郁闷。先不讨论这些倒卖者的行为，笔者从作者提供的代码托管官网上看到其开源许可证是 MIT。MIT 作为一个宽松型开源许可证，授予使用者几乎无限制的权限。也就是说倒卖者的行为固然让人讨厌，但其确实是可以这么做的。当然，作者十三除了困惑于开源的东西为何还有人拿去卖钱以及竟然还有人买之外，整体上是淡定、大度的。而倒卖者利用的正是大众的这种专业知识的缺失和信息的不对称性，严格意义上这是存在经济正当性的。案例 2：王垠闭源这个案例是 2017 年的旧闻，但很具代表性。BSD 许可证开源的软件被商业公司商业使用，还聘请了原开发者，最后闹的鸡飞狗跳。注：原博文《为什么我的代码进入闭源状态》地址已经 404 无法访问，大家可以搜索相关转载。王垠此人我不甚了解，据说曾经国内人气非常高，知乎、v2ex、csdn 博客上到处都有对他的评价和争论。但至少从这篇帖子可以看出，其对开源的理解很浅、也很狭隘（在 2017 年时，不代表现在）。其对开源抱有不该有的幻想，期待过高。案例3：swoole 修改开源协议这个案例也是 2017 年的，以 Apache 许可证开源的软件 swoole（撰文时经核实 swoole 依然是 Apache 许可证），与其复刻分支版本之间纷争。这个案例更像各种 Android 发布版与 Google Android OS 之间的关系，以宽松型许可协议开源的软件被各种修改版骚扰、蹭热度的现象很普遍。开源知识普及之路漫长以上三个案例都可以称之为开发者的控诉，暂不评论其控诉是否合理。仅以这些事件本身以及在网上引起的纷争，都说明距离开源在国内普及，还有很长的路要走。但值得欣慰的是，从 2017 年到 2020 年我们看到了这种进步，案例 1 中的作者对开源的理解上虽有偏颇，但并没有出现知识或法律方面的硬伤。 从开源软件概念引入中国，到近几年开源运动如火如荼的开展，已有几个年头。但据笔者与企业及业内人士的接触发现，公众对开源的认知和理解程度依旧参差不齐。究其原因有以下几点：大部分关注开源的人，更多的是关注技术，不会关注其背后的许可证问题；开源许可证更偏向法律，真正做技术的不关注、也不懂；开源许可证法律条文晦涩难懂，不容易理解；懂技术、会看代码的专利、著作权、商标等领域的律师甚少，没有技术背景的律师纵使法律水平再高，在理解涉及开源软件相关问题时也力不从心；开源领域国内诉讼不多，没有充分引起大部分企业、学界等人员的重视；也因为诉讼少，经济驱动力有限，很难吸引律师深入研究这一领域。重赏之下必有勇夫，若有足够的利益驱动，修个计算机学位又何妨，或者报个代码速成班也不是不可能吧。笔者有缘在多年前接触开源治理、合规问题，时不时看到网上爆出浅层次开源“事故”，说明大众的开源知识有限。今天蹭个热乎劲，再探讨一下开源基础知识（开源科普的知识网上并不少，没人关注归根结底还是这个领域内生动力不足所致）。既然内生动力不足，就靠外部热点的外部动力吧。开源“事故”，你是否理解开源？开源是什么？开源就是奉献，无私或有私的奉献。此处不接受反驳。开源运动起源于自由软件运动，自由软件运动的发起人 理查德·马修·斯托曼 （ Richard Matthew Stallman ） 是自由软件运动精神领袖。自由软件运动所要反对的就是后来以比尔盖茨（曾经）为代表的软件私有化运动。所以说，自由软件是旗帜鲜明的追求奉献、共享和软件自由的。开源运动的兴起是自由软件运动向商业化的妥协（可以这么说，毕竟经济基础决定上层建筑），所以说开源软件运动虽然有别于曾经的自由软件运动，奉献和协作依然深深的烙在其血液里。如果你无法理解这一点，就再看 10 遍开源软件的定义（直到看懂为止）。开源运动淡化了自由软件运动乌托邦式的理想主义，穿上了实用主义的外衣，毕竟空洞的理想是填不饱肚子的。开源“事故”，背后的起因网上时不时爆出的开源“事故”大都归于两类：类型一：批判拿来主义者坐收渔利、不劳而获、贩卖别人劳动成果……。这一类主角，多是软件开发者自己，站在自己的立场上看待开源软件的使用者（合法使用者、不合法使用者）。该类“事故”的原因有：软件的开发者没有充分理解开源的要义；对开源许可证不理解，开源自己软件时没能正确选择许可证，导致自己有被白piao的感觉；想借助大众或社区的力量优化自己的软件，获得免费劳动力；想借助开源扩大自己影响力（自我营销），却没考虑为此要付出的代价；看到其他人利用自己的开源软件获利，心理上有些许不平衡。类型二：批判开源软件收费、许可证不人性…

共享、免费还是公有？开源软件的真正定义
type: item
date: 2020-03-19T18:48:48+08:00
description: 如果你认为开源软件是共享软件、免费软件和公有领域软件的代名词，那么你并不是唯一有这种看法的人。当你听到“ 开源软件 （ open source ） ”一词时，你是否认为它与诸如 共享软件 （ shareware ） 、 免费软件 （ freeware ） 或 公有领域软件 （ public domain ） 之类的术语同义？ 如果是这样的话，你并不是唯一有这种看法的人。在软件行业内外的许多人都认为这些术语是一样的。本文说明了这些术语的不同之处，认为开源是一种变革性的许可和开发模式。分享我与以上几种软件打交道的经验，可能是探究差异的最佳方法。共享软件和免费软件早在 1982 年，当我在 Apple II Plus 上用 BASIC 编写代码时，我就开始从事计算机程序员的工作。我回想起去家乡当地的计算机商店，并在塑料袋中找到看起来价格高昂的装有游戏和实用程序软件的软盘。请记住，这是从一个中学生的角度来看的。但是，有一些软件可以免费或以最低价格获得。依据具体许可模式，它被称为共享软件或免费软件。在共享软件模式下，你只能在一定时间内使用该软件，如果你发现它有用，则要求你将支票寄给该软件的作者。但是，某些共享软件实际上也鼓励你复制并提供给你的朋友。这种模式通常称为免费软件。也就是说，共享软件和免费软件确切定义之间的差异十分微小，因此很容易将两者简单地统称为“共享软件”。我虽不能肯定，但是我不记得我是否向任何软件作者提供过使用共享软件的费用，主要是因为我在十几岁的时候就没有钱，但是我肯定喜欢使用这些软件程序，并且从中学到了很多有关计算机的知识。回顾过去，我现在意识到，如果该软件是根据开源许可条款而非共享软件条款提供的，那么作为一名新兴的程序员，我本可以在成长中学到很多东西，并且可以取得更多成就。这是因为几乎没有共享软件会提供源代码（即，人类可读的软件形式）。共享软件还包含许可限制，禁止接收者试图泄露其源代码。如果无法访问源代码，则很难了解该软件的实际工作方式，从而很难扩展或更改其功能。这使得最终用户完全依赖共享软件原始作者进行任何更改或改进。使用共享软件模式，任何开发人员社区几乎都不可能对代码施加影响，并进一步围绕代码进行创新。再分发和商业使用也可能受到进一步的限制。尽管共享软件可能在价格方面是免费的（至少在最初是免费的），但它在自由权利方面并不是免费的，并且不允许你通过探索代码的内部原理来学习和创新。这就引出了一个大问题：它与开源软件有何不同？开源许可的基础首先，我们需要了解“开源”是指许可模式和软件开发模式，两者与共享软件都有很大不同。在一种称为非 “左版” （ copyleft ） 开源许可的开源形式下，向用户提供了关键的自由权利，例如对访问源代码没有限制；可以出于任何目的出售、使用或赠送该软件；可以修改软件。这种形式的许可也不需要支付任何使用费或许可费。因为许可是高度宽松的，不需要谈判就可以使用，这种许可模式的一个惊人结果是它具有独特的能力，可以使无数软件开发人员协作起来对代码进行新的、有用的更改和创新。尽管从技术上讲，在这种许可模式下不需要提供源代码，但是几乎所有人都可以使用它来查看、学习、修改和分发给他人。非“左版”开源许可的另一个方面是，此类软件的任何接收者都可以添加其他许可限制。这意味着以这种许可形式对代码进行许可的初始作者，无法阻止接收者可能依据限制性更强的条款不再进一步许可给其他人。例如：假设作者 Noah 编写了一些软件，并根据非“左版”开源许可将其分发给了接收者 Aviva。然后，Aviva 修改并改进了 Noah 的软件，她有权根据非“左版”开源许可条款使用该软件。然后，Aviva 可以决定对可能限制该软件使用的任何接收者施加进一步的限制，例如在何处或如何使用它（例如，Aviva 可以增加一项限制，规定该软件只能在以下地区使用：加利福尼亚，并且不允许在任何核电厂中使用）。 即使 Aviva 可以访问源代码，也可以选择永远不将修改后的源代码发布给他人。不幸的是，有无数的专有软件公司以上述方式使用非“左版”开源许可软件。实际上，共享软件程序可以通过添加共享软件类型限制（例如，无法访问源代码或排除商业用途）来使用非“左版”开源许可软件，从而将非“左版”开源许可代码转换为共享软件许可模式。幸运的是，许多使用非“左版”开源许可软件的专有软件公司都看到了发布源代码的好处。这些组织一般通过诸如 GitHub 之类的软件存储平台向其接收者或更广泛的开源社区提供修改后的源代码，从而继续保持开源模式的持久性，实现创新的良性循环。这并不是完全出于慈善目的（或者至少通常不是这样）：这些公司希望鼓励社区创新和进一步改进，从而使他们也一并受益。同时，许多专有软件公司不选择这样做，这也完全符合非“左版”开源许可证条款的规定。“左版”许可的开源…

开源软件许可出毛病了？
type: item
date: 2020-03-04T01:18:26+08:00
description: 对于让开源软件变得如此出色的协作开发来说，开源软件许可以其不同于常规软件许可的方式提供了诸多支持。人们在使用常规软件许可时产生的实践和期望，也许会让他们在面对开源软件时感到沮丧。“请给我看下许可证”这种简单的要求，可能得不到令人满意的答复。尽管有的时候这种答复非常简单，但开源软件的许可信息通常更为复杂，达不到常规软件许可所设定的那种期望。这是怎么回事儿呢？开源软件许可是否出毛病了？然而并没有。许可条款类型以及软件开发方式的差异，都会导致软件许可信息的传送方式不同。律师便利性和开发人员便利性之间的折衷是造成这种状况的部分原因。如果只是说开源软件可以“协作”开发，那还没有弄清楚开源开发活动与常规许可软件之间可能存在的差别程度。尽管有像常规许可软件一样由一个人或一个固定的小团体来维护的开源项目，但是在开源项目上的协作可能会在广泛的潜在贡献者之间进行。例如，根据 GitHub 的“2019 年 Octoverse 报告” ，有超过 35 万人对前 1000 个项目做出了贡献。但是，开源软件开发与常规许可软件开发的不同之处不仅仅是贡献者数量。除了被发现对该开源项目拥有某些共同兴趣，为开源项目做出贡献的人们之间可能没有任何联系。人们的参与情况可能会随着时间的推移而变化。原始开发人员可能会离开，留下其他人继续进行项目开发。所有这一切都可能在没有规划或总体治理组织的情况下发生。除了遵循规范性的治理规则，开源协作活动还是轻量级的，而且可以比常规许可软件更加灵敏地响应。有关开源许可信息的实践与这种协作开发方式相适应。针对二进制文件以及源代码，开源许可中的条款通过提供所需的权限（包括复制、修改和分发）促进了协作开发。事实证明， “开源定义” （ Open Source Definition ） （OSD）有助于将注意力集中在满足其要求的许可上。开源软件的许可信息嵌入在源代码中。当获得源代码时，就会接收到相应的许可信息。想象一下每年以百万计的贡献规模，单独的许可管理是否完全可行呢？同样，通过将许可信息嵌入源代码中，可以反映与许可相关的详细信息，而这些细节在某些单独管理的许可流程中不可行。例如，将许可信息嵌入源代码，使得指示哪些许可条款适用于软件的哪些部分变得切实可行。为了说明开源许可实践所能实现的效果，请考虑以下示例性软件项目：该项目始于 5 年前；到目前为止，已有 50 位贡献者做出了贡献；通过改编其他项目中的部分软件，增加了一些功能；原始代码的开发者在三年后离开；几家商业企业已经在其内部或一部分产品中依赖该软件；如果考虑到其他软件和计算机世界方面相关的变化，则该软件未来可能还会有 5-10 年的发展。在开源项目中现有和常用的表示许可信息的方法，很容易适应这样一个项目的过程。没有预先规划，贡献者可以从项目中来来去去；项目的各个部分遵循不同的许可条款；如果与其他公司的合作破裂，商业企业可以继续以很少的管理开销成本分担软件维护工作，同时保持完全独立开发其软件分支的能力。相反，传统的软件许可方法将如何支持这种开发呢？甚至这样的合作有可能发生吗？我们是否将拥有一个完整的许可基础结构来跟踪数千个“主软件开发和分发协议”的适用性？我们是否要通过让某些公司控制一切来简化许可？让我们回到“是什么许可？”这个问题。我谈论开源开发特征的目的，是说明存在重要的影响开源许可信息如何表示的非法律因素。开源软件中许可信息的表示形式通常不符合常规软件许可的期望。但是，存在差异并不代表系统出毛病了。相反，对于支持过去二十年中已被证明有效的大规模协作开发这种软件构建方法来说，差异的作用非常强大。开源许可信息是什么样的呢？通常，人们会考虑每个“软件组件”的许可条款。软件组件可能作为应用程序对用户可见，或者对于用户来说可能不那么明显，例如与大型程序结合使用时可提供某些功能的库。对于许多软件组件而言，许可很简单：组件中的所有软件适用数十种最常见的开源许可证中的一种。除了最常见的许可证之外，还有很多文本有所变动的不经常使用的许可证。但是，在“开源定义”的指导下，开源许可条款中的权限和限制仍保持在一定范围内。如果要进行将开源软件集成到其他软件中的软件开发，那么你需要了解适用于所集成软件的所有 “左版” （ Copyleft ） 条款（例如著名的 GPL 系列许可证）。由于从我对开源软件开发方式的讨论中揭示的显而易见的原因，许可信息可能比单个许可证更为复杂。尽管一个软件组件可能有一个主要的“项目许可”，但可能有一部分软件遵循其他许可证。这可能会导致在源代码的各个部分中出现不同的许可声明。一些项目的做法是在每个源文件中放置版权声明。其他项目主要依靠放置包含许可文本的一个或多个文件。版权声明指示谁可能是该软件部分的版权拥有者（但是，鉴于版权声明实践的多样性，该指示的作用可能微不足道）。用来构建软件…

中国 GPL 诉讼第一案：关于 GPL 问题的探讨
type: item
date: 2019-12-17T16:57:01+08:00
description: 2019 年 11 月初，数字天堂（北京）网络技术有限公司（下称：数字天堂）诉柚子（北京）科技有限公司、柚子（北京）移动技术有限公司（下称：两柚子）侵犯计算机软件著作权纠纷案，由北京高级人民法院二审作出终审判决。笔者曾密切关注该案，终审判决生效前，囿于关联代理关系的利益冲突，不便多谈。现将本案相关若干问题梳理成文，愿与各位探讨之。本案之所以受关注，是因为本次计算机软件著作权侵权案涉及开源软件和 GPL 许可证，本案的判决对未来开源软件诉讼实践有重要意义。本案一审法院对 GPL 相关条款作了阐述，二审法院回避了 GPL 问题。本文，笔者基于本案事实和法院判决做些思考，分享给大家讨论。本文将仅对涉及开源软件及 GPL 许可证的内容进行论述，其他法律问题不作探讨。案情简介为节省篇幅，以下对案情进行摘要和总结，详细案情可见一审链接和二审链接。经过一审和二审对事实的调查和确认，两柚子认可：数字天堂是 HBuilder 软件的著作权人；数字天堂拥有 HBuilder 软件中的代码输入法功能插件、真机运行功能插件、边改边看功能插件源代码著作权；两柚子的 APICloud 软件中对应插件源代码部分与涉案的三个插件具有同一性。基于此，针对本著作权侵权控诉，两柚子抗辩理由只有 GPL 开源许可协议这一个突破口。而二审中对涉案代码量、侵权产品数量的认定，以及基于此对赔偿额的认定，只是量的维度问题。开源许可证是法律文件一审法院虽未明确 GPL 许可证的法律效力，但在论述涉案三个插件是否受 GPL 协议限制时，默认了 GPL 许可证具有法律约束力。这一点虽然是意料之中，但毕竟开源理念和大部分开源协议来源于国外，且应用于开源社区特定人群，这一认定给未来涉及开源软件的诉讼消除了部分不确定性。为了强调协议内容，下文涉及 GPL 许可证的除特指许可证本身外，都以 GPL 协议指代。法院虽然默认了 GPL 协议具有约束力，即类似于协议或合同的法律效果，但并未进一步将 GPL 协议条款基于我国著作权法进行解释。社区内关于 GPL 协议的解释，特别是关于 GPL 传染性的解释是基于美国版权法，其能否为国内法院认可，依然存在不确定性。随着开源理念的深入以及开源软件在世界范围内的普及，本案作为中国 GPL 第一案，对未来开源软件相关的诉讼意义重大。稍有遗憾的是，两审法院并未就开源软件以及 GPL 协议的关键问题进行阐述。当然，也不可能期待 GPL 问题通过一次诉讼案件完全解决，未来还需要更多的法律、学术、技术等人士贡献智慧。关于一审认定的思考既然法院确认了 GPL 协议的法律约束力，那么对 GPL 协议的解释要么采取社区通说解释，要么基于我国著作权法作独立解释。否则很容易出现矛盾或模糊，以至于增加企业开源实践中的法律不确定性。关于 GPL 协议约束力范围（传染性），一审法院以涉案的三个插件可以独立运行，分别存放在三个独立的文件夹中且三个独立文件夹中无 GPL 许可证，据此认为涉案三个插件不属于 GPL 协议中所指应被开源的衍生产品或修改版本。GPL 许可证中有关的原文如下：The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".)——GPL 3.0To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a “modified version” of the earlier work or a work “based on” the earlier work.A “covered work” means either the unmodified Pro…

开源与标准：为什么对待专利如此不同？
type: item
date: 2019-11-14T21:42:00+08:00
description: 两者之间的差异对我们如何构建软件开发过程产生了影响。制定标准规范和开源软件的开发有许多共同之处：两者都是竞争者可以合作的机制；两者都可以促进互操作性；两者都可用于促进新技术的采用；两者都可用于聚合或协调成熟技术。一项技术可以同时使用标准和开源：有时一个先于另一个；在其他情况下，它们可以并行进行。它们越来越多地使用类似的工具和流程实践（例如，细粒度版本控制；利用问题跟踪器一起推动某些开发讨论）。相似程度可能导致过度概括，错误地暗示一切都是可互换的（混合与搭配），在这儿选择一种做法；在那儿将它与一个过程相结合。实际上，获取在一个领域中获得的经验并查看它提供的好处是否可以在其他环境中获得，可能是有价值的。但是，对于某些实践而言，背景更为重要。虽然有相似之处，但也存在显著差异。在前面的文章《没有规则的治理：复刻潜力如何帮助项目》中，我讨论了在利用 复刻 （ forking ） 潜力作为一种可以促进轻量级治理的力量方面，开源软件开发和标准开发治理能力的不同。另一个不同之处在于专利规则的选择。如何对待专利参与者专利权的处理通常在开源软件开发和标准开发中以不同方式排列。这种差异有一个理由。而且，这种差异会对构建开发过程产生影响。开源：在为开源项目做出贡献时授予的专利许可通常由每个贡献者的贡献确定。标准：参与者在标准制定方面做出的专利承诺通常由整个最终规范确定。开源项目：基于贡献的专利规则基于贡献的专利规则是什么意思？如果专利所有者提供软件，由于软件添加到项目中，项目软件侵犯了该贡献者拥有的专利，那么贡献者不应该返回来期望获得使用它所贡献的软件的专利许可费。当然，有许多不同的许可文本可以让我们忙于分析每个许可的解释，并讨论情况中的不确定性和细微差别。在另一篇文章中，我在 MIT 许可协议的背景下谈到了这个问题（《为什么 MIT 的专利许可不讨人喜欢？》）。我认为，基本上来说，开源开发中的共同期望就像我上面所描述的那样：当你为开源做出贡献时，你将为你提供的软件提供所有必需的权限，之后你将无法返回来再要求获得使用你所贡献软件的许可费。标准制定：基于标准规范的专利规则相比之下，在制定标准时，通常会有更高的期望：参与者应对专利做出承诺，这些专利对整个最终规范至关重要，而不仅仅是对其贡献。这些专利承诺并不取决于确定谁对规范提出了什么想法；对于那些参与开发规范的人来说，他们的承诺是整个标准规范。包括在其中的专利确定相关专利的分析在软件和规范之间也有所不同。软件通常包括与相应的标准规范相比不需要的实现细节；在提供软件时，将包括对这些细节使用任何专利的许可。相反，规范开发的专利承诺仅限于对规范“必要”或“必需”的专利。当然，这取决于规范的内容。对于互操作性标准，规范应仅包括实现互操作性所需的详细级别，从而允许实现细节在标准的竞争性实现之间有所不同。对必要专利的承诺不包括实施细节方面的专利，这些专利可用作竞争优势。专利规则差异的基础为什么在专利处理方面存在这种差异？鉴于标准和开源软件的开发方式存在差异，这种不同的处理方式很有意义。更有限的与贡献范围相关的专利符合大多数协作软件开发的渐进式、开放式特性。开源项目经常持续发展，其方向可能会随着时间的推移而演化。虽然可以设置路线图和里程碑并发布快照版本，但这些不太常见，并且比标准项目中常见的范围限制和版本目标具有更少的限制性影响。可以看出，考虑到标准规范开发结构的差异，标准开发的更高期望值（整个最终规范，不仅仅是贡献）是有意义的。标准规范通常采用具有明确范围的强版本导向演进。规范开发通常适用于特定的快照版本。标准开发活动通常具有一组目标功能（通常在诸如章程之类的文档中表示）。与许多软件开发活动的情况相比，这为可能应用到标准开发活动的技术范围提供了更清晰的公共的进展预期。这种范围的明确性有助于潜在参与者在开始参与时评估参与标准制定项目的专利影响。相比之下，开源软件开发项目更为开放，通常不会排除采用任何特定技术的可能性。对开源项目和标准管理的影响这些对待专利的不同措施需要不同的项目管理方法。开源项目通常准备接受来自新贡献者的补丁。贡献者可能会随着时间的推移而来去。一些贡献者留下来。其他人可能会为该项目来解决一个有限的问题。通过软件贡献，可以更容易地了解谁贡献了什么软件，而不是准确理解谁以一种更抽象的方式“参与”。另一方面，参与标准制定活动通常具有大量的正式手续。而且，在涉及专利承诺时，这种参与的正式性非常重要。当一个人参与该规范的大部分开发时，对最终规范的专利承诺是有意义的。标准制定过程是否可以从提供单一、有限贡献的人那里获得完整的最终规范承诺？重要的是要有一个过程，以便清楚地了解谁参与谁，谁不参与。需要明确参与者以支持来自实际专利所有者的专利承诺，实际专利所有者通常是由坐在桌旁（比喻，尽管这可能涉及实际的谈判桌）的个人…

为何《贡献者许可协议》不利于开源社区？
type: item
date: 2019-05-10T17:16:01+08:00
description: 开源社区中很少有法律话题像《贡献者许可协议》一样具有争议性。开源社区中很少有法律话题像《贡献者许可协议》（CLA）一样具有争议性。除非你算上《Fedora 项目贡献者协议》（我一直被视为非 CLA）的特殊历史案例，或者像 Karl Fogel 一样，将《开发者原创证书》（DCO）归类为一种 CLA。目前红帽公司在其维护的项目中没有使用 CLA。过去情况并非如此。红帽公司最早的项目遵循我称之为 “入站=出站” （ inbound=outbound ） 的传统做法，其中对项目的贡献仅根据项目的开源许可协议提供，不需要执行外部非自由和开源许可协议。但在 21 世纪初，红帽公司开始尝试使用贡献者协议。Fedora 开始要求贡献者签署基于广泛采用的 Apache ICLA 制定的 CLA，而自由软件基金会衍生的版权转让协议和一对定制的 CLA 分别继承自 Cygnus 和 JBoss 的收购。我们甚至采取了一些措施，在快速增长的红帽公司主导项目中采用 Apache 风格的 CLA。这种情况已经结束，很大程度上是因为我们红帽公司法律团队成员听到并理解了红帽工程师和更广泛的技术社区提出的担忧和异议。我们继续成为一些人称之为反 CLA 运动的事实上的领导者，特别是我们反对 Project Harmony 以及我们努力让 OpenStack 用 DCO 取代其 CLA。（我们不情愿地签署可容忍的不符合实际需要的上游项目 CLA）为什么 CLA 存在问题我们不使用 CLA 的选择反映了我们作为一个真正的开源公司的价值观，它在自由软件运动中有着深厚的根源。多年来，许多开源社区已经解释了为什么 CLA 以及类似的版权分配机制对于开源来说是一个糟糕的政策。其中一个原因是繁文缛节问题。通常情况下，开源开发的特点是 无障碍 （ frictionless ） 贡献，这可以通过“入站=出站”来实现，而不需要进行进一步的法律仪式或流程。这使得新贡献者相对容易参与项目，允许贡献者社区更有效的增长并推动上游的技术创新。无障碍贡献是开源开发针对专有替代品享有优势的关键部分。但是，CLA 否定了无障碍的贡献。在贡献被接受之前签署不寻常的法律协议会造成官僚主义障碍，从而减缓发展并阻碍参与。尽管采用 CLA 的项目越来越多地使用自动化手段，但这种成本仍然存在。CLA 还会导致项目参与者之间的法律权力不对称，这也阻碍了项目周边主要贡献者和用户社区的增长。使用 Apache 风格的 CLA，领导项目的公司或组织获得其他贡献者无法获得的特殊权利，而其他贡献者必须承担项目负责人免除的某些法律义务（除了繁文缛节负担）。在 左版 （ copyleft ） 项目中，不对称问题最为严重，即使出站许可协议是宽松的，它也存在。在评估支持和反对 CLA 的论据时，请记住，今天与过去一样，任何产品中的绝大多数开源代码都源于遵循“入站=出站”实践的项目。相对较少数量的项目使用 CLA 会对所有其他项目造成附带损害，因为它表明，由于某些原因，开源许可协议不足以处理流入项目的贡献。CLA 的案例由于 CLA 仍然是少数人的做法，并且源自外部开源社区文化，我认为 CLA 的支持者应该解释清楚为什么它们相对于其成本是必要或有益的。我怀疑大多数使用 CLA 的公司只是在没有经过严格审查的情况下模仿同行公司的行为。肤浅的来说，对于那些倾向于采用更复杂的手续、纸张和流程而不管业务成本如何的风险规避律师而言，CLA 是正常的。尽管如此，一些支持 CLA 的论据往往是先进的，值得考虑。易于 再许可 （ relicensing ） ：如果管理得当，Apache 风格的 CLA 可以根据管理员的选择，为其提供有效的无限权力来进行分许可。这种做法有时被认为是可取的，因为可能需要依据一些其他开源许可协议再许可该项目。但是，回顾一些涉及大量贡献者的项目（所有这些项目都是在没有使用 CLA 的情况下取得成功）的重要再许可活动的历史案例，易于再许可的价值被夸大了。再许可变得困难很有好处，因为它会让项目产生稳定的法律期望，并鼓励项目在进行重大法律政策变更之前咨询其贡献者社区。在任何情况下，大多数“入站=出站”开源项目在其生命周期中从不尝试再许可，而对于少数这样做的项目来说，再许可将相对轻松，因为通常需要去联系的过去的贡献者的数量不会很大。原创追踪：有的人声称 CLA 使项目能够严格跟踪具有一定法律效益的贡献的来源。目前尚不清楚在这方面使用 CLA 所取得的成就是因为通过保留 Git 提交历史这样的非 CLA 手段无法更好地处理。DCO 似乎更适合跟踪贡献，因为它通常在每个提交的基础上使用，而 CLA 是每个贡献者签署一次，并且在行政上与代码贡献分开。此外，原创跟踪通常被描述为对公众有益，但我知道项目无法对 CLA 接受记录提供透明的…

《贡献者许可协议》是“人魔”般的怪物？
type: item
date: 2019-03-08T16:41:00+08:00
description: 非标准的开源贡献者许可协议正在创造类似电影《冲出人魔岛》中“人魔”般的怪物。当我开启作为开源律师的职业生涯时，面临的一个重要问题是需要耗时费力去分析的新形式开源许可协议的激增，正如我的同事 Scott Peterson 在其文章中所述，“开源许可协议是共享资源”：专注于少数许可协议更有好处。通过对少数许可协议达成更广泛共识所积累的经验和讨论更容易减少不确定性，而不是在成千上百的许可协议之间进行有关行动和辩论。过去多年开源社区对许可协议扩散的反应持积极态度，我很高兴看到大多数开源项目都从一组被工程师和律师熟知的许可协议（例如 GPL、LGPL、AGPL、BSD、MIT、Apache 2）中进行选择。因此，不用将时间浪费在解释许可协议条款上，完全开启了一个低摩擦的生态系统。一旦项目采用开源许可协议，它通常采用标准的“ 入站=出站 （ inbound=outbound ） ”模式，创造该短语的 Richard Fontana 将其描述为贡献者不言自明地获得出站项目适用的许可协议的许可，使得贡献者可以轻松参与项目，无需担心繁文缛节和受到威胁。这是一个非常简单的模式，能够非常聪明地进行上面提到的许可协议选择。不幸的是，许多项目不选择采用“入站=出站”模式，而是采用某种形式的《 贡献者许可协议 （ Contributor License Agreement ） 》（CLA）。CLA 的范围和目的各不相同。读者们可以在 Ben Cotton 的文章《CLA 与 DCO 有什么不同？》中具体了解《贡献者许可协议》与《 开发者原创证书 （ Developer Certificates of Origin ） 》（DCO）的区别。采用 CLA 的项目在接受贡献之前，要求贡献者提交作为个人或所在公司签署的 CLA 存档。除非是其条款能够被工程师和其代理律师很好理解的标准 CLA（例如下文提到的 Apache 软件基金会非实质性定制的 CLA），否则因为需要非常仔细阅读 CLA 以确保能够完全理解其条款，贡献者通常放弃去深究 CLA。理解非标准 CLA 的过程需要数天或上周才能完成，具体取决于工作负荷以及是否需要与许可协议提交人进行协商。根据我的经验，最终结果是回到标准的 CLA 条款！这个曲折的过程导致大量的时间和精力被浪费。此外，CLA 需要某种形式的签名，增添了许多在大型官僚组织可能更严重的延迟性和复杂性。这并不是一条令人开心的路径，对开源/协作开发模式具有高度侵蚀性。请注意，当我提到“标准 CLA”时，我所指的是基于众所周知 CLA（例如 Apache 软件基金会个人或企业 CLA）的 CLA。虽然 Apache 软件基金会的 CLA 由基金会本身以其原始形式使用，但它们通常被以非实质性方式进行修改以供其他组织使用。例如，大多数组织在开始时都小心翼翼地摆脱了许可协议的慈善使命，还定制了许可协议名称。Apache 软件基金会这类非实质性变体需要与本文中描述的类似“人魔”怪物的变体区分开。我对最近 CLA 数量的激增表示担忧，我们似乎正在经历十年前在开源许可协议扩散方面遇到的相同现象。事实上，在过去的一年里，在我的办公桌上至少看到 20 种不同的 CLA，它们与常见的 Apache 软件基金会个人或企业 CLA 存在细微但实质性的偏差。这些偏差通常小到无助于澄清条款语言或权利，但其中有些偏差会比较大，这种混合的可憎之物让我想起了 Moreau 博士通过他的活体解剖过程创造的新动物（参见维基百科上的《冲出人魔岛》）。无论偏差是小还是大，它们造成的影响可能很大，经常导致混淆、更多的审查时间以及谈判。例如，律师普遍接受的做法是对许可协议或合同中的术语使用初始定义。无意中使用同一术语的小写形式会导致是否应该使用该术语在标准/字典中定义或协议中更窄或更宽泛定义的模糊性。尽管这对于不经意的观察者来说似乎是一个微不足道的偏差，但这通常会导致许可协议接收/授予的权限显著减少或扩大，或者导致不可接受的歧义。其他偏差起草得如此之差，以至于它们的意义不明确，因此必须彻底拒绝。在最近的例子中，有一种 CLA 的专利许可语言以令人困惑的方式将术语 “衍生作品” （ derivative works ） 包括在内，偏离了 Apache 软件基金会 CLA 版本。此 CLA 授予专利许可的范围似乎过于宽泛且可能无限制，它是如此模糊，以至于我被迫拒绝使用它。我不确定这是否是这个特定 CLA 的起草人所预期的结果，但是这次审查花费了大量的时间和成本，最终限制了我们的工程师为该项目做出贡献。这是一个令人伤心的结果，没有人从中受益。作为一个社区，让我们从之前关于开源许可协议扩散的错误中吸取教训，采用“入站=出站”模式，最好使用 DCO 而不是 CLA。如果您选择使用 CLA，那么强烈…