如果你认为开源软件是共享软件、免费软件和公有领域软件的代名词，那么你并不是唯一有这种看法的人。

当你听到“ 开源软件 （ 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 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。

非标准的开源贡献者许可协议正在创造类似电影《冲出人魔岛》中“人魔”般的怪物。

当我开启作为开源律师的职业生涯时，面临的一个重要问题是需要耗时费力去分析的新形式开源许可协议的激增，正如我的同事 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 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。

提要：传统观点认为，Apache 许可证拥有“真正”的专利许可，那 MIT 许可证呢？

我经常听到说，MIT 许可证中没有专利许可，或者它只有一些“默示”专利许可的可能性。如果 MIT 许可证很敏感的话，那么它可能会因为大家对其较为年轻的同伴 Apache 许可证的不断称赞而产生自卑感，传统观点认为，Apache 许可证拥有“真正”的专利许可。

这种区分经常重复出现，以至于人们认为，在许可证文本中是否出现“专利”一词具有很大的法律意义。不过，对“专利”一词的强调是错误的。1927 年，美国最高法院表示：

“专利所有人使用的任何语言，或者专利所有人向其他人展示的任何行为，使得其他人可以从中合理地推断出专利所有人同意他依据专利来制造、使用或销售，便构成了许可行为，并可以作为侵权行为的辩护理由。”

MIT 许可证无疑拥有明示许可。该许可证不限于授予任何特定类型的知识产权。但其许可证声明里不使用“专利”或“版权”一词。您上次听到有人表示担心 MIT 许可证仅包含默示版权许可是什么时候了？

既然授予权利的文本中没有“版权”和“专利”，让我们来研究一下 MIT 许可证中的字眼，看看我们能否了解到哪些权利被授予。

没有任何信息会导致人们认为，许可人会保留对使用专利所有人创造的软件的行为起诉专利侵权的权利，并允许其他人“无限制地处理本软件”。

为什么说这是默示专利许可呢？没有充足的理由这么做。我们来看一个默示专利许可的案例。Met-Coil Systems Corp. 诉Korners Unlimited 的专利纠纷涉及专利的默示许可（美国专利 4,466,641，很久以前已过期），该专利涉及用于连接供暖和空调系统中使用的金属管道段。处理该专利纠纷上诉的美国法院认定，专利权人（Met-Coil）出售其成型机（一种不属于专利保护主体的机器，但用于弯曲金属管道端部的法兰，使其作为以专利方式连接管道的一部分）授予其客户默示专利许可；因此，所谓的专利侵权者（Korners Unlimited）向这些客户出售某些与专利有关的部件（与 Met-Coil 机器弯曲产生的法兰一起使用的特殊角件）并不促成专利的侵权，因为客户被授予了许可（默示许可）。

通过销售其目的是在使用受专利保护的发明中发挥作用的金属弯曲机，专利权人向机器的购买者授予了专利许可。在 Met-Coil 案例中，可以看到需要谈论“默示”许可，因为根本不存在书面许可；法院也试图寻找由行为默示的许可。

现在，让我们回到 MIT 许可证。这是一个明示许可证。这个明示许可证授予了专利许可吗？事实上，在授予“无限制地处理软件”权限的情况下，MIT 许可证的确如此。没有比通过直接阅读授予许可的文字来得出结论更有效的办法了。

“明示专利许可”一词可以用于两种含义之一：

• 包括授予专利权利的明示许可证，或
• 明确提及专利权利的许可证。

其中第一项是与默示专利许可的对比。如果没有授予专利权利的明示许可，人们可以在分析中继续查看是否默示了专利许可。

人们经常使用第二个含义“明示专利许可”。不幸的是，这导致一些人错误地认为缺乏这样的“明示专利许可”会让人寻找默示许可。但是，第二种含义没有特别的法律意义。没有明确提及专利权利并不意味着没有授予专利权利的明示许可。因此，没有明确提及专利权利并不意味着仅受限于专利权利的默示许可。

说完这一切之后，那它究竟有多重要呢？

并没有多重要。当个人和企业根据 MIT 协议贡献软件时，他们并不希望稍后对那些使用专利所有人为之做出贡献的软件的人们主张专利权利。这是一个强有力的声明，当然，我没有直接看到贡献者的期望。但是根据 20 多年来我对依据 MIT 许可证贡献代码的观察，我没有看到任何迹象表明贡献者认为他们应该保留后续对使用其贡献的代码的行为征收专利许可费用的权利。恰恰相反，我观察到了与许可证中“无限制”这个短语一致的行为。

本讨论基于美国法律。其他司法管辖区的法律专家可以针对在其他国家的结果是否有所不同提出意见。

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

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

本文由高级咨询师薛亮据自由软件基金会（FSF）的英文原文翻译而成，这篇常见问题解答澄清了在使用 GNU 许可证中遇到许多问题，对于企业和软件开发者在实际应用许可证和解决许可证问题时具有很强的实践指导意义。

1. 关于 GNU 项目、自由软件基金会（FSF）及其许可证的基本问题
2. 对于 GNU 许可证的一般了解
3. 在您的程序中使用 GNU 许可证
4. 依据GNU许可证分发程序
5. 在编写其他程序时采用依据 GNU 许可证发布的程序
6. 将作品与依据 GNU 许可证发布的代码相结合
7. 关于违反 GNU 许可证的问题

5 在编写其他程序时采用依据 GNU 许可证发布的程序

5.1 我可以在同一台电脑上安装一个遵循 GPL 许可证的程序和一个不相关的非自由程序吗？（同 2.3）

可以。

5.2 我可以使用遵循 GPL 许可证的编辑器（例如 GNU Emacs）来开发非自由程序吗？我可以使用遵循 GPL 许可证的工具（例如 GCC）来编译它们吗？

可以，因为编辑器和工具的版权并不覆盖您所编写的代码。从法律上来说，使用它们不会对适用于您代码的许可证施加任何限制。

有些程序出于技术原因将其自身某些部分复制到输出文件中，例如，Bison 将标准解析器程序复制到其输出文件中。在这种情况下，输出文件中复制的文本遵循其在源代码中所遵循的相同许可证。同时，源自程序输入部分的输出部分继承输入部分的版权状态。

正因为如此，Bison 也可以用来开发非自由程序。这是因为我们决定明确允许在 Bison 输出文件中不受限制地使用 Bison 标准解析器程序。我们之所以做出这个决定，是因为还有其他与 Bison 相媲美的工具已被许可用于非自由程序。

5.3 有没有一些方法可以让使用我的程序的人们得到的输出物遵循 GPL？例如，如果我的程序用于开发硬件设计，我可以要求这些设计必须是自由的吗？（同 3.17）

一般来说，这在法律上是不可能的；针对人们通过使用您的程序获取数据形成的输出物如何使用，版权法并没有赋予您任何发言权。如果用户使用您的程序输入或转换自己的数据，输出物的版权属于他，而不是您。更一般来说，当程序将其输入物转换成其他形式时，输出物的版权状态将继承其得以生成的输入物的版权状态。

所以您对输出物的使用拥有发言权的唯一方式是输出物的实质部分（或多或少）是从您程序的文本中复制出来。例如，如果我们在这种具体情况下没有例外，那么Bison的一部分输出物（参见问题 5.2）将被 GNU GPL 所涵盖。

所以，即使没有技术原因，您也可以人为制作一个程序，将某些文本复制到其输出物中。但是，如果复制的文本没有实际用途，用户可以简单地从输出物中删除该文本，并且仅使用其余的内容。那么他就不必满足重新分发所复制文本的条件。

5.4 在什么情况下，遵循 GPL 的程序其输出文件也必须遵循 GPL 呢？

程序的输出文件通常不受程序代码的版权保护。因此，程序代码的许可证不适用于输出文件，无论是将其导入文件，还是制作屏幕截图、屏幕录像或视频。

例外情况是，程序全屏显示来源于程序的文本和/或艺术品。该文本和/或艺术品的版权则会覆盖其输出文件。输出音频的程序（例如视频游戏）也将适用于此例外。

如果艺术品/音乐遵循 GPL，则无论您如何进行复制，GPL 都适用。不过， 合理使用 （ fair use ） 可能仍然适用。

请记住，一些程序，特别是视频游戏，可以具有与底层遵循 GPL 的游戏分开许可的艺术品/音频。在这种情况下，艺术品/音频的许可证将规定视频/流媒体可以依之产生的条款。另请参阅：1.6 我可以将GPL应用于软件以外的其他作品吗？

5.5 如果我将我的程序移植到 GNU/Linux，这是否意味着我必须将其作为遵循 GPL 或其他自由软件许可证的自由软件进行发布？

一般来说，答案是否定的——这不是法律规定。具体来说，答案取决于您要使用哪些库以及许可证。大多数系统库都使用 GNU LGPL 许可证，或者使用 GNU GPL 加上允许将库与任何东西链接的例外声明。这些库可以在非自由程序中使用；但是在 LGPL 的情况下，它确实有一些必须遵循的要求。

一些库依据 GNU GPL 单独发布；您必须使用与 GPL 兼容的许可证才能使用这些库。但是这些通常是更特定的库，而在另一个平台不会有任何类似它们的库，所以您可能不会想要简单地移植使用这些库。

当然，如果您的软件不是自由软件，它不会对我们的社区做出贡献，而重视软件自由的人也会拒绝使用它。只有愿意放弃软件自由的人才会使用您的软件，这意味着它将有效地成为人们失去软件自由的诱因。

如果您希望有一天回头看您的职业生涯，觉得它有助于发展一个善良和自由的社会，您需要使您的软件成为自由软件。

5.6 我想将遵循 GPL 的软件纳入我的专有系统。我只依据 GPL 给予我的权限来使用该软件。我可以这样做吗？

您不能将遵循 GPL 的软件纳入专有系统。GPL 的目标是授予每个人复制、再分发、理解和修改程序的自由。如果您可以将遵循 GPL 的软件整合到非自由系统中，则可能会使遵循 GPL 的软件不再是自由软件。

包含遵循 GPL 程序的系统是该 GPL 程序的扩展版本。GPL 规定，如果它最终发布的话，任何扩展版本的程序必须依据 GPL 发布。这有两个原因：确保获得软件的用户获得自己应该拥有的自由，并鼓励人们回馈他们所做的改进。

但是，在许多情况下，您可以将遵循 GPL 的软件与专有系统一起分发。要有效地做到这一点，您必须确保自由和非自由程序之间的通信保持 一定距离 （ arms length ） ，而不是将它们有效地结合成一个程序。

这种情况与“纳入”遵循 GPL 的软件之间的区别，部分是实质问题，部分是形式问题。实质上是这样的：如果两个程序结合起来，使它们成为一个程序的两个部分，那么您不能将它们视为两个单独的程序。所以整个作品必须遵循 GPL。

如果这两个程序保持良好的分离，就像编译器和内核，或者像编辑器和 shell 一样，那么您可以将它们视为两个单独的程序，但是您必须恰当执行。这个问题只是一个形式问题：您如何描述您在做什么。为什么我们关心这个？因为我们想确保用户清楚地了解软件集合中遵循 GPL 的软件的自由状态。

如果人们分发遵循 GPL 的软件，将其称为系统（用户已经知晓其中一部分为专有软件）的“一部分”，用户可能不确定其对遵循 GPL 的软件所拥有的权利。但是如果他们知道他们收到的是一个自由程序加上另外一个程序，那么他们的权利就会很清楚。

5.7 如果我分发了一个与我修改后的遵循 LGPL v3 的库相链接的专有程序，那么为了确定我正在做出的明确的专利许可授权的范围， “贡献者版本” （ contributor version ） 是什么？它仅是库，还是整个组合？

“贡献者版本”仅是您的库版本。

5.8 依据 AGPL v3，当我根据第 13 节修改程序时，必须提供什么样的 相应源代码 （ Corresponding Source ） ？

“相应源代码”在许可证的第 1 节中定义，您应该提供其列出的内容。因此，如果您的修改版本取决于遵循其他许可证的库，例如 Expat 许可证或 GPL v3，则相应源代码应包括这些库（除非是系统库）。如果您修改了这些库，则必须提供您修改后的源代码。

第 13 节第一段的最后一句只是为了强化大多数人所自然地认为的那样：尽管在第 13 节中通过特殊例外来处理与遵循 GPL v3 的代码相结合的情况，相应源代码仍然应该包括以这种方式与程序相结合的代码。这句话并不意味着您只需提供 GPL v3 所涵盖的源代码；而是意味着这样的代码不会从相应源代码的定义中排除。

5.9 在哪里可以了解更多有关 GCC 运行时库例外的信息？

GCC 运行时库例外包含 libgcc、libstdc ++、libfortran、libgomp、libdecnumber 以及与 GCC 一起分发的其他库。这个例外是为了让人们根据自己选择的条件分发用 GCC 编译的程序，即使这些库的一部分作为编译过程的一部分被包含在可执行文件中。要了解更多信息，请阅读有关 GCC 运行时库例外的常见问题。

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

提要：Apache 2.0许可证中的专利许可条款使得开源代码可以安全使用，但它经常被误解。

Apache 2.0 许可证包含许多关键条款，其中也包括根据我的经验经常被误解的 专利许可 （ patent grant ） 条款。专利许可对于开源代码的安全使用具有重大影响。我通过分析 Apache 2.0 许可证第 3 部分的其中一段来具体解释：

3. 专利许可的授予 （ Grant of Patent License ） 。根据本许可证的条款和条件，每个 贡献者 （ Contributor ） 特此授予您永久的、全球性的、非独占的、免费的、免版税的、不可撤销的（本节所述除外）专利许可，从而制作、委托制作、使用、许诺销售、销售、进口和以其他方式转移 作品 （ the Work ） ，该专利许可仅适用于贡献者提供的满足以下条件的专利权利要求：贡献者的 贡献 （ Contribution ） 单独对该权利要求必然构成侵权，或贡献者的贡献与贡献者提交此类贡献的作品之间的结合对该权利要求必然构成侵权。

实质上，当软件开发人员为项目（即 Apache 2.0 许可证中的“作品”）贡献代码，他/她就成为贡献者。在上述条款中，贡献者授予了使用任何可能与其贡献相关的专利的许可。这让用户感到安心，因为贡献者可能会被禁止向任何使用包含该贡献的软件的用户收取专利许可费。

但当软件开发人员贡献的代码仅其自身来说没有被贡献者的任何专利所覆盖，而只有与贡献者提交此类贡献的遵循 Apache 2.0 许可证的开源项目相结合才能被相关专利覆盖时，问题就变得复杂了。因此，拥有相关专利的贡献者可以向使用修订版作品的用户收取专利许可费。Apache 2.0 许可证的作者进行了前瞻性思考，对这种情况也进行了说明。第 3 条规定，该许可证适用于“贡献者提供的满足以下条件的专利权利要求：……贡献者的贡献与贡献者提交此类贡献的作品之间的结合对该权利要求必然构成侵权。”

一些贡献者可能担心他们的贡献会导致广泛的专利许可。例如，您向遵循 Apache 2.0 许可证的开源项目贡献代码，在您提交贡献的时候，无论是您的贡献自身还是其与开源项目的结合都没有对您的专利构成侵权，但后续该作品通过其他人而非您的贡献在功能上进行了扩展，从而被您的专利所覆盖，这种情况该怎么办呢？您的专利会被自动许可吗？按照 Apache 软件基金会的常见问题解答，情况并非如此。

这个结果似乎以一种开放/合作的方式，在向 Apache 2.0 开源项目贡献代码的专利所有者与保证相关专利不会针对依据 Apache 2.0 许可证享有权益的作品用户主张专利权的必要性之间，达成了一种明智的平衡。

关于依据 Apache 2.0 许可证向 Apache 软件基金会提交贡献的专利许可范围的相关问题和答案，可以在 Apache 软件基金会有关许可的常见问题解答里找到。

请记住，这是 Apache 软件基金会对 Apache 2.0 许可证的解释。使用 Apache 2.0 许可证的其他许可人可能会以不同的方式解释该许可证中专利许可条款的范围，但我认为那似乎不太可能会成功，Apache 软件基金会的常见问题解答对专利许可条款的解释看起来合情合理。

作者简介：Jeffrey R. Kaufman 是全球领先的开源软件解决方案供应商 Red Hat 公司的开源知识产权律师，还担任 托马斯杰斐逊法学院 （ Thomas Jefferson School of Law ） 的兼职教授。在任职 Red Hat 之前，Jeffrey曾担任 高通公司 （ Qualcomm Incorporated ） 的专利顾问，为 首席科学家办公室 （ Office of the Chief Scientist ） 提供开源事务咨询。

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