保留简略的版权声明即可，无需投入过多资源维护。

版权声明 （ 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 ） 的一名开源律师。我工作中的一个重要部分是向其他公司（包括其内部法律顾问）提供有关红帽公司如何采用完全开源的开发模式来构建企业级产品的信息，并回答他们有关开源许可的一般问题。在听了红帽公司的成功经验之后，这些律师与我对话的话题常常转变为其所在组织如何发展成为更具开源意识和能力的组织，他们也经常询问我如何改善他们的做法，以便更熟练地为其组织的雇员提供开源法律咨询。在这两篇文章中，我将分享我通常在这些主题上告诉内部法律顾问的那些内容。

总是要找到一条可行路径

我的雇主红帽公司在使用开源软件方面的独特之处在于，我们的开发模式始于具有数千名贡献者的开源社区，并产生了经受过尝试、测试和信任的最终产品。更具体地说，通过我们独特的开发模式，我们从社区创建的开源软件开始，并在每个项目的基础上加强安全性，修复错误，修补漏洞并添加新功能。然后，我们将这些改进回馈给每个项目，以便使整个开源社区受益。此方法的效用非常重要，包括：

1. 通过内部团队与组织外部其他人之间的协作来利用外部创新；
2. 当现有或潜在的社区与您在同一问题上开展工作而且能够合作时，可以避免您自己开发和维护开源解决方案的成本和效率低下的问题；

3. 通过与合作伙伴和上游项目社区的富有成效的合作，能够避免维护主项目下游分支的昂贵代价。

   • 一些公司发现创建上游代码的非公共分支很诱人，因为它是解决特定 用例 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 中的作者对开源的理解上虽有偏颇，但并没有出现知识或法律方面的硬伤。

从开源软件概念引入中国，到近几年开源运动如火如荼的开展，已有几个年头。但据笔者与企业及业内人士的接触发现，公众对开源的认知和理解程度依旧参差不齐。究其原因有以下几点：

1. 大部分关注开源的人，更多的是关注技术，不会关注其背后的许可证问题；
2. 开源许可证更偏向法律，真正做技术的不关注、也不懂；
3. 开源许可证法律条文晦涩难懂，不容易理解；
4. 懂技术、会看代码的专利、著作权、商标等领域的律师甚少，没有技术背景的律师纵使法律水平再高，在理解涉及开源软件相关问题时也力不从心；
5. 开源领域国内诉讼不多，没有充分引起大部分企业、学界等人员的重视；
6. 也因为诉讼少，经济驱动力有限，很难吸引律师深入研究这一领域。重赏之下必有勇夫，若有足够的利益驱动，修个计算机学位又何妨，或者报个代码速成班也不是不可能吧。

笔者有缘在多年前接触开源治理、合规问题，时不时看到网上爆出浅层次开源“事故”，说明大众的开源知识有限。今天蹭个热乎劲，再探讨一下开源基础知识（开源科普的知识网上并不少，没人关注归根结底还是这个领域内生动力不足所致）。既然内生动力不足，就靠外部热点的外部动力吧。

开源“事故”，你是否理解开源？

开源是什么？

开源就是奉献，无私或有私的奉献。此处不接受反驳。

开源运动起源于自由软件运动，自由软件运动的发起人 理查德·马修·斯托曼 （ Richard Matthew Stallman ） 是自由软件运动精神领袖。自由软件运动所要反对的就是后来以比尔盖茨（曾经）为代表的软件私有化运动。所以说，自由软件是旗帜鲜明的追求奉献、共享和软件自由的。

开源运动的兴起是自由软件运动向商业化的妥协（可以这么说，毕竟经济基础决定上层建筑），所以说开源软件运动虽然有别于曾经的自由软件运动，奉献和协作依然深深的烙在其血液里。如果你无法理解这一点，就再看 10 遍开源软件的定义（直到看懂为止）。

开源运动淡化了自由软件运动乌托邦式的理想主义，穿上了实用主义的外衣，毕竟空洞的理想是填不饱肚子的。

开源“事故”，背后的起因

网上时不时爆出的开源“事故”大都归于两类：

类型一：批判拿来主义者坐收渔利、不劳而获、贩卖别人劳动成果……。这一类主角，多是软件开发者自己，站在自己的立场上看待开源软件的使用者（合法使用者、不合法使用者）。

该类“事故”的原因有：

1. 软件的开发者没有充分理解开源的要义；
2. 对开源许可证不理解，开源自己软件时没能正确选择许可证，导致自己有被白piao的感觉；
3. 想借助大众或社区的力量优化自己的软件，获得免费劳动力；
4. 想借助开源扩大自己影响力（自我营销），却没考虑为此要付出的代价；
5. 看到其他人利用自己的开源软件获利，心理上有些许不平衡。

类型二：批判开源软件收费、许可证不人性，批判严格型许可证的传染性像病毒、吸血鬼、耍流氓，对别人行使著作权或协议约定的行为愤愤不平。这一类人，基本是拿来主义者，同样站在自己的立场上看待开源软件的开发者（仁慈的开发者、邪恶的开发者）。

该类“事故”的原因有：就是想白 piao 而已，因为你完全有选择用与不用的权力。

这两类“事故”的产生都源于没能深入理解开源运动的精髓和要义，纯粹的从利己主义出发思考问题，没有做到换位思考。忽略了开源的初衷：奉献和共享。

现实中，经常发生这样的事情：对同一个人，作为开源的使用者时他们常常讨厌 GPL 许可证，因为限制太多；作为开源软件开发者时又喜欢 GPL 的安全感，讨厌 MIT、BSD 等许可证让自己被白 piao 了却投诉无门。

开发者和使用者的权利义务

开源软件首先是开发者的劳动成果，是拥有著作权的。开源一定意义上就是奉献，每一个开源软件使用者都是开源的受益者。面对这种奉献，你需要做的就是尊重。但开源的使用者并不必然要求是高尚的、无私的，这种尊重基于开发者选择的开源许可证在合规的前提下行使权利，在尊重权利人的同时实现共赢和自身利益最大化。

而作为开源软件的开发者，也不必然要求是高尚的、无私的，开发者可以基于自己的目的来选择适当的开源协议。选择开源，就要审视自己内心深处的想法，开源的动机和目的是什么？后果是什么？……慎重的思考了这些问题后，还需要清楚的知道选择宽松型的许可证可能要面对的各种问题。

开源使用者是纯粹的受益者，即便是抱怨无非是对严格型许可证发发牢骚而已。而开源的开发者往往显得更值得同情，一般是从道义上（如案例 3）以及经济利益上（如案例 1、2）体现。但这就是开源运动运行的机制，它肯定不完美，但被证明是行之有效的。针对开源开发者，你需要做的就是当别人违法的时候拿起法律的武器捍卫自己的权利，当别人没有违法的时候，你心里再不爽也要保持淡定。

当然，诸如前述案例让人糟心的事情肯定很多，开发者也不是束手无策：

比如案例 1 中新蜂商城的作者，选择了 MIT 这个非常宽松的许可证。就意味着，其他人几乎可以拿来做任何事情，包括卖钱。但你依然有以下权利：

1. 不准拿你的大名做推广，或者类似名字这种具有身份意义、独特标识作用的符号；
2. 如果作品真的好且有市场，作者完全可以自己经营，将自己的品牌做大；
3. 别人卖的了你的源码卖不了你的实力，你可以不断迭代升级，源码和服务提供一站式解决方案。其实，现实中我们熟悉的开源软件大都如此，比如 Android、Linux 等；
4. 乐见其成，毕竟开源就是奉献自己的劳动成果让人使用，二手贩子们所做的事与开源者的目标是一致的。当然如果贩子们声称是自主源码云云（国内拿开源的东西声称自主开发的太多了），那必然是违法的，开源者可以大胆的拿起法律的武器。

主动开源，你真的准备好了吗？

基于国内的现实状况，笔者以往更多的是将精力放在帮助企业和开发者合规的使用和利用开源。因为我们曾经都是开源的受益者，需要基于合法、合规的前提汲取营养、学习知识。

目前，国内越来越多企业或个人开始思考反哺开源社区，这是非常好的开始，说明我们从受益者开始变为奉献者。但现实中这些才华横溢的开发者在开源中难免遇到案例中的问题，一旦遇到将严重挫伤其开源的积极性。

因此，开源开发者在主动开源之前，更需要深刻理解开源，明确自己开源的目的以及可能面对的潜在问题等。在慎重思考自己开源的目的和对开源后各种问题的考量后，选择适合自己的许可证。

以下是几个典型的开源动机面临的潜在风险：

1. 想借助大众或社区的力量优化自己的软件，获得免费劳动力
   开源软件千千万，真正取得成功或大众认可的软件凤毛麟角，不能说这种目的动机不纯，至少实现的可能性甚微。更多的可能是根本没有人看得上你的项目。
2. 想借助开源扩大自己影响力（自我营销）
   这可能是开源开发者，包括大企业做开源的一个非常重要的目的。具体能否实现，就看你的水平有多高，实力是否匹配自己的梦想。
3. 基于自己牛逼的软件，打造生态。
   这也是大部分企业的终极梦想，就像第一条所述，大部分的开源软件都归于路人甲，能否实现自己的生态梦取决于你的软件到底如何，能否支撑一个生态、够吸引外围群落。
   即便这些都满足了，还要思考一点，你自己的实力能否持续主导这个生态的发展。因为，开源社区的主导力是由实力说话的，如果你无法保持持续的创造力，别人fork一下就可能成为新的盟主而把你晾在一边坐冷板凳。Google 的 Android 生态就是道理，Google 对 Android 生态的领导力是建立在其持续的创造力之上的。
4. 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 个项目做出了贡献。但是，开源软件开发与常规许可软件开发的不同之处不仅仅是贡献者数量。除了被发现对该开源项目拥有某些共同兴趣，为开源项目做出贡献的人们之间可能没有任何联系。人们的参与情况可能会随着时间的推移而变化。原始开发人员可能会离开，留下其他人继续进行项目开发。所有这一切都可能在没有规划或总体治理组织的情况下发生。

除了遵循规范性的治理规则，开源协作活动还是轻量级的，而且可以比常规许可软件更加灵敏地响应。有关开源许可信息的实践与这种协作开发方式相适应。

1. 针对二进制文件以及源代码，开源许可中的条款通过提供所需的权限（包括复制、修改和分发）促进了协作开发。事实证明， “开源定义” （ Open Source Definition ） （OSD）有助于将注意力集中在满足其要求的许可上。
2. 开源软件的许可信息嵌入在源代码中。当获得源代码时，就会接收到相应的许可信息。想象一下每年以百万计的贡献规模，单独的许可管理是否完全可行呢？同样，通过将许可信息嵌入源代码中，可以反映与许可相关的详细信息，而这些细节在某些单独管理的许可流程中不可行。例如，将许可信息嵌入源代码，使得指示哪些许可条款适用于软件的哪些部分变得切实可行。

为了说明开源许可实践所能实现的效果，请考虑以下示例性软件项目：

该项目始于 5 年前；到目前为止，已有 50 位贡献者做出了贡献；通过改编其他项目中的部分软件，增加了一些功能；原始代码的开发者在三年后离开；几家商业企业已经在其内部或一部分产品中依赖该软件；如果考虑到其他软件和计算机世界方面相关的变化，则该软件未来可能还会有 5-10 年的发展。

在开源项目中现有和常用的表示许可信息的方法，很容易适应这样一个项目的过程。没有预先规划，贡献者可以从项目中来来去去；项目的各个部分遵循不同的许可条款；如果与其他公司的合作破裂，商业企业可以继续以很少的管理开销成本分担软件维护工作，同时保持完全独立开发其软件分支的能力。

相反，传统的软件许可方法将如何支持这种开发呢？甚至这样的合作有可能发生吗？我们是否将拥有一个完整的许可基础结构来跟踪数千个“主软件开发和分发协议”的适用性？我们是否要通过让某些公司控制一切来简化许可？

让我们回到“是什么许可？”这个问题。我谈论开源开发特征的目的，是说明存在重要的影响开源许可信息如何表示的非法律因素。开源软件中许可信息的表示形式通常不符合常规软件许可的期望。但是，存在差异并不代表系统出毛病了。相反，对于支持过去二十年中已被证明有效的大规模协作开发这种软件构建方法来说，差异的作用非常强大。

开源许可信息是什么样的呢？

通常，人们会考虑每个“软件组件”的许可条款。软件组件可能作为应用程序对用户可见，或者对于用户来说可能不那么明显，例如与大型程序结合使用时可提供某些功能的库。

对于许多软件组件而言，许可很简单：组件中的所有软件适用数十种最常见的开源许可证中的一种。除了最常见的许可证之外，还有很多文本有所变动的不经常使用的许可证。但是，在“开源定义”的指导下，开源许可条款中的权限和限制仍保持在一定范围内。

如果要进行将开源软件集成到其他软件中的软件开发，那么你需要了解适用于所集成软件的所有 “左版” （ Copyleft ） 条款（例如著名的 GPL 系列许可证）。

由于从我对开源软件开发方式的讨论中揭示的显而易见的原因，许可信息可能比单个许可证更为复杂。

1. 尽管一个软件组件可能有一个主要的“项目许可”，但可能有一部分软件遵循其他许可证。这可能会导致在源代码的各个部分中出现不同的许可声明。
2. 一些项目的做法是在每个源文件中放置版权声明。其他项目主要依靠放置包含许可文本的一个或多个文件。
3. 版权声明指示谁可能是该软件部分的版权拥有者（但是，鉴于版权声明实践的多样性，该指示的作用可能微不足道）。
4. 用来构建软件组件的源代码可以包括未反映在所得组件中的软件，例如与测试或构建相关的文件。这对于使用无 GPL 规则（项目中可能包含遵循 GPL 许可证的文件，但用于生成可执行程序的文件不得包含遵循GPL许可证的文件）的人可能很重要。

因为许多细节都与某些许可信息涉及的软件部分有关，这种细粒度的许可信息在源代码中最有效地进行了传达。在最详细的级别上，源代码即许可证。当许可信息在源代码中时，可以用与源代码相同的方式（例如在版本控制系统中）来维护该许可信息，并且该信息固有地可用于获得源代码的任何人。

从源代码中提取许可信息并创建许可条款概要似乎很简单。但是，对于一个人或一个公司来说足够了的摘要，可能对于另一个人或公司是不足的。不同的人可能关注不同的许可信息细节。一些人可能想确切地知道该软件的哪些组件遵循“左版”条款。其他人可能并不关心所有组件的许可条款概要。还有的人可能需要包括每个不同的版权声明在内的所有许可声明。

你想查看哪些许可信息的细节呢？在软件开发中有大量的工具可以使用。扫描、提取和报告现有许可信息的工具是持续开发的活跃主题。现在，“是什么许可？”可能会改写为“向我显示许可信息报告”，该报告可能包括一系列程度不同的详细信息，具体取决于对请求报告的人的重要性。在最详细的级别上，源代码即许可证。

因为软件可以采用不同的方式构建出来，常规软件许可和开源软件许可分别适用于不同的领域。两者之间可能存在差异，对于这一点要做好准备。

作者简介：Scott Peterson 是红帽公司法律团队成员。很久以前，一位工程师就一个叫做 GPL 的奇怪文件向 Scott 征询法律建议，这个致命的问题让 Scott 走上了探索包括技术标准和开源软件在内的协同开发法律问题的纠结之路。

译者简介：薛亮，集慧智佳知识产权咨询公司互联网事业部总监，擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。