开源项目的版权声明已无存在必要？
保留简略的版权声明即可，无需投入过多资源维护。 版权声明 （ 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）（虚假版权管理信息）提供了一些不利因素（即使仅限于不良意图）。由于价值较低且存在一定风险（如果在进行更改时出错），因此难怪没有更多资源用于维护版权声明。有些人和一些公司强调将详细的版权声明放入根据开源许可证提供的代码中。其他人则没有。随着开源项目的发展，某些贡献中可能包含版权声明，而其他贡献则没有。即使文件的内容与原始版本相比发生了很大的变化，文件也可以包含原始版权声明，而不包含其他版权声明。或者以后的贡献者可以向以前没有版权声明的文件中添加一个版权声明。那作为版权声明要素的“该作品的首次出版年份”呢？这意味着什么？不同的人有不同的做法。已更新？那其他贡献提交之后呢？至于从挖掘版权声明数据中得出结论，要谨慎。期望值不要那么高。那开源项目应该怎么做呢？请提供并维护清晰、准确的许可证信息。对于版权声明来说，很难证明为维护版权声明的详细信息而进行的投入是合理的。但是有些人可能希望会出现版权声明。至于“软件的起源”，也许仅仅参考项目本身而不是尝试捕获更细粒度的内容可能会更有用和更准确。公开年份？手动维护源文件中的麻烦程度导致其不大值得；源管理工具以较低的资源成本提供了更准确的信息。有关实用方法的更多详细信息，我建议你将注意力集中在对版权声明实践的重新思考上，可以参考 Steve Winslow 于 2020 年 1 月 10 日发布的《开源软件项目中的版权声明》。作者简介：Scott Peterson 是红帽公司（Red Hat）法律团队成员。很久以前，一位工程师就一个叫做 GPL 的奇怪文件向 Scott 征询法律建议，这个致命的问题让 Scott 走上了探索包括技术标准和开源软件在内的协同开发法律问题的纠结之路。 译者简介：薛亮，集慧智佳知识产权咨询公司互联网事业部总监，擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。
如何寻找可行之路？开源律师如是说
开源法规对成功有不同寻常的要求。一起来了解开源组织的律师如何帮助其雇主找到可行路径。正如我在这个分为两部分的系列文章的第一部分中所分享的那样，我是 红帽公司 （ Red Hat ） 的一名开源律师。我工作中的一个重要部分是向其他公司（包括其内部法律顾问）提供有关红帽公司如何采用完全开源的开发模式来构建企业级产品的信息，并回答他们有关开源许可的一般问题。在听了红帽公司的成功经验之后，这些律师与我对话的话题常常转变为其所在组织如何发展成为更具开源意识和能力的组织，他们也经常询问我如何改善他们的做法，以便更熟练地为其组织的雇员提供开源法律咨询。在这两篇文章中，我将分享我通常在这些主题上告诉内部法律顾问的那些内容。总是要找到一条可行路径我的雇主红帽公司在使用开源软件方面的独特之处在于，我们的开发模式始于具有数千名贡献者的开源社区，并产生了经受过尝试、测试和信任的最终产品。更具体地说，通过我们独特的开发模式，我们从社区创建的开源软件开始，并在每个项目的基础上加强安全性，修复错误，修补漏洞并添加新功能。然后，我们将这些改进回馈给每个项目，以便使整个开源社区受益。此方法的效用非常重要，包括：通过内部团队与组织外部其他人之间的协作来利用外部创新；当现有或潜在的社区与您在同一问题上开展工作而且能够合作时，可以避免您自己开发和维护开源解决方案的成本和效率低下的问题；通过与合作伙伴和上游项目社区的富有成效的合作，能够避免维护主项目下游分支的昂贵代价。一些公司发现创建上游代码的非公共分支很诱人，因为它是解决特定 用例 use case 的快速方法，或者因为它们不愿意在社区中进行协作。然而，由于增加的开发成本、互操作性损失和其他原因，这种分支的长期维护负担可能是令人望而却步的。相比之下，将开发集中在原始上游社区中，可以在所有参与者之间分担开发成本。除少数例外（例如红帽公司）外，大多数使用开源软件的组织可能都拥有专有软件许可模式（或与 SaaS 等效的概念），并在其业务中对专有软件进行许可。这些组织认为他们拥有可以提供某些竞争优势的软件组件，并且不希望看到这些组件在开源条款下对其他人可用。这是可以理解的。但是，我会鼓励任何咨询此类问题的开源律师来敦促其客户采用开源开发模式，尤其是对于所有无差异且通用的软件。例如，如果您的公司开发了用于手机的应用程序，并且您需要一个软件模块来读取和写入 PNG 图像文件，那么使用 GitHub 上流行的开源 PNG 软件模块之一将便宜得多。对于您的业务而言，对 PNG 图像进行编码和解码可能是无差别的，那么为什么要花费宝贵的工程时间来编写自己的版本？此外，为此功能编写自己的模块也可能会导致与使用常用开源模块的其他软件的兼容性问题。这是为什么呢？尽管您的模块和开源模块可能已被编写为对已发布的 PNG 规范进行编码和解码，但有时对规范的解释可能会有所不同，也可能会出现实施错误。使用同一模块执行此功能的每个人都可以确保大多数用户的兼容性，并降低开发和维护成本。还必须意识到，您可能需要某些软件来保持专有性，并且不受开源条款的约束。取决于您系统的软件体系架构和所使用的开源许可证，除非采取某些措施（超出本文的范围），否则打算保留专有权的软件代码可能会受到开源许可证条款的约束。在这里向客户提供一些有关许可证选择和体系架构的咨询服务将变得很有用。寻找灵活的解决方案之前主要许可专有软件的组织逐渐增加了对开源软件的使用，但审核和批准的要求可能会增长（以我的经验甚至成倍增长）。由于资源限制，这样的组织可能会陷入困境。下面介绍了一些可以采用的灵活的解决方案。授权并委托他人律师不能也不应成为看门人。那样效率低下，并且肯定会导致开发和发布时间出现瓶颈，从而产生挫败感和收入损失。相反，应将审批权限授予产品或项目管理和工程领域有能力的个人。这可以让组织有效地保持灵活性。对客户进行教育（请参阅下一节）对于成功实现这一点至关重要。我采用的一种方法是为整个工程组织提供开源培训，以便他们可以进行基本的许可模式和体系架构选择，同时为软件开发人员提供更专业的培训，以使他们能够提供更复杂的指导和决策。也要考虑在每个级别上对权限进行明确限制，包括哪些类型的问题和决定必须上报给作为他们开源律师的您。您组织的特定授权级别将取决于您团队在开源方面的经验以及对某些开源问题的敏感性。教育客户我发现培训是将您的组织迁移到更具开源意识组织的最有效工具之一。培训您的软件工程师和产品经理至关重要。让我详细说明。尽管您的软件工程师处在最前沿，并且通常可能对开源问题和软件许可非常了解，但是基于您组织的特定要求对他们进行培训仍然很重要。例如，您的公司可能只允许使用宽松的开源许可证，并且可能对其版权声明和源代码可用性有某些要求。为避免开发中出现随后必须纠正的问题（一种昂贵且耗时的实践），最好培训工程师最大程度地减少不当行为的可能性，尤其是在所有开发过程的开始时（请参阅下一节）。产品经理也必须接受培训。在许多公司中，产品经理负责营销的经典四个环节（产品、价格、定位和促销），并负责产品从生到死的整个生命周期。产品经理工作的方方面面可能会受到使用开源软件的影响。出于上述相同的原因，了解使用开源软件的要求对他们很有用。此外，更重要的是，产品经理在组织中的重要影响，意味着他们通常能够对流程和政策进行必要的更改。产品经理可能会成为您针对“开放”进行流程变更的最强有力的拥护者之一。早期发现在开发过程快要结束时解决开源许可问题非常困难且成本很高。随着软件的发布日期临近，体系架构和开源软件模块都是已经选定且难以更改了。如果检测到问题，例如专有软件模块中嵌入的“左版”（copyleft）软件（当该专有模块无意受开源条款约束时），则在该开发阶段修改体系架构或模块可能非常困难且成本昂贵。相反，应该在开发过程中尽早进行架构分析和开源模块选择的过程，以便可以进行成本更低且更有效的更正。开源法规的“奖励”实践开源法规是一项有益的职业，因为它具有影响组织朝着“开放”方向发展的能力，这具有很大的好处。是否成功取决于您随着组织的成长和成熟而找到具备可行性和灵活性的解决方案的能力。作者简介：Jeffrey R. Kaufman 是全球领先的开源软件解决方案供应商 红帽公司 （ Red Hat ） 开源法务团队的资深商务法律顾问，还担任 北卡罗来纳大学 （ University of North Carolina ） 的兼职法律教授。在任职红帽公司之前，Jeffrey 曾担任 高通公司 （ Qualcomm ） 的专利和开源法律顾问。 译者简介：薛亮，集慧智佳知识产权咨询公司互联网事业部总监，擅长专利分析、专利布局、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。
关系造就成功——律师护航开源的三种方式
开源法规之所以独特，是因为它对成功的要求比较特殊。一起来了解开源组织的律师如何帮助其雇主达成目标。我是 红帽公司 （ 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、融洽你作为开源律师的成功通常是与软件开发人员建立积极关系的直接结果。在许多情况下，你的软件开发人员是你的法律建议的直接或间接接受者，他们将寻求你的指导和咨询。不幸的是，许多软件开发人员对律师持怀疑态度，并经常将律师视为其开发和发布软件能力的障碍。克服这种弊端的最好方法是与客户建立融洽的关系。对于大多数人来说，操作方式有所不同，但是这里有一些建议。对客户的工作表现出兴趣：对他们项目的细节、项目的工作方式、底层的编程语言、它如何与其他系统连接以及如何使公司受益感到好奇。在确定法律风险和减轻风险的方法时，其中一些答案将在你的法律分析中很有用，但是更重要的是，这为与客户保持积极的关系打下了坚实的基础。让你的客户清楚，你正在努力寻找通向“YES”的途径：让你的客户知道你对他们项目的某些方面感到担忧，但随后提出减轻这些担忧的想法。向他们保证，与他们一起找到解决方案，而不是成为障碍。但是这里面不能夸大其词。参与一个开源项目：如果你具有软件开发经验，则尤其应当如此。即使你没有这样的经验，也可以通过多种方式参与，例如帮助编制文档或进行社区拓展。或仅仅是为了更多地了解他们的工作，要求参加他们的进度会议。这也让你可以按需实时提供顾问服务，以便团队可以在此过程的早期进行纠正。2、信任你的软件开发人员在其开源社区中非常活跃，并且是了解当前影响开源软件和开发问题的最佳资源。当你与当地的律师协会或国家层面的法律组织等保持联系，以了解最新法律进展时，你还应该与各种软件开发资源进行定期沟通，并就各种事项征求他们的意见（例如，对于此许可协议应用于某项目，社区的观点是什么？）。四、关系造就成功开源法规之所以独特，是因为其对成功的不寻常要求，其成功即是与其他开源律师、开源组织的联系以及与客户的深厚和互相尊重的关系。成功是这些关系的直接成果。在本系列的第二部分中，我将探讨为什么给你的组织找到“开放”之路并开发可扩展的解决方案是如此重要，并告诉你如何去做。作者简介：Jeffrey R. Kaufman 是全球领先的开源软件解决方案供应商 红帽公司 （ Red Hat ） 开源法务团队的资深商务法律顾问，还担任 北卡罗来纳大学 （ University of North Carolina ） 的兼职法律教授。在任职红帽公司之前，Jeffrey 曾担任 高通公司 （ Qualcomm ） 的专利和开源法律顾问。译者简介：薛亮，集慧智佳知识产权咨询公司互联网事业部总监，擅长专利分析、专利布局、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。
源码被倒卖，大厂薅羊毛，开源真的只能被予取予求？
今天看到一篇文章《开源项目在闲鱼、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的感觉；想借助大众或社区的力量优化自己的软件，获得免费劳动力；想借助开源扩大自己影响力（自我营销），却没考虑为此要付出的代价；看到其他人利用自己的开源软件获利，心理上有些许不平衡。类型二：批判开源软件收费、许可证不人性，批判严格型许可证的传染性像病毒、吸血鬼、耍流氓，对别人行使著作权或协议约定的行为愤愤不平。这一类人，基本是拿来主义者，同样站在自己的立场上看待开源软件的开发者（仁慈的开发者、邪恶的开发者）。该类“事故”的原因有：就是想白 piao 而已，因为你完全有选择用与不用的权力。这两类“事故”的产生都源于没能深入理解开源运动的精髓和要义，纯粹的从利己主义出发思考问题，没有做到换位思考。忽略了开源的初衷：奉献和共享。现实中，经常发生这样的事情：对同一个人，作为开源的使用者时他们常常讨厌 GPL 许可证，因为限制太多；作为开源软件开发者时又喜欢 GPL 的安全感，讨厌 MIT、BSD 等许可证让自己被白 piao 了却投诉无门。开发者和使用者的权利义务开源软件首先是开发者的劳动成果，是拥有著作权的。开源一定意义上就是奉献，每一个开源软件使用者都是开源的受益者。面对这种奉献，你需要做的就是尊重。但开源的使用者并不必然要求是高尚的、无私的，这种尊重基于开发者选择的开源许可证在合规的前提下行使权利，在尊重权利人的同时实现共赢和自身利益最大化。而作为开源软件的开发者，也不必然要求是高尚的、无私的，开发者可以基于自己的目的来选择适当的开源协议。选择开源，就要审视自己内心深处的想法，开源的动机和目的是什么？后果是什么？……慎重的思考了这些问题后，还需要清楚的知道选择宽松型的许可证可能要面对的各种问题。开源使用者是纯粹的受益者，即便是抱怨无非是对严格型许可证发发牢骚而已。而开源的开发者往往显得更值得同情，一般是从道义上（如案例 3）以及经济利益上（如案例 1、2）体现。但这就是开源运动运行的机制，它肯定不完美，但被证明是行之有效的。针对开源开发者，你需要做的就是当别人违法的时候拿起法律的武器捍卫自己的权利，当别人没有违法的时候，你心里再不爽也要保持淡定。当然，诸如前述案例让人糟心的事情肯定很多，开发者也不是束手无策：比如案例 1 中新蜂商城的作者，选择了 MIT 这个非常宽松的许可证。就意味着，其他人几乎可以拿来做任何事情，包括卖钱。但你依然有以下权利：不准拿你的大名做推广，或者类似名字这种具有身份意义、独特标识作用的符号；如果作品真的好且有市场，作者完全可以自己经营，将自己的品牌做大；别人卖的了你的源码卖不了你的实力，你可以不断迭代升级，源码和服务提供一站式解决方案。其实，现实中我们熟悉的开源软件大都如此，比如 Android、Linux 等；乐见其成，毕竟开源就是奉献自己的劳动成果让人使用，二手贩子们所做的事与开源者的目标是一致的。当然如果贩子们声称是自主源码云云（国内拿开源的东西声称自主开发的太多了），那必然是违法的，开源者可以大胆的拿起法律的武器。主动开源，你真的准备好了吗？基于国内的现实状况，笔者以往更多的是将精力放在帮助企业和开发者合规的使用和利用开源。因为我们曾经都是开源的受益者，需要基于合法、合规的前提汲取营养、学习知识。目前，国内越来越多企业或个人开始思考反哺开源社区，这是非常好的开始，说明我们从受益者开始变为奉献者。但现实中这些才华横溢的开发者在开源中难免遇到案例中的问题，一旦遇到将严重挫伤其开源的积极性。因此，开源开发者在主动开源之前，更需要深刻理解开源，明确自己开源的目的以及可能面对的潜在问题等。在慎重思考自己开源的目的和对开源后各种问题的考量后，选择适合自己的许可证。以下是几个典型的开源动机面临的潜在风险：想借助大众或社区的力量优化自己的软件，获得免费劳动力 开源软件千千万，真正取得成功或大众认可的软件凤毛麟角，不能说这种目的动机不纯，至少实现的可能性甚微。更多的可能是根本没有人看得上你的项目。想借助开源扩大自己影响力（自我营销） 这可能是开源开发者，包括大企业做开源的一个非常重要的目的。具体能否实现，就看你的水平有多高，实力是否匹配自己的梦想。基于自己牛逼的软件，打造生态。 这也是大部分企业的终极梦想，就像第一条所述，大部分的开源软件都归于路人甲，能否实现自己的生态梦取决于你的软件到底如何，能否支撑一个生态、够吸引外围群落。 即便这些都满足了，还要思考一点，你自己的实力能否持续主导这个生态的发展。因为，开源社区的主导力是由实力说话的，如果你无法保持持续的创造力，别人fork一下就可能成为新的盟主而把你晾在一边坐冷板凳。Google 的 Android 生态就是道理，Google 对 Android 生态的领导力是建立在其持续的创造力之上的。Just for fun 最纯粹的开源。如果你开源软件的目的很单纯，就是因为喜欢而开源。那单纯的你需要知道不同开源许可证开源的后果。若别人拿你的开源软件去卖钱你也不要太上头，因为这是允许的，当然更不能看到别人赚了一大笔钱心里就不平衡了。就像大把的企业靠着 林纳斯·本纳第克特·托瓦兹 （ Linus Benedict Torvalds ） Just for fun 的软件 Linux 和 Git 赚了大笔的钱，你能做的就是乐见其成。开源不仅仅是代码，更是人品和实力，也是策略和格局。希望每一个奉献和使用开源的你，都能感受到这个世界的善意。以上是基于本次热点，针对使用开源以及主动开源分享的点滴思考和建议。有兴趣可以找我讨论沟通。付钦伟，集慧智佳高级咨询师、专利代理人，擅长专利分析布局、FTO调查与风险应对、专利信息应用、开源软件风险与合规指导。
共享、免费还是公有？开源软件的真正定义
如果你认为开源软件是共享软件、免费软件和公有领域软件的代名词，那么你并不是唯一有这种看法的人。当你听到“ 开源软件 （ open source ） ”一词时，你是否认为它与诸如 共享软件 （ shareware ） 、 免费软件 （ freeware ） 或 公有领域软件 （ public domain ） 之类的术语同义？ 如果是这样的话，你并不是唯一有这种看法的人。在软件行业内外的许多人都认为这些术语是一样的。本文说明了这些术语的不同之处，认为开源是一种变革性的许可和开发模式。分享我与以上几种软件打交道的经验，可能是探究差异的最佳方法。共享软件和免费软件早在 1982 年，当我在 Apple II Plus 上用 BASIC 编写代码时，我就开始从事计算机程序员的工作。我回想起去家乡当地的计算机商店，并在塑料袋中找到看起来价格高昂的装有游戏和实用程序软件的软盘。请记住，这是从一个中学生的角度来看的。但是，有一些软件可以免费或以最低价格获得。依据具体许可模式，它被称为共享软件或免费软件。在共享软件模式下，你只能在一定时间内使用该软件，如果你发现它有用，则要求你将支票寄给该软件的作者。但是，某些共享软件实际上也鼓励你复制并提供给你的朋友。这种模式通常称为免费软件。也就是说，共享软件和免费软件确切定义之间的差异十分微小，因此很容易将两者简单地统称为“共享软件”。我虽不能肯定，但是我不记得我是否向任何软件作者提供过使用共享软件的费用，主要是因为我在十几岁的时候就没有钱，但是我肯定喜欢使用这些软件程序，并且从中学到了很多有关计算机的知识。回顾过去，我现在意识到，如果该软件是根据开源许可条款而非共享软件条款提供的，那么作为一名新兴的程序员，我本可以在成长中学到很多东西，并且可以取得更多成就。这是因为几乎没有共享软件会提供源代码（即，人类可读的软件形式）。共享软件还包含许可限制，禁止接收者试图泄露其源代码。如果无法访问源代码，则很难了解该软件的实际工作方式，从而很难扩展或更改其功能。这使得最终用户完全依赖共享软件原始作者进行任何更改或改进。使用共享软件模式，任何开发人员社区几乎都不可能对代码施加影响，并进一步围绕代码进行创新。再分发和商业使用也可能受到进一步的限制。尽管共享软件可能在价格方面是免费的（至少在最初是免费的），但它在自由权利方面并不是免费的，并且不允许你通过探索代码的内部原理来学习和创新。这就引出了一个大问题：它与开源软件有何不同？开源许可的基础首先，我们需要了解“开源”是指许可模式和软件开发模式，两者与共享软件都有很大不同。在一种称为非 “左版” （ copyleft ） 开源许可的开源形式下，向用户提供了关键的自由权利，例如对访问源代码没有限制；可以出于任何目的出售、使用或赠送该软件；可以修改软件。这种形式的许可也不需要支付任何使用费或许可费。因为许可是高度宽松的，不需要谈判就可以使用，这种许可模式的一个惊人结果是它具有独特的能力，可以使无数软件开发人员协作起来对代码进行新的、有用的更改和创新。尽管从技术上讲，在这种许可模式下不需要提供源代码，但是几乎所有人都可以使用它来查看、学习、修改和分发给他人。非“左版”开源许可的另一个方面是，此类软件的任何接收者都可以添加其他许可限制。这意味着以这种许可形式对代码进行许可的初始作者，无法阻止接收者可能依据限制性更强的条款不再进一步许可给其他人。例如：假设作者 Noah 编写了一些软件，并根据非“左版”开源许可将其分发给了接收者 Aviva。然后，Aviva 修改并改进了 Noah 的软件，她有权根据非“左版”开源许可条款使用该软件。然后，Aviva 可以决定对可能限制该软件使用的任何接收者施加进一步的限制，例如在何处或如何使用它（例如，Aviva 可以增加一项限制，规定该软件只能在以下地区使用：加利福尼亚，并且不允许在任何核电厂中使用）。 即使 Aviva 可以访问源代码，也可以选择永远不将修改后的源代码发布给他人。不幸的是，有无数的专有软件公司以上述方式使用非“左版”开源许可软件。实际上，共享软件程序可以通过添加共享软件类型限制（例如，无法访问源代码或排除商业用途）来使用非“左版”开源许可软件，从而将非“左版”开源许可代码转换为共享软件许可模式。幸运的是，许多使用非“左版”开源许可软件的专有软件公司都看到了发布源代码的好处。这些组织一般通过诸如 GitHub 之类的软件存储平台向其接收者或更广泛的开源社区提供修改后的源代码，从而继续保持开源模式的持久性，实现创新的良性循环。这并不是完全出于慈善目的（或者至少通常不是这样）：这些公司希望鼓励社区创新和进一步改进，从而使他们也一并受益。同时，许多专有软件公司不选择这样做，这也完全符合非“左版”开源许可证条款的规定。“左版”许可的开源软件1989 年，一种新的被称为 GNU 通用公共许可证（也称为 GPL 许可证）的开源许可证被开发出来，其目的是确保软件“生来自由”（如同言论自由），并且能始终保持这种自由，这与非“左版”开源许可软件有时会发生的情况不同。作为版权法的独特适用，只要遵守这些规则（稍后会再介绍），GPL 许可证能够确保持续的软件自由。版权的这种独特适用称为 “左版” （ copyleft ） 。与非“左版”开源软件一样，“左版”许可证允许接收者不受限制地使用该软件、检查源代码、修改软件，以及将原始或经修改的软件进一步分发给其他接收者。与非“左版”开源许可证不同，“左版”开源许可证要求所有接收者必须也具有这些相同的自由权利。除非不遵守规则，否则这些自由权利决不能被收回。使“左版”开源许可证能够强制执行，并促使人们遵守法规的原因是版权法的适用。如果“左版”代码的接收者不遵守许可条款（例如，对软件使用添加任何其他限制或不提供源代码），则其许可将被终止，并且由于他不再享有使用该软件的法律许可，他将成为版权侵犯者。因此，该“左版”许可软件任何下游接收者的自由权利得以保障。超越基础：其他软件许可模式我在前面提到了公有领域软件，尽管它通常与开源软件混为一谈，但是这种模式有所不同。公有领域软件是指已采取步骤查看后获知没有与该软件相对应的版权存在，最常见的情况是软件版权到期或被作者放弃。（在许多国家/地区，版权保护机制尚不明确，这就是为什么某些公有领域软件可能选择开源许可模式作为备选方案的原因。）使用公有领域软件无需许可证。尽管如果源代码可获取的话，许多人会认为公有领域软件是开源软件的一种形式，但无需许可证是否让公有领域软件成为“开源软件”，是存在很多争论的主题。有趣的是，有许多开源项目利用公有领域软件的小模块来实现某些功能。甚至还有声称整个程序属于公有领域的软件，例如实现了 SQL 数据库引擎并在许多应用程序和设备中使用的 SQLite。没有许可条款的软件也是很常见的。许多人错误地认为这种未经许可的软件是开源软件，属于公有领域，或者不受限制地免费使用。在大多数国家（包括美国），软件的版权在其创建时就已存在。这意味着不以许可证的形式许可就不能使用它，除非它以某种方式放弃版权，并将其放置在公有领域。此通用规则存在一些例外情况，例如法律层面的默示许可或合理使用。但是在如何将它们应用于特定状况方面，情况非常复杂。在意图让其遵守开源许可条款的情况下，我不建议提供没有许可条款的软件，因为这会导致混乱和潜在的滥用。开源软件的好处就像我之前说的那样，开源是高效的软件开发模式，并具有推动创新的巨大能力。但这到底意味着什么？开源许可模式的好处之一是大大减少了创新方面的摩擦，尤其是原始作者以外的其他用户所进行的创新。这种摩擦是有限的，因为使用开源软件通常不需要协商许可条款，从而大大简化并降低了使用成本。反过来，这创建了一种开源生态系统，它鼓励快速修改和组合现有技术以形成新的事物。这些修改通常能回馈到开源生态系统中，从而构造了一个创新循环。驱动大量事物（从你的烤面包机到火星飞行器）运转的无数种软件，正是这种轻松地将各种程序组合在一起的能力的直接结果——开源开发模式让所有这些软件得以成为现实。作者简介：Jeffrey R. Kaufman 是全球领先的开源软件解决方案供应商 红帽公司 （ Red Hat ） 开源法务团队的资深商务法律顾问，还担任 北卡罗来纳大学 （ University of North Carolina ） 的兼职法律教授。在任职红帽公司之前，Jeffrey曾担任 高通公司 （ Qualcomm ） 的专利和开源法律顾问。译者简介：薛亮，集慧智佳知识产权咨询公司互联网事业部总监，擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。
对于让开源软件变得如此出色的协作开发来说，开源软件许可以其不同于常规软件许可的方式提供了诸多支持。人们在使用常规软件许可时产生的实践和期望，也许会让他们在面对开源软件时感到沮丧。“请给我看下许可证”这种简单的要求，可能得不到令人满意的答复。尽管有的时候这种答复非常简单，但开源软件的许可信息通常更为复杂，达不到常规软件许可所设定的那种期望。这是怎么回事儿呢？开源软件许可是否出毛病了？然而并没有。许可条款类型以及软件开发方式的差异，都会导致软件许可信息的传送方式不同。律师便利性和开发人员便利性之间的折衷是造成这种状况的部分原因。如果只是说开源软件可以“协作”开发，那还没有弄清楚开源开发活动与常规许可软件之间可能存在的差别程度。尽管有像常规许可软件一样由一个人或一个固定的小团体来维护的开源项目，但是在开源项目上的协作可能会在广泛的潜在贡献者之间进行。例如，根据 GitHub 的“2019 年 Octoverse 报告” ，有超过 35 万人对前 1000 个项目做出了贡献。但是，开源软件开发与常规许可软件开发的不同之处不仅仅是贡献者数量。除了被发现对该开源项目拥有某些共同兴趣，为开源项目做出贡献的人们之间可能没有任何联系。人们的参与情况可能会随着时间的推移而变化。原始开发人员可能会离开，留下其他人继续进行项目开发。所有这一切都可能在没有规划或总体治理组织的情况下发生。除了遵循规范性的治理规则，开源协作活动还是轻量级的，而且可以比常规许可软件更加灵敏地响应。有关开源许可信息的实践与这种协作开发方式相适应。针对二进制文件以及源代码，开源许可中的条款通过提供所需的权限（包括复制、修改和分发）促进了协作开发。事实证明， “开源定义” （ Open Source Definition ） （OSD）有助于将注意力集中在满足其要求的许可上。开源软件的许可信息嵌入在源代码中。当获得源代码时，就会接收到相应的许可信息。想象一下每年以百万计的贡献规模，单独的许可管理是否完全可行呢？同样，通过将许可信息嵌入源代码中，可以反映与许可相关的详细信息，而这些细节在某些单独管理的许可流程中不可行。例如，将许可信息嵌入源代码，使得指示哪些许可条款适用于软件的哪些部分变得切实可行。为了说明开源许可实践所能实现的效果，请考虑以下示例性软件项目：该项目始于 5 年前；到目前为止，已有 50 位贡献者做出了贡献；通过改编其他项目中的部分软件，增加了一些功能；原始代码的开发者在三年后离开；几家商业企业已经在其内部或一部分产品中依赖该软件；如果考虑到其他软件和计算机世界方面相关的变化，则该软件未来可能还会有 5-10 年的发展。在开源项目中现有和常用的表示许可信息的方法，很容易适应这样一个项目的过程。没有预先规划，贡献者可以从项目中来来去去；项目的各个部分遵循不同的许可条款；如果与其他公司的合作破裂，商业企业可以继续以很少的管理开销成本分担软件维护工作，同时保持完全独立开发其软件分支的能力。相反，传统的软件许可方法将如何支持这种开发呢？甚至这样的合作有可能发生吗？我们是否将拥有一个完整的许可基础结构来跟踪数千个“主软件开发和分发协议”的适用性？我们是否要通过让某些公司控制一切来简化许可？让我们回到“是什么许可？”这个问题。我谈论开源开发特征的目的，是说明存在重要的影响开源许可信息如何表示的非法律因素。开源软件中许可信息的表示形式通常不符合常规软件许可的期望。但是，存在差异并不代表系统出毛病了。相反，对于支持过去二十年中已被证明有效的大规模协作开发这种软件构建方法来说，差异的作用非常强大。开源许可信息是什么样的呢？通常，人们会考虑每个“软件组件”的许可条款。软件组件可能作为应用程序对用户可见，或者对于用户来说可能不那么明显，例如与大型程序结合使用时可提供某些功能的库。对于许多软件组件而言，许可很简单：组件中的所有软件适用数十种最常见的开源许可证中的一种。除了最常见的许可证之外，还有很多文本有所变动的不经常使用的许可证。但是，在“开源定义”的指导下，开源许可条款中的权限和限制仍保持在一定范围内。如果要进行将开源软件集成到其他软件中的软件开发，那么你需要了解适用于所集成软件的所有 “左版” （ Copyleft ） 条款（例如著名的 GPL 系列许可证）。由于从我对开源软件开发方式的讨论中揭示的显而易见的原因，许可信息可能比单个许可证更为复杂。尽管一个软件组件可能有一个主要的“项目许可”，但可能有一部分软件遵循其他许可证。这可能会导致在源代码的各个部分中出现不同的许可声明。一些项目的做法是在每个源文件中放置版权声明。其他项目主要依靠放置包含许可文本的一个或多个文件。版权声明指示谁可能是该软件部分的版权拥有者（但是，鉴于版权声明实践的多样性，该指示的作用可能微不足道）。用来构建软件组件的源代码可以包括未反映在所得组件中的软件，例如与测试或构建相关的文件。这对于使用无 GPL 规则（项目中可能包含遵循 GPL 许可证的文件，但用于生成可执行程序的文件不得包含遵循GPL许可证的文件）的人可能很重要。因为许多细节都与某些许可信息涉及的软件部分有关，这种细粒度的许可信息在源代码中最有效地进行了传达。在最详细的级别上，源代码即许可证。当许可信息在源代码中时，可以用与源代码相同的方式（例如在版本控制系统中）来维护该许可信息，并且该信息固有地可用于获得源代码的任何人。从源代码中提取许可信息并创建许可条款概要似乎很简单。但是，对于一个人或一个公司来说足够了的摘要，可能对于另一个人或公司是不足的。不同的人可能关注不同的许可信息细节。一些人可能想确切地知道该软件的哪些组件遵循“左版”条款。其他人可能并不关心所有组件的许可条款概要。还有的人可能需要包括每个不同的版权声明在内的所有许可声明。你想查看哪些许可信息的细节呢？在软件开发中有大量的工具可以使用。扫描、提取和报告现有许可信息的工具是持续开发的活跃主题。现在，“是什么许可？”可能会改写为“向我显示许可信息报告”，该报告可能包括一系列程度不同的详细信息，具体取决于对请求报告的人的重要性。在最详细的级别上，源代码即许可证。因为软件可以采用不同的方式构建出来，常规软件许可和开源软件许可分别适用于不同的领域。两者之间可能存在差异，对于这一点要做好准备。作者简介：Scott Peterson 是红帽公司法律团队成员。很久以前，一位工程师就一个叫做 GPL 的奇怪文件向 Scott 征询法律建议，这个致命的问题让 Scott 走上了探索包括技术标准和开源软件在内的协同开发法律问题的纠结之路。译者简介：薛亮，集慧智佳知识产权咨询公司互联网事业部总监，擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。
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 Program or a work based on the Program.——GPL 2.0结合 GPL 协议条款和 GNU 官网对于 GPL 传染性的解释，一审法院这一认定是值得商榷的，就像你不能认为总部在西城的 A 公司与其在昌平拥有独立办公场所的分公司 B 是完全独立的，这需要从 A 和 B 之间的财务、人事、业务等是否独立为基础判断。同理，GPL 模块 A 与模块 B 之间是否独立，绝对不能以A和B是否位于独立的文件夹中来判断，还是需要从 A 和 B 之间的功能关系、通信关系、调用关系、依赖关系等来判断。插件相对于主程序是否独立，需要看：插件的使命，是否为该主程序而存在；插件与主程序的交互方式，如管道、队列、函数调用； 交换消息的密切性 （ intimate communication ） ；是否有例外声明等。一审法院在确定赔偿额的时候又一次指出三个涉案插件是三个独立软件作品。一审法院从审判认定到赔偿衡量是一致的。这里，两柚子并没有就涉案三个插件的独立性进行抗辩，而这一点对 GPL 是否构成传染非常关键，在一审中被告代理律师对 GPL 许可证条款的理解也存在局限。关于二审认定的思考首先，二审中两柚子再次提出司法鉴定来否定涉案三个插件独立性，可能是准备利用GPL传染性中关于独立作品的认定来抗辩。不过，法院认为二审诉讼中再次提出第三次鉴定申请，有违司法程序公正和司法程序效率，即二审法院基于程序公正的角度考量不予准许。同时，二审法院认为两柚子提出的新的司法鉴定申请内容与本案待证事实之间无直接关联性，这一点是值得商榷的，因为 GPL 中作品是否独立直接影响作品是否受GPL约束，进而直接影响本案关于侵权的认定。二审法院的否决理由，直接回避了可能对 GPL 传染性问题的讨论。其次，二审法院认定数字天堂现有证据不足以证明涉案三个插件可以独立于 HBuilder 开发工具软件中的其他程序独立运行，但针对不独立的插件却没有进一步讨论这种不独立是否能够进行 GPL 开源抗辩。也就是说，一审法院基于作品的独立认定 GPL 抗辩无效，二审法院采取了一审对 GPL 抗辩的意见，但却否定了作品的独立性这一前提。是否为独立作品的认定直接决定作品是否属于 衍生作品 （ derivative work ） 或 修改作品 （ modified version ） ，进而直接影响是否受 GPL 约束。当然，我们可以这样解读二审法院对于作品独立的认定，即 GPL 许可证里所说的作品的独立性，和一审、二审法院判决赔偿额对插件独立的认定是不同维度/层次，这是说的通的。但仔细阅读一审判决可知，法院在否决 GPL 抗辩中和赔偿额判定中对独立的认定是一致的，二审认可了一审对 GPL 抗辩部分的认定，却否决了赔偿额中对独立作品的认定，本身前后有矛盾嫌疑。笔者认为，如果按照上述：GPL 传染性中独立性判定和对侵权作品数量中独立性判定是不同维度的独立性判定的假设，至少二审中需要重新认定 GPL 传染性的问题，从而将两个维度的独立性认定区分开来。关于两柚子诉求理由的思考两柚子在二审中再次申请司法鉴定：涉案三个插件是否可以脱离 Eclipse 主体软件在 Windows 环境中独立运行；将涉案三个插件源代码编译为插件以验证插件能否在 Eclipse 主体软件中独立运行；任意删除 Hbuilder 软件目录下的一个或多个以“org．eclipse”、“org．apache”、“com．aptana”为前缀的文件或目录 JAR 文件以验证涉案三个插件能否正常运行……关于这三个补充鉴定事项，首先，笔者认为两柚子或者其律师在开源上做足了工作，但其中依然存在问题。首先，插件独立于 Eclipse 主程序，并不一定需要插件可以脱离 Eclipse 主程序在 Windows 中独立运行。插件的独立性在于：插件有明确的功能，可用于特定的主程序，但不依赖于特定的主程序。最后，主程序脱离插件，应当且必须可以独立运行，并且不损失主程序本身的所有功能。再看诉讼本身基于以上认识，我们再回头看看案件本身。首先说明，因本案需要进行多处技术鉴定，笔者无法也没有精力一一取证，仅仅基于几个假设，再捋一下 GPL 相关的问题。笔者认为，关于本案 GPL 传染性的认定需要从 3 个方面来看：Eclipse 主程本身；基于 Eclipse 主程序的 GPL 插件；涉案插件与主程序，以及涉案插件与上述 GPL 插件的关系。为方便读者理解，引用数字天堂代理律所对一审结果评述的一张图。（1）从 Eclipse 主程序看APICloud 和 HBuilder 都是基于主程序 Eclipse 平台，包含第三方开源插件+各自自研插件组成的集成开发环境 IDE。首先，主程序 Eclipse 是采用 EPL（Eclipse Public License）许可证公开，EPL 与 GPL 不兼容。即便是 2017 年 8 月发布的 EPL-2.0 版本虽然添加了次级许可证选项，但其与 GPL 依然是不兼容的。因此，HBuilder 作为下游产品，其对 Eclipse 的包装分发不能变更 Eclipse 许可证。其次，针对插件来说，无非是拓展 Eclipse 某一特定的功能，任何非 Eclipse 本身的第三方插件，可以说对于 Eclipse 主程序来说都是非必须的。其第三方公司开发的 Eclipse 主程序的插件，按照 EPL 传染性的规定，一般不视为 EPL 的衍生作品，不受 EPL 约束。最后，需要强调的是 EPL 虽然是弱 Copyleft 许可证，但其依然是类似于 GPL 的具有“传染性”的许可证，其在给予用户更大使用方便的同时，对自身软件的 Copyleft 保护依然很强。因此，下游软件开发者在处理 EPL 软件和 GPL 软件时，需要认真对待它们的兼容性问题。（2）从 Aptana 插件看Aptana 在 2006 年推出时，以 EPL 1.0 发布，并于 2017 年 9 月 21 日修改为 GPL3.0 和 APL（Aptana Public License ）双许可。APL 不是开源/自由软件许可证，可以认为是商业许可，但对于非分发的内部使用是免费的。Aptana 作为主程序 Eclipse 的插件，由于 EPL 和 GPL 不兼容，Aptana 中的 GPL 插件要和以 EPL 许可的 Eclipse 主程序连接，必须在 GPL 许可证里作例外声明。毫无疑问，笔者在 Aptana 官网找到了例外声明，即关于独立作品的 GPL 传染性例外声明，以及聚合程序的 GPL 传染性例外声明。部分内容如下：GPL Section 7 Exception……which are conveyed to you by Appcelerator, Inc. and licensed under one or more of the licenses identified in the Excepted License List below (each an "Excepted License"), as long as:you obey the GPL in all respects for the Program and the modified version, except for Excepted Works which are identifiable sections of the modified version, which are not derived from the Program, and which can reasonably be considered independent and separate works in themselves,all Excepted Works which are identifiable sections of the modified version, which are not derived from the Program, and which can reasonably be considered independent and separate works in themselves,are distributed subject to the Excepted License under which they were originally licensed, andare not themselves modified from the form in which they are conveyed to you by Appcelerator, andthe object code or executable form of those sections are accompanied by the complete corresponding machine-readable source code for those sections, on the same medium as the corresponding object code or executable forms of those sections, and are licensed under the applicable Excepted License as the corresponding object code or executable forms of those sections, andany works which are aggregated with the Program, or with a modified version on a volume of a storage or distribution medium in accordance with the GPL, are aggregates (as defined in Section 5 of the GPL) which can reasonably be considered independent and separate works in themselves and which are not modified versions of either the Program, a modified version, or an Excepted Work.If the above conditions are not met, then the Program may only be copied, modified, distributed or used under the terms and conditions of the GPL or another valid licensing option from Appcelerator, Inc. Terms used but not defined in the foregoing paragraph have the meanings given in the GPL从以上 GPL 例外中可以看出，Aptana 只是部分限定了“衍生作品”解释，也就是运行采用 GPL 许可证的 Aptana 与像 Eclipse 这样独立的程序交互不会发生传染，仅此而已。而如果修改 Aptana，将其他程序并入 Aptana Studio，或者将 Aptana 与其他程序进行整合的作品依然受到 GPL 协议约束。简单的说，加入 GPL 例外的 GPL 程序依然是 GPL 程序，这一点必须强调。关于这一点，Aptana 官网还专门有问题解答：Can I add EPL'd plugins to Aptana Studio package and redistribute it?No. You can only redistribute the unmodified binary versions of the EPL'd plugins that are part of Aptana Studio when distributing any of the GPL'd code. Adding any files to Aptana Studio package creates a derivative work, and since all derivative works need to be made GPL'd, you will not be able to add EPL'd (or any other license) plugins without contacting us for a commercial license.What if I want to make changes to some of Aptana Studio's EPL'd plugins?You are free to make changes to any of Aptana Studio EPL'd code under the terms of the EPL. To get those redistributed as part of Aptana Studio, we encourage you to contribute those back to Aptana so that we may evaluate your changes for inclusion back into the product.Can I take unmodified Aptana Studio binaries and combine them with an Eclipse distribution?No. Combining our GPL'd licensed code with any other product requires that the entire product be GPL'd, and therefore you cannot include any Eclipse distribution.数字天堂认为，其 HBuilder 是包含 Eclipse 平台框架和众多插件的聚合体软件包，但其基于 Eclipse 开发且打包了 Aptana 中的 GPL 插件。从 GPL 协议对独立程序和聚合程序的规定来看，HBuilder 不被感染很难成立。一旦这种潜在传染可能性成立，数字天堂的 HBuilder 发行版就不满足合规性，其内部 EPL 和 GPL 软件不兼容。直白的说，就是整个发行版都可能受到 GPL 的约束。同时，这对于 Eclipse 是不可接受的，哪怕 EPL 是弱 Copyleft 许可证。这些问题，多是对 EPL 和 GPL 的 Copyleft 性质认识不到位导致。（3）涉案插件与主程序及 Aptana 插件的关系其实，以上两步分析一旦得出受 GPL 约束的结论，就不需要下面的分析了。为了完整，同时供未来类似案例参考，简单介绍。进一步分析 Aptana 与数字天堂的涉案三个插件之间的关系，若涉案三个插件与 Aptana 有调用、通信、依赖关系，那么涉案三个插件必然会被 GPL 传染，也即是受 GPL 约束。从以上三步的分析可见，在 GPL 传染性判断时，是否为独立作品是非常关键的。这也是我在前面法院判决部分要强调一审法院对独立的认定虽未必符合 GPL 本身解释，但至少前后一致。而二审法院对作品独立的认定甚至前后矛盾。当然，笔者没太多精力去调查技术细节，点到为止，有兴趣的读者可以进行深入研究。以上分析，是基于 Eclipse 作为中立主程序（即 Eclipse 主程序著作权人非诉讼参与人），GPL 插件与非 GPL 插件判定的情况，换一种场景以上判断完全或者大部分不成立。关于开源软件和 GPL 的问题还有很多需要注意的，限于篇幅不再进一步说明，对本案或对开源感兴趣的朋友可以找我单独讨论。 付钦伟，集慧智佳高级咨询师、专利代理人，擅长专利分析布局、FTO 调查与风险应对、专利信息应用、开源软件风险与合规指导。
开源与标准：为什么对待专利如此不同？
两者之间的差异对我们如何构建软件开发过程产生了影响。制定标准规范和开源软件的开发有许多共同之处：两者都是竞争者可以合作的机制；两者都可以促进互操作性；两者都可用于促进新技术的采用；两者都可用于聚合或协调成熟技术。一项技术可以同时使用标准和开源：有时一个先于另一个；在其他情况下，它们可以并行进行。它们越来越多地使用类似的工具和流程实践（例如，细粒度版本控制；利用问题跟踪器一起推动某些开发讨论）。相似程度可能导致过度概括，错误地暗示一切都是可互换的（混合与搭配），在这儿选择一种做法；在那儿将它与一个过程相结合。实际上，获取在一个领域中获得的经验并查看它提供的好处是否可以在其他环境中获得，可能是有价值的。但是，对于某些实践而言，背景更为重要。虽然有相似之处，但也存在显著差异。在前面的文章《没有规则的治理：复刻潜力如何帮助项目》中，我讨论了在利用 复刻 （ forking ） 潜力作为一种可以促进轻量级治理的力量方面，开源软件开发和标准开发治理能力的不同。另一个不同之处在于专利规则的选择。如何对待专利参与者专利权的处理通常在开源软件开发和标准开发中以不同方式排列。这种差异有一个理由。而且，这种差异会对构建开发过程产生影响。开源：在为开源项目做出贡献时授予的专利许可通常由每个贡献者的贡献确定。标准：参与者在标准制定方面做出的专利承诺通常由整个最终规范确定。开源项目：基于贡献的专利规则基于贡献的专利规则是什么意思？如果专利所有者提供软件，由于软件添加到项目中，项目软件侵犯了该贡献者拥有的专利，那么贡献者不应该返回来期望获得使用它所贡献的软件的专利许可费。当然，有许多不同的许可文本可以让我们忙于分析每个许可的解释，并讨论情况中的不确定性和细微差别。在另一篇文章中，我在 MIT 许可协议的背景下谈到了这个问题（《为什么 MIT 的专利许可不讨人喜欢？》）。我认为，基本上来说，开源开发中的共同期望就像我上面所描述的那样：当你为开源做出贡献时，你将为你提供的软件提供所有必需的权限，之后你将无法返回来再要求获得使用你所贡献软件的许可费。标准制定：基于标准规范的专利规则相比之下，在制定标准时，通常会有更高的期望：参与者应对专利做出承诺，这些专利对整个最终规范至关重要，而不仅仅是对其贡献。这些专利承诺并不取决于确定谁对规范提出了什么想法；对于那些参与开发规范的人来说，他们的承诺是整个标准规范。包括在其中的专利确定相关专利的分析在软件和规范之间也有所不同。软件通常包括与相应的标准规范相比不需要的实现细节；在提供软件时，将包括对这些细节使用任何专利的许可。相反，规范开发的专利承诺仅限于对规范“必要”或“必需”的专利。当然，这取决于规范的内容。对于互操作性标准，规范应仅包括实现互操作性所需的详细级别，从而允许实现细节在标准的竞争性实现之间有所不同。对必要专利的承诺不包括实施细节方面的专利，这些专利可用作竞争优势。专利规则差异的基础为什么在专利处理方面存在这种差异？鉴于标准和开源软件的开发方式存在差异，这种不同的处理方式很有意义。更有限的与贡献范围相关的专利符合大多数协作软件开发的渐进式、开放式特性。开源项目经常持续发展，其方向可能会随着时间的推移而演化。虽然可以设置路线图和里程碑并发布快照版本，但这些不太常见，并且比标准项目中常见的范围限制和版本目标具有更少的限制性影响。可以看出，考虑到标准规范开发结构的差异，标准开发的更高期望值（整个最终规范，不仅仅是贡献）是有意义的。标准规范通常采用具有明确范围的强版本导向演进。规范开发通常适用于特定的快照版本。标准开发活动通常具有一组目标功能（通常在诸如章程之类的文档中表示）。与许多软件开发活动的情况相比，这为可能应用到标准开发活动的技术范围提供了更清晰的公共的进展预期。这种范围的明确性有助于潜在参与者在开始参与时评估参与标准制定项目的专利影响。相比之下，开源软件开发项目更为开放，通常不会排除采用任何特定技术的可能性。对开源项目和标准管理的影响这些对待专利的不同措施需要不同的项目管理方法。开源项目通常准备接受来自新贡献者的补丁。贡献者可能会随着时间的推移而来去。一些贡献者留下来。其他人可能会为该项目来解决一个有限的问题。通过软件贡献，可以更容易地了解谁贡献了什么软件，而不是准确理解谁以一种更抽象的方式“参与”。另一方面，参与标准制定活动通常具有大量的正式手续。而且，在涉及专利承诺时，这种参与的正式性非常重要。当一个人参与该规范的大部分开发时，对最终规范的专利承诺是有意义的。标准制定过程是否可以从提供单一、有限贡献的人那里获得完整的最终规范承诺？重要的是要有一个过程，以便清楚地了解谁参与谁，谁不参与。需要明确参与者以支持来自实际专利所有者的专利承诺，实际专利所有者通常是由坐在桌旁（比喻，尽管这可能涉及实际的谈判桌）的个人所代表的公司。如何获得基于规范的承诺？软件标准中典型的免许可费专利承诺最常被作为获得标准组织成员资格或负责规范开发的特定委员会成员资格的条件。为了使这一机制发挥作用，成员资格必须是一个定义明确的概念，以便有一个明确的成员资格决策点（即，用于触发专利承诺的明确行动）和承诺的受益人可以依赖的明确的记录文件。除了参与清晰度之外，为了促进持怀疑态度的专利参与者的参与，项目需要具有明确的范围和明确的开始和结束（明确指出专利承诺将适用的“最终规范”）。这种参与模式与典型的开源项目有很大不同，典型的开源项目可能有一个连续的参与，其范围包括维护几个主要的驱动程序到只提交一个补丁。专利政策虽然我所描述的差异通常是这种情况，但某些特定活动遵循不同模式可能有一些原因。例如，考虑作为标准开发活动附带的参考实现的软件。可能有一个强有力的理由期望参与者对完整的最终参考实施提供承诺，而不仅仅是限定于他们对它的贡献。当然，可能存在其他边缘情况；可能存在严格安排的开源开发；可能会有连续的、随心所欲的规范开发。标准制定的专利政策可分为合理和非歧视（RAND）或免许可费（RF）：基本上来说，实施标准的专利许可费包括需要交（RAND）或不需要交（RF）。制定与软件相关的标准（本文的重点）更多地使用免许可费政策。关于专利许可费预期问题是许可或承诺范围政策之外的另一个维度。结论标准的制定和开源软件的开发通常具有不同的参与者专利期望范围（仅限于贡献或整个最终可交付成果）。这些不同的选择基于通常如何进行开发的显著差异，而不是任意差异。作者简介：Scott Peterson 是红帽公司法律团队成员。很久以前，一位工程师就一个叫做 GPL 的奇怪文件向 Scott 征询法律建议，这个致命的问题让 Scott 走上了探索包括技术标准和开源软件在内的协同开发法律问题的纠结之路。译者简介：薛亮，集慧智佳知识产权咨询公司总监，擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。
为何《贡献者许可协议》不利于开源社区？
开源社区中很少有法律话题像《贡献者许可协议》一样具有争议性。开源社区中很少有法律话题像《贡献者许可协议》（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 接受记录提供透明的随时可行的公开访问。许可撤销：一些 CLA 支持者警告说可能有一天，贡献者可能会试图撤销过去授予的许可。如果关注的范围是大量没有供职公司的具有判断力的个人贡献者，则不清楚为什么 Apache 风格的 CLA 与使用开源许可协议相比提供了更有意义的保护。而且，正如在讨论开源法律政策时提出的许多法律风险一样，这似乎是一种幻想的风险。多年来，我只听说过少数声称的许可撤销尝试活动，所有这些都在贡献者面临社区压力而退步时得到迅速解决。未经授权的员工贡献：这是许可撤销问题的一个特例，最近已成为 CLA 倡导者共同提出的观点。当员工为上游项目提供贡献时，通常雇主拥有项目给予许可的版权和专利，并且只有某些管理人员有权授予此类许可。假设一名员工在未经雇主批准的情况下向项目提供了专有代码，雇主后来发现这一点并要求删除该项贡献或起诉该项目的用户。通过使用类似 Apache CCLA 及其陈述和签名要求的材料，加上一些适当的审查程序以确定 CCLA 签名者可能被授权签署（我怀疑大多数使用 CLA 的公司没有采取任何有意义的措施），可以将这种未经授权的贡献风险最小化。基于常识和共同经验，我认为，在今天的几乎所有案例中，员工的贡献都是在雇主的实际或建设性知识基础上和同意下完成的。如果围绕开源软件存在高度诉讼风险，也许应该更加重视这种风险，但开源项目引发的诉讼仍然非常罕见。更重要的是，我不知道任何针对“入站=出站”项目的非源自涉嫌开源许可协议违规的版权或专利侵权指控因使用CLA而被阻止的案例。特别是，当指出未经授权的贡献风险时，CLA 支持者经常引用专利风险，但 Apache 风格的 CLA 中的专利许可授权的设计范围非常狭窄。此外，企业对开源项目的贡献通常很少，规模较小（因此很容易更换），并且随着时间的推移可能会被丢弃。备选方案如果您的公司没有对反 CLA 案例买账并且对简单使用“入站=出站”感到不舒服，那么还有其他方法可以替代非对称且管理上繁琐的 Apache 风格的 CLA 要求。使用 DCO 作为“入站=出站”的补充至少消除了厌恶风险的 CLA 倡导者的一些担忧。如果必须使用真正的 CLA，则无需使 用Apach e模式（更不用说它的怪异衍生物）。考虑“Eclipse 贡献者协议”的非规范核心（基本上是包含在 CLA 内的 DCO），或者 软件自由保护协会 （ Software Freedom Conservancy ） 的 Selenium CLA，它仅仅是对“入站=出站”贡献策略进行仪式化。作者简介：Richard Fontana 是红帽公司法律部门产品和技术团队的高级商业顾问。 他的大部分工作都集中在开源相关的法律问题上。 译者简介：薛亮，集慧智佳知识产权咨询公司总监，擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。
非标准的开源贡献者许可协议正在创造类似电影《冲出人魔岛》中“人魔”般的怪物。当我开启作为开源律师的职业生涯时，面临的一个重要问题是需要耗时费力去分析的新形式开源许可协议的激增，正如我的同事 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，那么强烈建议使用 Apache 软件基金会个人或企业 CLA 等标准 CLA，而不是创建新的、幻想的或荒谬的类似“人魔”怪物的许可协议。作者简介：Jeffrey R. Kaufman 是全球领先的开源软件解决方案供应商 Red Hat 公司的开源知识产权律师，还担任 托马斯杰斐逊法学院 （ Thomas Jefferson School of Law ） 的兼职教授。在任职 Red Hat 之前，Jeffrey 曾担任 高通公司 （ Qualcomm Incorporated ） 的专利顾问，为 首席科学家办公室 （ Office of the Chief Scientist ） 提供开源事务咨询。译者简介：薛亮，集慧智佳知识产权咨询公司总监，擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。