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

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

1、关于 GNU 项目、自由软件基金会（FSF）及其许可证的基本问题

1.1 “GPL” 代表什么意思？

“GPL” 代表“ 通用公共许可证 （ General Public License ） ”。 最常见的此类许可证是 GNU 通用公共许可证，简称 GNU GPL。 如果人们能够自然而然地将其理解为 GNU GPL，可以进一步缩短为“GPL”。

1.2 自由软件是否意味着必须使用 GPL？

根本不是的，还有许多其他自由软件许可证。我们有一个不完整的列表。任何为用户提供特定自由的许可证都是自由软件许可证。

1.3 为什么我要使用 GNU GPL，而不是其他自由软件许可证？

使用 GNU GPL 将要求所有发布的改进版本都是自由软件。这意味着您可以避免与您自己作品的专有修改版本进行竞争的风险。不过，在某些特殊情况下，最好使用一个更宽松的许可证。

1.4 所有 GNU 软件都使用 GNU GPL 作为其许可证吗？

大多数 GNU 软件包都使用 GNU GPL，但是有一些 GNU 程序（以及程序的一部分）使用更宽松的许可证，例如 LGPL（ 较宽松公共许可证 （ Lesser GPL ） ）。我们这样做是基于战略考虑。

1.5 如果一个程序使用 GPL 许可证，是否会使其成为 GNU 软件？

任何人都可以依据 GNU GPL 发布一个程序，但并不能使其成为 GNU 软件包。

让程序成为 GNU 软件包意味着将其明确地贡献给 GNU 项目。当程序的开发人员和 GNU 项目都同意这样做时，才会发生这种情况。如果您有兴趣向 GNU 项目贡献程序，请写信至 mailto:[email protected] 。

1.6 我可以将 GPL 应用于软件以外的其他作品吗？

您可以将 GPL 应用于任何类型的作品，只需明确该作品的“源代码”构成即可。 GPL 将“源代码”定义为作品的首选形式，以便在其中进行修改。

不过，对于手册和教科书，或更一般地，任何旨在教授某个主题的作品，我们建议使用 GFDL，而非 GPL。

1.7 手册为什么不使用 GPL 许可证？

手册也可以使用 GPL 许可证，但对于手册来说，最好使用 GFDL（ 自由文本授权 （ GNU Free Documentation License ） ）许可证。

GPL 是为软件程序设计的，它包含许多复杂的条款，对于程序来说至关重要；但对于图书或手册来说，这将是麻烦和不必要的。例如，任何人如果（以 GPL ）出版纸质图书，就要么必须为每份印刷版本配置该图书的机器可读形式“源代码”，或提供书面文件，表明将稍后发送“源代码”。

同时，GFDL 中包含了帮助免费手册的出版商从销售副本中获利的条款，例如，出售封面文字。 背书 （ Endorsements ） 部分的特殊规则使得 GFDL 可以作为官方标准。修改版本的手册是被允许的，但该修改版本不能被标记为“该标准”。

使用 GFDL，我们允许对手册中涵盖其技术主题的文本进行修改。能够修改技术部分非常重要，因为修改程序的人理所当然地要去修改对应的文档。人们有这样做的自由，它是一种道德责任。我们的手册还包括阐述我们对自由软件政治立场的部分。我们将它们标记为 “不变量” （ invariant ） ，使得它们不被更改或删除。 GFDL 中也为这些“不变部分”做出了规定。

1.8 GPL 被翻译成其他语言了吗？

将 GPL 翻译成英文以外的语言将是有用的。人们甚至进行了翻译，并将文本发送给我们。但我们不敢将翻译文本批准为正式有效。其中的风险如此之大，以至于我们不敢接受。

法律文件在某种程度上就像一个程序。翻译它就像将程序从一种语言和操作系统转换到另一种语言。只有同时熟练使用这两种语言的律师才能做到这一点——即便如此，也有引入错误的风险。

如果我们正式批准 GPL 的翻译文本，我们将不得不给予所有人许可，让他们可以去做翻译文本规定可以做的任何事情。如果这是一个完全准确的翻译，那没关系。但如果翻译错误，后果可能是我们无法解决的灾难。

如果一个程序有 bug，我们可以发布一个新的版本，最终旧版本将会逐渐消失。但是，一旦我们给予每个人去根据特定翻译文本行事的许可，如果我们稍后发现它有一个错误，我们无法收回该权限。

乐意提供帮助的人有时会为我们做翻译工作。如果问题是要找人做这个工作的话，那问题就解决了。但实际的问题是错误的风险，做翻译工作不能避免风险。我们无法授权非律师撰写的翻译文本。

因此，目前我们并不认可GPL的翻译文本是全球有效和具有约束力的。相反，我们正在做两件事情：

• 将非正式的翻译指引给人们。这意味着我们允许人们进行GPL的翻译，但是我们不认可翻译文本具有法律效力和约束力。
  未经批准的翻译文本没有法律效力，应该如此明确地表述。翻译文本应标明如下：

This translation of the GPL is informal, and not officially approved by the Free Software Foundation as valid. To be completely sure of what is permitted, refer to the original GPL (in English).
本 GPL 翻译文本是非正式的，没有被自由软件基金会（FSF）正式批准为有效。若要完全确定何种行为被允许，请参阅原始 GPL（英文）。

但未经批准的翻译文本可以作为如何理解英文 GPL 的参考。对于许多用户来说，这就足够了。不过，在商业活动中使用 GNU 软件的企业，以及进行公共 ftp 发行的人员，需要去核查实际的英文 GPL，以明确其允许的行为。

• 发布仅在单个国家/地区有效的翻译文本。
  我们正在考虑发布仅在单个国家正式生效的翻译文本。这样一来，如果发现有错误，那么错误将局限于这个国家，破坏力不会太大。
  即便是一个富有同情心和能力的律师来做翻译，仍然需要相当多的专门知识和努力，所以我们不能很快答应任何这样的翻译。

1.9 为什么有一些 GNU 库依据普通 GPL 而不是 LGPL 来发布？

对于任何特定库使用 LGPL 构成了自由软件的倒退。这意味着我们部分放弃了捍卫用户自由权利的努力，对基于 GPL 软件所构建产品的分享要求也降低了。在它们自身而言，这是更糟糕的变化。

有时一个小范围的倒退是很好的策略。某种情况下，使用 LGPL 的库可能会带来该库的广泛使用，从而进一步改善该库，为自由软件带来更广泛的支持，诸如此类。如果在相当大的程度上出现这种情况，这可能对自由软件很有好处。但它发生的几率有多少呢？我们只能推测。

在每个库上用一段时间的 LGPL，看看它是否有帮助，如果 LGPL 没有帮助，再将其更改为 GPL。这种做法听起来很好，但却是不可行的。一旦我们对特定库使用了 LGPL，那就很难进行改变。因此，我们根据具体情况决定每个库使用哪个许可证。对于我们如何判断该问题，有一段很长的解释。

1.10 谁有权力执行 GPL 许可证？

由于 GPL 是版权许可，软件的版权所有者将是有权执行 GPL 的人。如果您发现违反 GPL 的行为，您应该向遵循GPL的该软件的开发人员通报。他们是版权所有者，或与版权所有者有关。若要详细了解如何报告 GPL 违规，请参阅“如果发现了可能违反 GPL 许可证的行为，我该怎么办？”

1.11 为什么 FSF 要求为 FSF 拥有版权的程序做出贡献的贡献者将版权 分配 （ assign ） 给 FSF？如果我持有 GPL 程序的版权，我也应该这样做吗？如果是，怎么做？

我们的律师告诉我们，为了最大限度地向法院要求违规者强制执行 GPL，我们应该让程序的版权状况尽可能简单。为了做到这一点，我们要求每个贡献者将贡献部分的版权分配给 FSF，或者放弃对贡献部分的版权要求。

我们也要求个人贡献者从雇主那里获得版权放弃声明（如果有的话），以确保雇主不会声称拥有这部分贡献的版权。

当然，如果所有的贡献者把他们的代码放在公共领域，也就没有用之来执行 GPL 许可证的版权了。所以我们鼓励人们为大规模的代码贡献分配版权，只把小规模的修改放在公共领域。

如果您想要在您的程序中执行 GPL，遵循类似的策略可能是一个好主意。如果您需要更多信息，请联系 mailto:[email protected]。

1.12 我可以修改 GPL 并创建一个修改后的许可证吗？

您可以制作GPL的修改版本，但这往往会产生实践上的后果。

您可以在其他许可证中合法使用GPL条款（可能是修改过的），只要您以其他名称来称呼您的许可证，并且不包括 GPL 的 引言 （ preamble ） ，只要您对最后的使用说明进行了足够多的修改，使其措辞明显不同，没有提到 GNU（尽管您描述的实际过程可能与其类似）。

如果您想在修改后的许可证中使用我们的引言，请写信至 mailto:[email protected]，以获得许可。我们需要查看实际的许可证要求，才能决定我们是否能够批准它们。

虽然我们不会以这种方式对您修改许可证提出法律上的反对意见，但我们希望您三思而行，别去修改许可证。类似这些修改后的许可证几乎肯定与 GNU GPL 不兼容，并且这种不兼容性阻碍了模块之间的有用组合。

不同自由软件许可证的扩散本身就是一个负担。请使用 GPL v3 提供的 例外 （ exception ） 机制，而不是去修改 GPL。

1.13 为什么你们决定将 GNU Affero GPL v3 作为一个单独的许可证？

GPLv3 的早期草案在第 7 节中允许许可人在发布源代码时添加一个类似 Affero 的要求。但是，一些开发和依赖自由软件的公司认为这个要求太过繁重。他们希望避免使用遵循这个要求的代码，并且对检查代码是否符合这个附加要求所带来的管理成本表示担忧。通过将 GNU Affero GPL v3 作为单独的许可证发布，在该许可证以及 GPL v3 中允许遵循该许可证的代码链接到彼此，我们完成了所有最初的目标，同时更容易确定哪些源代码需要遵循发布要求。

（题图：pycom.io）

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

在 2016 年 7 月，Facebook 公司的 React.js 开源许可协议曾引起激烈争论。一年过后，该协议再次成为开源社区的头条新闻。

背景介绍

React.js 是 Facebook 推出的一个用来构建用户界面的 JavaScript 库，起源于 Facebook 的内部项目，用来架设 Instagram 的网站。

• 2013 年 5 月，Facebook 将 React.js 开源。
• 2016 年 7月，React.js 开源许可协议中的附加专利条款引发争议。
• 2016 年 11 月，Facebook 发布官方问答，对附加专利条款进行澄清。
• 2017 年 7 月，Apache 基金会禁止使用遵循 BSD 许可证 + 专利开源协议的 JAR 包。

Apache 基金会的立场

2017 年 7 月，针对 Facebook 公司的 BSD 许可证 + 专利开源协议，Apache 基金会提出了如下建议：

1. 任何新项目、子项目或代码库都不允许使用遵循 Facebook 公司 “BSD 许可证 + 专利开源协议”的 jar 包。换句话说，如果你之前没有使用过，之后也不允许去使用。这种许可协议被 Apache 基金会列为 X 类别（Cat-X）。
2. 如果你一直在使用，并且在 release 中已经这么做了，那么在 2017 年 8 月 31 日之前，你将暂时从 X 类别中被排除。在此之后，任何和所有使用 Facebook 公司 “BSD 许可证+专利开源协议”的产品都将被 Apache 基金会禁止使用，你必须找到采用了合适许可证的替代品，或者放弃使用。这种情况没有例外。
3. 上述条款没有涵盖的任何其他情形也禁止使用。

X 类别被定义为“Apache 产品中可能不允许的许可证”，目前包括 GNU GPL、GNU LGPL、BCL、BSD-4-Clause 等许可证。有关禁用许可证列表可以在 Apache 基金会网站上查询。

Facebook 的 “BSD 许可证 + 专利开源协议”

React 是一种流行的用于创建丰富用户界面的 JavaScript 技术，最初来源于 Facebook，并被广泛使用。该技术依据 BSD 许可证进行开源，但是，它的附加专利条款需要特别注意（以下为节选）。

Facebook, Inc.（Facebook）特此授予软件的每个接收人（“你”）基于任何 “必要权利要求” （ Necessary Claims ） 的永久的、全球范围的、免版税的、非排他的、不可撤销的许可（遵守以下终止条款），可以制造、曾经制造、使用、销售、许诺销售、进口以及转移软件。

如果您（或任何您的子公司、关联方或代理商）直接或间接地启动了专利主张，或从专利主张中直接获取经济利益，本协议授予的许可将自动终止，恕不另行通知：（i）针对 Facebook 或其任何子公司或关联方；（ii）全部或部分来自于 Facebook 或其任何子公司或关联方的任何软件、技术、产品或服务的专利主张针对任何一方；或（iii）与软件相关的任何一方。尽管如此，如果 Facebook 或其任何子公司或关联方首先对你提起专利侵权诉讼指控，你在该诉讼中针对与软件无关的一方提起专利侵权反诉，你所被授予的许可不会因反诉而在本段第（i）款的规定下终止。

如果你的项目中正在使用或打算使用 React，你可能需要去咨询律师了。由于专利条款的限制，你不能做任何构成与 Facebook 竞争的事情。如果你采取法律行动或者以其他方式挑战 Facebook，那么你使用 React 的许可会被立即撤销。

如果你与其他使用 React 的公司发生法律纠纷，那你使用 React 的许可也会被撤销。Aurelia 框架创建者、Angular 2 开发团队前成员 Rob Eisenberg 表示，这就是 Google 公司和 Microsoft 公司的员工在工作中不允许使用 React.js 的原因。

虽然这只是在理论上对大多数采用 React 的项目可能产生的影响，但仍然值得特别注意，并且，类似 WordPress Calypso 这种已经与 React.js 建立了深刻联系的项目，可能会受到限制。运营 WordPress 的 Automattic 公司对一些小官司并不陌生，但这次很可能成为 Facebook 这个大公司的诉讼对象。

Drupal 和 WordPress 等许多开源产品都在采用 Facebook 公司的 React.js 技术。对于 Automattic 公司这种拥有开源产品的公司来说，未来如果被 Facebook 认定与 Facebook 构成竞争，将会是一个棘手的问题。

目前 Facebook 正如日中天，以上可能性发生的几率比较小，但如同 Yahoo 公司一样，Facebook 总有一天会从神坛跌落。到那时，Facebook 公司很有可能会从竞争角度充分利用许可协议所赋予的权利。所以，如果你打算利用 React.js 创建一个有可能终结 Facebook 神话的产品，最好先咨询你的律师。

但是，美国专利法非常复杂，尤其是在知识产权相关问题上，往往难以解释。从 Google 和 Oracle 公司有关安卓使用 Java 的争议可以看出，解决此类问题往往需要好几年时间。这意味着你必须要财大气粗，即使是你最后赢了官司。

Facebook 公司的官方问答

React 的技术优势难以挑战。从开发者构建 web 用户界面方面来说，React 引发了一场变革。Facebook 在某些方面不太清楚的许可协议（BSD 许可证+专利）在开源开发者中间引发了激烈争论。开源社区继续坚持对“邪恶公司”的抵制，而 Facebook 很容易被归为此类公司。

2016 年 11 月，Facebook 澄清了其在 React、React Native 和其他许多项目中广泛采用的开源许可协议方面的立场。与任何法律文本一样，软件许可协议非常难以解释。Facebook 提供了一个 FAQ 来回应经常被问到的问题。其中包括：

1. 如果我创建了一个竞争性产品，那么 Facebook 公司 “BSD 许可证+专利许可协议”中的附加专利授权是否会被终止？
2. 如果我用专利侵权以外的理由起诉 Facebook，那么 Facebook 公司 “BSD许可证+专利许可协议”中的附加专利授权是否会被终止？
3. 如果 Facebook 公司首先起诉我专利侵权，而我反诉 Facebook 公司专利侵权，那么 Facebook 公司 “BSD许可证+专利许可协议”中的附加专利授权是否会被终止？
4. Facebook 公司 “BSD 许可证+专利许可协议”中的附加专利授权的终止是否也会导致版权许可的终止？

对 1、2、4 的回答是明确的“否”，而对于第 3 个问题，FAQ 中规定，反诉主张不得与 Facebook 任何专利相关。上述官方说法比较可靠，在这个 Facebook 即便成为专利流氓也所获甚微的时刻，Facebook 仍然坚持其对 React 许可协议的看法。

使用 React.js 的开发者怎么办？

Apple 和 Microsoft 等行业巨头对于采用 React 的态度令人关注。有报道称，由于担心法律纠纷，这些巨头们已经禁止在项目中使用 React UI 库。但显然这是一个引发争议的问题，因为两家巨头都发布了使用 React 的网络资源或库。

Microsoft 提供了一个用于扩展 PowerPoint 和其他 Office365 产品的 React UI 组件库。Apple 开发者网站上的 API 文档采用 React.js 构建。

以上两款产品都不是两家公司的核心产品，Apple 也不太可能发布一款利用 React Native 编写的 iOS 邮件客户端。值得注意的是，虽然两家公司都看到了利用 React 创建 web 用户界面的价值，但它们的法律部门也没有因此遇到麻烦。

所以对大多数应用案例来说，似乎专利诉讼被严格限制在使用中的具体工具上，在这种情况下无需过分担心。由于使用了宽松的 BSD 许可证，对于开发者来说，React 实际上比使用传染性的 GPL 许可证的库更为安全。

Facebook 公司的数据库引擎 RocksDB 正准备将许可证更改为 Apache 2.0。但 React.js 是一个特殊的项目，Facebook 公司似乎有意继续保留专利条款。

虽然商业实体很乐意在产品中使用 React 授权代码，尽管 WordPress 等许多受欢迎的开源项目仍将继续采用 React，但开源社区对 Facebook 不断捍卫和澄清这种特殊授权感到了厌倦。

因此，如果你想找到类似 Solr 这种采用 React UI 的 Apache 项目，可能还需要很长时间。幸运的是，React 本身并非独一无二，你的项目可以采用与 React 类似的替代品，例如 Preact 或 Inferno，而不用担心遇到 React 的专利授权问题。

参考来源

• https://react-etc.net/entry/your-license-to-use-react-js-can-be-revoked-if-you-compete-with-facebook
• https://react-etc.net/entry/react-patents-facebook-license-faq-adoption-by-apple-and-microsoft
• https://react-etc.net/entry/apache-foundation-bans-use-of-facebook-bsd-patents-licensed-libraries-like-react-js
• https://github.com/facebook/react/blob/master/PATENTS

（题图：facebook.github.io）

编译：

薛亮，北京集慧智佳知识产权管理咨询股份有限公司互联网事业部 高级咨询师，擅长专利检索，专利分析，竞争对手跟踪，FTO分析，开源软件知识产权风险分析，致力于为互联网企业，高科技公司提供知识产权咨询服务。

为什么像 GNU GPL 这样的限制性许可证越来越不受青睐。

“如果你用了任何开源软件， 那么你软件的其他部分也必须开源。” 这是微软前 CEO 巴尔默 2001 年说的， 尽管他说的不对， 还是引发了人们对自由软件的 FUD （ 恐惧， 不确定和怀疑 （ fear, uncertainty and doubt ） ）。 大概这才是他的意图。

对开源软件的这些 FUD 主要与开源许可有关。 现在有许多不同的许可证， 当中有些限制比其他的更严格（也有人称“更具保护性”）。 诸如 GNU 通用公共许可证 （GPL） 这样的限制性许可证使用了 copyleft 的概念。 copyleft 赋予人们自由发布软件副本和修改版的权力， 只要衍生工作保留同样的权力。 bash 和 GIMP 等开源项目就是使用了 GPL(v3)。 还有一个 AGPL（ Affero GPL） 许可证， 它为网络上的软件（如 web service）提供了 copyleft 许可。

这意味着， 如果你使用了这种许可的代码， 然后加入了你自己的专有代码， 那么在一些情况下， 整个代码， 包括你的代码也就遵从这种限制性开源许可证。 Ballmer 说的大概就是这类的许可证。

但宽松许可证不同。 比如， 只要保留版权声明和许可声明且不要求开发者承担责任， MIT 许可证允许任何人任意使用开源代码， 包括修改和出售。 另一个比较流行的宽松开源许可证是 Apache 许可证 2.0，它还包含了贡献者向用户提供专利授权相关的条款。 使用 MIT 许可证的有 JQuery、.NET Core 和 Rails ， 使用 Apache 许可证 2.0 的软件包括安卓， Apache 和 Swift。

两种许可证类型最终都是为了让软件更有用。 限制性许可证促进了参与和分享的开源理念， 使每一个人都能从软件中得到最大化的利益。 而宽松许可证通过允许人们任意使用软件来确保人们能从软件中得到最多的利益， 即使这意味着他们可以使用代码， 修改它， 据为己有，甚至以专有软件出售，而不做任何回报。

开源许可证管理公司黑鸭子软件的数据显示， 去年使用最多的开源许可证是限制性许可证 GPL 2.0，份额大约 25%。 宽松许可证 MIT 和 Apache 2.0 次之， 份额分别为 18% 和 16%， 再后面是 GPL 3.0, 份额大约 10%。 这样来看， 限制性许可证占 35%， 宽松许可证占 34%， 几乎是平手。

但这份当下的数据没有揭示发展趋势。黑鸭子软件的数据显示， 从 2009 年到 2015 年的六年间， MIT 许可证的份额上升了 15.7%， Apache 的份额上升了 12.4%。 在这段时期， GPL v2 和 v3 的份额惊人地下降了 21.4%。 换言之， 在这段时期里， 大量软件从限制性许可证转到宽松许可证。

这个趋势还在继续。 黑鸭子软件的最新数据显示， MIT 现在的份额为 26%， GPL v2 为 21%， Apache 2 为 16%， GPL v3 为 9%。 即 30% 的限制性许可证和 42% 的宽松许可证－－与前一年的 35% 的限制许可证和 34% 的宽松许可证相比， 发生了重大的转变。 对 GitHub 上使用许可证的调查研究证实了这种转变。 它显示 MIT 以压倒性的 45% 占有率成为最流行的许可证， 与之相比， GPL v2 只有 13%， Apache 11%。

引领趋势

从限制性许可证到宽松许可证，这么大的转变背后是什么呢？ 是公司害怕如果使用了限制性许可证的软件，他们就会像巴尔默说的那样，失去自己私有软件的控制权了吗？ 事实上， 可能就是如此。 比如， Google 就禁用了 Affero GPL 软件。

Instructional Media + Magic 的主席 Jim Farmer， 是一个教育开源技术的开发者。 他认为很多公司为避免法律问题而不使用限制性许可证。 “问题就在于复杂性。 许可证的复杂性越高， 被他人因为某行为而告上法庭的可能性越高。 高复杂性更可能带来诉讼”， 他说。

他补充说， 这种对限制性许可证的恐惧正被律师们驱动着， 许多律师建议自己的客户使用 MIT 或 Apache 2.0 许可证的软件， 并明确反对使用 Affero 许可证的软件。

他说， 这会对软件开发者产生影响， 因为如果公司都避开限制性许可证软件的使用，开发者想要自己的软件被使用， 就更会把新的软件使用宽松许可证。

但 SalesAgility（开源 SuiteCRM 背后的公司）的 CEO Greg Soper 认为这种到宽松许可证的转变也是由一些开发者驱动的。 “看看像 Rocket.Chat 这样的应用。 开发者本可以选择 GPL 2.0 或 Affero 许可证， 但他们选择了宽松许可证，” 他说。 “这样可以给这个应用最大的机会， 因为专有软件厂商可以使用它， 不会伤害到他们的产品， 且不需要把他们的产品也使用开源许可证。 这样如果开发者想要让第三方应用使用他的应用的话， 他有理由选择宽松许可证。”

Soper 指出， 限制性许可证致力于帮助开源项目获得成功，方式是阻止开发者拿了别人的代码、做了修改，但不把结果回报给社区。 “Affero 许可证对我们的产品健康发展很重要， 因为如果有人利用了我们的代码开发，做得比我们好， 却又不把代码回报回来， 就会扼杀掉我们的产品，” 他说。 “ 对 Rocket.Chat 则不同， 因为如果它使用 Affero， 那么它会污染公司的知识产权， 所以公司不会使用它。 不同的许可证有不同的使用案例。”

曾在 Gnome、OpenOffice 工作过，现在是 LibreOffice 的开源开发者的 Michael Meeks 同意 Jim Farmer 的观点，认为许多公司确实出于对法律的担心，而选择使用宽松许可证的软件。 “copyleft 许可证有风险， 但同样也有巨大的益处。 遗憾的是人们都听从律师的， 而律师只是讲风险， 却从不告诉你有些事是安全的。”

巴尔默发表他的错误言论已经过去 15 年了， 但它产生的 FUD 还是有影响－－即使从限制性许可证到宽松许可证的转变并不是他的目的。

via: http://www.cio.com/article/3120235/open-source-tools/what-the-rise-of-permissive-open-source-licenses-means.html

作者：Paul Rubens 译者：willcoderwang 校对：jasminepeng

本文由 LCTT 原创编译，Linux中国 荣誉推出

如果你在开源项目中花费了很多时间的话，你可能会看到使用的术语 “copyleft”（GNU 官方网站上的释义：中文，英文）。虽然这个术语使用比较普遍，但是很多人却不理解它。软件许可是一个至少不亚于文件编辑器和打包格式的激烈辩论的主题。专家们对 copyleft 的理解可能会充斥在好多书中，但是这篇文章可以作为你理解 copyleft 启蒙之路的起点。

什么是 copyright？

在我们可以理解 copyleft 之前，我们必须先介绍一下 copyright 的概念。copyleft 并不是一个脱离于 copyright 的法律框架，copyleft 存在于 copyright 规则中。那么，什么是 copyright？

它的准确定义随着司法权的不同而不同，但是其本质就是：作品的作者对于作品的 复制 （ copying ） （因此这个术语称之为 “copyright”：copy 's right）、表现等有一定的垄断性。在美国，其宪法明确地阐述了美国国会的任务就是制定版权法律来“促进科学和实用艺术的进步”。

不同于以往，版权会立刻附加到作品上——而且不需要注册。默认情况下，所有的权力都是保留的。也就是说，没有经过作者的允许，没有人可以重新出版、表现或者修改作品。这种“允许”就是一种许可，可能还会附加有一定的条件。

如果希望得到对于 copyright 更彻底的介绍，Coursera 上的教育工作者和图书管理员的著作权是一个非常优秀的课程。

什么是 copyleft？

先不要着急，在我们讨论 copyleft 是什么之前，还有一步。首先，让我们解释一下 开源 （ open source ） 意味着什么。所有的开源许可协议，按照 开源倡议的定义 （ Open Source Inititative's definition ） （规定），除其他形式外，必须以源码的形式发放。获得开源软件的任何人都有权利查看并修改源码。

copyleft 许可和所谓的 “ 自由 （ permissive ） ” 许可不同的地方在于，其衍生的作品中，也需要相同的 copyleft 许可。我倾向于通过这种方式来区分两者不同： 自由 （ permissive ） 许可向直接下游的开发者提供了最大的自由（包括能够在闭源项目中使用开源代码的权力），而 copyleft 许可则向最终用户提供最大的自由。

GNU 项目为 copyleft 提供了这个简单的定义（中文，英文）：“ 规则就是当重新分发该程序时，你不可以添加限制来否认其他人对于[自由软件]的自由。 （ the rule that when redistributing the program, you cannot add restrictions to deny other people the central freedoms [of free software]. ） ”这可以被认为权威的定义，因为 GNU 通用许可证 （ GNU General Public License，GPL ） 的各种版本的依然是最广泛使用的 copyleft 许可。

软件中的 copyleft

GPL 家族是最出名的 copyleft 许可，但是它们并不是唯一的。 Mozilla 公共许可协议 （ Mozilla Public License，MPL ） 和 Eclipse 公共许可协议 （ Eclipse Public License，EPL ） 也很出名。很多其它的 copyleft 许可 也有较少的采用。

就像之前章节介绍的那样，一个 copyleft 许可意味着下游的项目不可以在软件的使用上添加额外的限制。这最好用一个例子来说明。如果我写了一个名为 MyCoolProgram 的程序，并且使用 copyleft 许可来发布，你将有使用和修改它的自由。你可以发布你修改后的版本，但是你必须让你的用户拥有我给你的同样的自由。（但）如果我使用 “ 自由 （ permissive ） ” 许可，你将可以将它自由地合并到一个不提供源码的闭源软件中。

对于我的 MyCoolProgram 程序，和你必须能做什么同样重要的是你必须不能做什么。你不必用和我完全一样的许可协议，只要它们相互兼容就行（但一般的为了简单起见，下游的项目也使用相同的许可）。你不必向我贡献出你的修改，但是你这么做的话，通常被认为一个很好的形式，尤其是这些修改是 bug 修复的话。

非软件中的 copyleft

虽然，copyleft 的概念起始于软件世界，但是它也存在于之外的世界。“做你想做的，只要你保留其他人也有做同样的事的权力”的概念是应用于文字创作、视觉艺术等方面的知识共享署名许可（中文，英文）的一个显著的特点（CC BY-SA 4.0 是贡献于 Opensource.com 默认的许可，也是很多开源网站，包括 Linux.cn 在内所采用的内容许可协议）。GNU 自由文档许可证是另一个非软件协议中 copyleft 的例子。在非软件中使用软件协议通常不被建议。

我是否需要选择一种 copyleft 许可？

关于项目应该使用哪一种许可，可以用（已经有了）成篇累牍的文章在阐述。我的建议是首先将许可列表缩小，以满足你的哲学信条和项目目标。GitHub 的 choosealicense.com 是一种查找满足你的需求的许可协议的好方法。tl;drLegal 使用平实的语言来解释了许多常见和不常见的软件许可。而且也要考虑你的项目所在的生态系统，围绕一种特定语言和技术的项目经常使用相同或者相似的许可。如果你希望你的项目可以运行的更出色，你可能需要确保你选择的许可是兼容的。

关于更多 copyleft 的信息，请查看 copyleft 指南。

（题图来自：behance.net）

via: https://opensource.com/resources/what-is-copyleft

作者：Ben Cotton 译者：yangmingming 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

谷歌是开源领域领先的贡献者之一，但是这个搜索巨头不是所有的开源许可证都喜欢。

来自多伦多的报道：Marc Merlin 从 2002 年起就在谷歌担任工程师，至今已经做了许多开源和 Linux 相关的工作。在本周召开的 LinuxCon 北美峰会上，Merlin 发表了演讲，为大家揭示了谷歌是如何使用开源和为开源做贡献的。

“没有开源软件就没有今天的谷歌”，Merlin 说。

Merlin 讲到，谷歌早期回馈到开源社区的资源有限，谷歌的第一代软件全都是写给内部用的，最初并不是为开源而设计的。他接着补充说，事实上开源并不是一件简单的事。也就是说，谷歌早期的软件最初并没有准备开源，不过谷歌发表了技术性论文描述了使用的方法和代码，以便其他人也可以用同样的原理来实现。

Marc Merlin at LinuxCon North America

在各种开源技术领域，谷歌早期的贡献主要是错误修复。

“我们通常是第一个发现并修复那些只在我们这个量级出现的错误的”，Merlin 说。

到现在，Merlin 说谷歌已经为 Linux 内核贡献了超过 5000 个补丁，补丁涵盖了从小的修复到完整的驱动程序和类似容器这样的子系统。

随着谷歌在开源领域的努力，现在已经在 GitHub 上发布了超过 3000 个开源项目。为了以法律的角度来管理整个过程，Merlin 说谷歌有六个人专门在内部从事使用和发布开源软件的合规管理。

为了保证法律上的一致性，谷歌将所有外部的开源代码存储在一个第三方体系内。Merlin 补充说，谷歌只允许使用谷歌能够遵循的许可证的开源软件。其中一个不能接受的许可证是 AGPL （Affero General Public License），它是一个互惠的许可证，要求使用该代码需提供一个到源代码的链接。

“确保我们没有在任何对外的产品中使用 AGPL 代码的代价太高，相较而言，不如找一个限制性更少的替代品或我们自己写一个”，Merlin 说。

对于那些贡献给谷歌项目的代码，谷歌要求开发者接受一个 贡献者许可协议 （ Contributor License Agreement ） （CLA），该 CLA 主要是让谷歌可以对贡献的代码重新颁发许可证，并为谷歌提供代码的专利授权。

“你仍然拥有你的代码，你只是授予谷歌一个许可而已”，Merlin 说。

合作是开源的一部分。OIN 的 CEO Keith Bergelt 解释说，开放创新网络（Open Invention Network）模式允许众多企业和公司决定它们该在哪较量，在哪合作。随着开源的演变，“我们需要为合作创造渠道，否则我们将会有几百个团体把数十亿美元花费到同样的技术上。”

开放创新网络（Open Invention Network），即 OIN，正在全球范围内开展让 Linux 远离专利诉讼的伤害的活动。它的努力得到了一千多个公司的热烈回应，它们的加入让这股力量成为了历史上最大的反专利管理组织。

开放创新网络以白帽子组织的身份创建于2005年，目的是保护 Linux 免受来自许可证方面的困扰。包括 Google、 IBM、 NEC、 Novell、 Philips、 Red Hat 和 Sony 这些成员的董事会给予了它可观的经济支持。世界范围内的多个组织通过签署自由 OIN 协议加入了这个社区。

创立开放创新网络的组织成员把它当作利用知识产权保护 Linux 的大胆尝试。它的商业模式非常的难以理解。它要求它的成员采用免版权许可证，并永远放弃由于 Linux 相关知识产权起诉其他成员的机会。

然而，从 Linux 收购风波——想想服务器和云平台——那时起，保护 Linux 知识产权的策略就变得越加的迫切。

在过去的几年里，Linux 的版图曾经历了一场变革。OIN 不必再向人们解释这个组织的定义，也不必再解释为什么 Linux 需要保护。据 OIN 的 CEO Keith Bergelt 说，现在 Linux 的重要性得到了全世界的关注。

“我们已经见到了一场人们了解到 OIN 如何让合作受益的文化变革，”他对 LinuxInsider 说。

如何运作

开放创新网络使用专利权的方式创建了一个协作环境。这种方法有助于确保创新的延续。这已经使很多软件厂商、顾客、新型市场和投资者受益。

开放创新网络的专利证可以让任何公司、公共机构或个人免版权使用。这些权利的获得建立在签署者同意不会专为了维护专利而攻击 Linux 系统的基础上。

OIN 确保 Linux 的源代码保持开放的状态。这让编程人员、设备厂商、独立软件开发者和公共机构在投资和使用 Linux 时不用过多的担心知识产权的问题。这让对 Linux 进行重新打包、嵌入和使用的公司省了不少钱。

“随着版权许可证越来越广泛的使用，对 OIN 许可证的需求也变得更加的迫切。现在，人们正在寻找更加简单或更实用的解决方法”，Bergelt 说。

OIN 法律防御援助对成员是免费的。成员必须承诺不对 OIN 名单上的软件发起专利诉讼。为了保护他们的软件，他们也同意提供他们自己的专利。最终，这些保证将让几十万的交叉许可通过该网络相互连接起来，Bergelt 如此解释道。

填补法律漏洞

“OIN 正在做的事情是非常必要的。它提供另一层 IP （知识产权）保护，”休斯顿法律中心大学的副教授 Greg R. Vetter 这样说道。

他回答 LinuxInsider 说，第二版 GPL 许可证被某些人认为提供了隐含的专利许可，但是律师们更喜欢明确的许可。

OIN 所提供的许可填补了这个空白。它还明确的覆盖了 Linux 内核。据 Vetter 说，明确的专利许可并不是 GPLv2 中的必要部分，但是这个部分被加入到了 GPLv3 中。（LCTT 译注：Linux 内核采用的是 GPLv2 的许可）

拿一个在 GPLv3 中写了10000行代码的代码编写者来说。随着时间推移，其他的代码编写者会贡献更多行的代码，也加入到了知识产权中。GPLv3 中的软件专利许可条款将基于所有参与的贡献者的专利，保护全部代码的使用，Vetter 如此说道。

并不完全一样

专利权和许可证在法律结构上层层叠叠互相覆盖。弄清两者对开源软件的作用就像是穿越雷区。

Vetter 说“通常，许可证是授予建立在专利和版权法律上的额外权利的法律结构。许可证被认为是给予了人们做一些的可能会侵犯到其他人的知识产权权利的事的许可。”

Vetter 指出，很多自由开源许可证（例如 Mozilla 公共许可、GNU GPLv3 以及 Apache 软件许可）融合了某些互惠专利权的形式。Vetter 指出，像 BSD 和 MIT 这样旧的许可证不会提到专利。

一个软件的许可证让其他人可以在某种程度上使用这个编程人员创造的代码。版权对所属权的建立是自动的，只要某个人写或者画了某个原创的东西。然而，版权只覆盖了个别的表达方式和衍生的作品。他并没有涵盖代码的功能性或可用的想法。

专利涵盖了功能性。专利权还可以被许可。版权可能无法保护某人如何独立地开发对另一个人的代码的实现，但是专利填补了这个小瑕疵，Vetter 解释道。

寻找安全通道

许可证和专利混合的法律性质可能会对开源开发者产生威胁。据 Chaotic Moon Studios 的创办者之一、 IEEE 计算机协会成员 William Hurley 说，对于某些人来说，即使是 GPL 也会成为威胁。

“在很久以前，开源是个完全不同的世界。被彼此间的尊重和把代码视为艺术而非资产的观点所驱动，那时的程序和代码比现在更加的开放。我相信很多为最好的愿景所做的努力几乎最后总是背负着意外的结果，”Hurley 这样告诉 LinuxInsider。

他暗示说，成员人数超越了1000人（的组织）可能会在知识产权保护重要性方面意见不一。这可能会继续搅混开源生态系统这滩浑水。

“最终，这些显现出了围绕着知识产权的常见的一些错误概念。拥有几千个开发者并不会减少风险——而是增加。给出了专利许可的开发者越多，它们看起来就越值钱，”Hurley 说。“它们看起来越值钱，有着类似专利的或者其他知识产权的人就越可能试图利用并从中榨取他们自己的经济利益。”

共享与竞争共存

竞合策略是开源的一部分。OIN 模型让各个公司能够决定他们将在哪竞争以及在哪合作，Bergelt 解释道。

“开源演化中的许多改变已经把我们移到了另一个方向上。我们必须为合作创造渠道。否则我们将会有几百个团体把数十亿美元花费到同样的技术上，”他说。

手机产业的革新就是个很好的例子。各个公司放出了不同的标准。没有共享，没有合作，Bergelt 解释道。

他说：“这让我们在美国接触技术的能力落后了七到十年。我们接触设备的经验远远落后于世界其他地方的人。在我们用不上 CDMA (Code Division Multiple Access 码分多址访问通信技术)时对 GSM (Global System for Mobile Communications 全球移动通信系统) 还沾沾自喜。”

改变格局

OIN 在去年经历了激增400个新许可的增长。这意味着着开源有了新趋势。

Bergelt 说：“市场到达了一个临界点，组织内的人们终于意识到直白地合作和竞争的需要。结果是两件事同时进行。这可能会变得复杂、费力。”

然而，这个由人们开始考虑合作和竞争的文化革新所驱动的转换过程是可以接受的。他解释说，这也是一个人们怎样拥抱开源的转变——尤其是在 Linux 这个开源社区的领导者项目。

还有一个迹象是，最具意义的新项目都没有在 GPLv3 许可下开发。

二个总比一个好

“GPL 极为重要，但是事实是有一堆的许可模型正被使用着。在 Eclipse、Apache 和 Berkeley 许可中，专利问题的相对可解决性通常远远低于在 GPLv3 中的。”Bergelt 说。

GPLv3 对于解决专利问题是个自然的补充——但是 GPL 自身不足以独自解决围绕专利使用的潜在冲突。所以 OIN 的设计是以能够补充版权许可为目的的，他补充道。

然而，层层叠叠的专利和许可也许并没有带来多少好处。到最后，专利在几乎所有的案例中都被用于攻击目的——而不是防御目的，Bergelt 暗示说。

“如果你不准备对其他人采取法律行动，那么对于你的知识产权来说专利可能并不是最佳的法律保护方式”，他说。“我们现在生活在一个对软件——开放的和专有的——误会重重的世界里。这些软件还被错误而过时的专利系统所捆绑。我们每天在工业化和被扼杀的创新中挣扎”，他说。

法院是最后的手段

想到 OIN 的出现抑制了诉讼的泛滥就感到十分欣慰，Bergelt 说，或者至少可以说 OIN 的出现扼制了特定的某些威胁。

“可以说我们让人们放下他们的武器。同时我们正在创建一种新的文化规范。一旦你入股这个模型中的非侵略专利，所产生的相关影响就是对合作的鼓励”，他说。

如果你愿意承诺合作，你的第一反应就会趋向于不急着起诉。相反的，你会想如何让我们允许你使用我们所拥有的东西并让它为你赚钱，而同时我们也能使用你所拥有的东西，Bergelt 解释道。

“OIN 是个多面的解决方式。它鼓励签署者创造双赢协议”，他说，“这让起诉成为最逼不得已的行为。那才是它的位置。”

底线

Bergelt 坚信，OIN 的运作是为了阻止 Linux 受到专利伤害。在这个需要 Linux 的世界里没有诉讼的地方。

唯一临近的是与微软的移动之争，这关系到行业的发展前景（原文： The only thing that comes close are the mobile wars with Microsoft, which focus on elements high in the stack. 不太理解，请指正。）。那些来自法律的挑战可能是为了提高包括使用 Linux 产品的所属权的成本，Bergelt 说。

尽管如此“这些并不是有关 Linux 诉讼”，他说。“他们的重点并不在于 Linux 的核心。他们关注的是 Linux 系统里都有些什么。”

via: http://www.linuxinsider.com/story/Defending-the-Free-Linux-World-81512.html

作者：Jack M. Germain 译者：H-mudcup 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出