共享、免费还是公有？开源软件的真正定义
如果你认为开源软件是共享软件、免费软件和公有领域软件的代名词，那么你并不是唯一有这种看法的人。当你听到“ 开源软件 （ 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 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。
非标准的开源贡献者许可协议正在创造类似电影《冲出人魔岛》中“人魔”般的怪物。当我开启作为开源律师的职业生涯时，面临的一个重要问题是需要耗时费力去分析的新形式开源许可协议的激增，正如我的同事 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 2.0许可证中的专利许可条款？
提要：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 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。
明确是避免许可歧义的关键所在。在许可证的过去、当前和未来版本如何适用于软件程序方面，GPL 系列许可证在开源许可证中可谓独树一帜。如果不能完全理解其中独有的许可证特性，开源软件开发人员可能会无意中造成混淆。GPL 许可证在其许可证的条款和条件中阐明了许可证版本如何适用于该程序。GPL v2（第 9 条）写到：“每个版本都有一个独特的版本号，如果该程序指定了其适用的许可证的版本号以及‘任何更新的版本’，则可以选择遵循由 自由软件基金会 （ Free Software Foundation ） 发布的该版本或之后任何更新版本的条款和条件。如果该程序未指定许可证的版本号，则可以选择自由软件基金会以前发布的任何版本。”GPL v3 第 14 条与 GPL v2 中的上述条款非常相似。多年以来，我看到很多开源项目表示遵循 GPL 许可证，但却没有明确指出版本号，同时也没有将整个 GPL 许可证（例如，v2 或 v3）副本囊括在程序内。取决于您是许可人还是被许可人等因素，这其中造成的含混不清可能对您有益或有害。许可证的模糊如何产生影响例如，假设应用程序的许可证声明：“本程序遵循 GPL 许可证”，并且包含整个 GPL v3 许可证的副本。由于该项目没有明确说明适用该许可证的哪个版本号，所以合理的解释是自由软件基金会发布的所有版本 GPL 许可证都适用——v3、v2 甚至 v1！依据 GPL v3 第 14 条的下述文本可以合乎情理地做出上述理解。“如果该程序未指定 GNU GPL 的版本号，则可以选择由自由软件基金会发布的任何版本。”另一方面，将 GPL 特定版本的完整副本（还可能包括许可证标题块中的 GPL 版本号）包含在程序中，可以被解释为在实质上传递了特定版本的许可证。在这个例子中，那就是 GPL v3 版本并且只有 GPL v3 版本，因为 v3 中没有“任何更新的版本”的条款。如何避免许可歧义为了避免这种许可歧义，您应该写得非常明确。如果您只想适用 GPL v3，应该明确地声明：“本程序仅遵循 GPL v3”，并提供整个 GPL v3 许可证副本。或者，如果您希望适用 GPL v3 或之后更新的版本，请明确声明：“本程序遵循 GPL v3 或其之后更新的版本”。最后，如果您真的想要适用任何版本的 GPL 许可证，您可以提供 GPL v3 许可证，并表示：“本程序遵循由自由软件基金会发布的任何版本的 GPL 许可证”。无论您选择哪种授权方式，都应该非常明确，让每个人都能理解您的真正意图。作者简介：Jeffrey R. Kaufman是全球领先的开源软件解决方案供应商Red Hat公司的开源知识产权律师，还担任托马斯杰斐逊法学院（Thomas Jefferson School of Law）的兼职教授。在任职Red Hat之前，Jeffrey曾担任高通公司（Qualcomm Incorporated）的专利顾问，为首席科学家办公室（Office of the Chief Scientist）提供开源事务咨询。译者简介：薛亮，集慧智佳知识产权咨询公司高级咨询师，擅长专利检索、专利分析、竞争对手跟踪、FTO分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。via: https://opensource.com/article/17/11/avoiding-gpl-confusion作者：Jeffrey Robert Kaufman 译者：薛亮 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
一个开源软件许可证合规的经济高效模式
使用开源的方式有利于你的盈亏底线以及开源生态系统。“ 合规性工业联合体 The Compliance Industrial Complex ” 是一个术语，它会唤起那些组织参与精心设计并且花费昂贵流程的以遵守开源许可条款的反乌托邦想象。由于“生活经常模仿艺术”，许多组织采用了这种做法，可惜的是它们剥夺了许多开源模型的好处。本文介绍了一种经济高效的开源软件许可证合规性方法。开源许可证通常对从第三方授权的代码分发者有三个要求：提供开源许可证的副本包括版权声明对于 copyleft 许可证（如 GPL），将相应的源代码提供给接受者。（与任何一般性声明一样，可能会有例外情况，因此始终建议审查许可条款，如有需要，请咨询律师的意见。）因为源代码（以及任何相关的文件，例如：许可证、README）通常都包含所有这些信息，所以最简单的遵循方法就是随着二进制/可执行程序一起提供源代码。替代方案更加困难并且昂贵，因为在大多数情况下，你仍然需要提供开源许可证的副本并保留版权声明。提取这些信息来结合你的二进制/可执行版本并不简单。你需要流程、系统和人员来从源代码和相关文件中复制此信息，并将其插入到单独的文本文件或文档中。不要低估创建此文件的时间和费用。虽然有工具也许可以自动化部分流程，但这些工具通常需要人力资源（例如工程师、质量经理、发布经理）来准备代码来扫描并对结果进行评估（没有完美的工具，几乎总是需要审查）。你的组织资源有限，将其转移到此活动会增加机会成本。考虑到这笔费用，每个后续版本（主要或次要）的成本将需要进行新的分析和修订。也有因不选择发布不能被很好识别的源码而导致增加的其他成本。这些根源在于不向开源项目的原始作者和/或维护者发布源代码, 这一活动称为上游化。独自上游化一般不满足大多数开源许可证的要求，这就是为什么这篇文章主张与你的二进制/可执行文件一起发布源代码。然而，上游化和提供源代码以及二进制/可执行文件都能提供额外的经济效益。这是因为你的组织不再需要保留随着每次发布合并开源代码修改而产生的私有分支 - 由于你的内部代码库与社区项目不同，这将是越来越消耗和凌乱的工作。上游化还增强了开源生态系统，它会鼓励社区创新，从中你的组织或许也会得到收益。那么为什么大量的组织不会为其产品发布源代码来简化其合规性工作？在许多情况下，这是因为他们认为这可能会暴露他们竞争优势的信息。考虑到这些专有产品中的大量代码可能是开源代码的直接副本，以支持诸如 WiFi 或云服务这些当代产品的基础功能，这种信念可能是错误的。即使对这些开源作品进行了修改来适配其专有产品，这些更改也往往是微不足道的，并包含了很少的新的版权部分或可用来专利的内容。因此，任何组织都应该通过这种方式来查看其代码，因为它可能会发现其代码库中绝大部分是开源的，只有一小部分是真正专有的、与竞争对手区分开来的部分。那么为什么不分发和向上游提交这些没有差别的代码呢？考虑一下拒绝遵从工业联合体的思维方式, 以降低成本并大大简化合规性。使用开源的方式，并体验发布你的源代码的乐趣，以造福于你的盈亏底线和开源生态系统，从中你将继续收获更多的利益。作者简介Jeffrey Robert Kaufman - Jeffrey R. Kaufman 是全球领先的开源软件解决方案提供商红帽公司的开源知识产权律师。Jeffrey 还担任着 Thomas Jefferson 法学院的兼职教授。 在加入红帽前，Jeffrey 在高通担任专利法律顾问，为首席科学家办公室提供开源顾问。 Jeffrey 在 RFID、条形码、图像处理和打印技术方面拥有多项专利。更多关于我（题图： opensource.com）via: https://opensource.com/article/17/9/economically-efficient-model作者：Jeffrey Robert Kaufman 译者：geekpi 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
GNU Affero 通用公共许可证版本 3（AGPLv3）是与 GPLv3 几乎相同的 左版 （ copyleft ） 许可证。两个许可证具有相同的公共版权范围，但在一个重要方面有重大差异。 AGPLv3 的第 13 节规定了 GPLv2 或 GPLv3 中不存在的附加条件：在本许可证的其它条款之外，如果你修改了程序，你必须把你修改的版本，给你的那些使用计算机网络远程（如果你的版本支持此类交互）与之交互的用户，明确提供一个通过一些标准或者常规的复制手段，从网络服务器上免费获得与你所修改的版本相匹配的源码的机会。这个“通过计算机网络远程交互”的范围主要被认为是 SaaS 部署的情形，尽管其实际上读起来的意思超乎了惯例的 SaaS 部署情形。其目标是解决在用户在使用像 Web Services 这样的功能时，其代码没有公开的常规 GPL 协议所暴露出的漏洞。因此，该协议的第 13 节，在 GPLv2 第 3 节以及 GPLv3 和 AGPLv3 第 6 节中包含的目标代码分发的触发要求之外，提供了额外的源代码公开的要求。常常被误解的是，AGPLv3 第 13 节中的源代码分发要求仅在 AGPLv3 软件已被“你”（例如，提供网络服务的实体）修改的地方才触发。我的理解是，只要“你”不修改 AGPLv3 的代码，许可证就不应该被理解为需要按照第 13 节规定的方式访问相应的源码。如我所见，尽管即使公开许可证中不要求公开的源代码也是一个好主意，但在 AGPL 下许多未修改以及标准部署的软件模块根本不会触发第 13 节。如何解释 AGPL 的条款和条件，包括 AGPL 软件是否已被修改，可能需要根据具体情况的事实和细节进行法律层面的分析。作者简介：Jeffrey R. Kaufman 是全球领先的开源软件解决方案提供商 Red Hat 公司的开源 IP 律师。Jeffrey 也是托马斯·杰斐逊法学院的兼职教授。在入职 Red Hat 之前，Jeffrey 曾经担任高通公司的专利顾问，向首席科学家办公室提供开源顾问。Jeffrey 在 RFID、条形码、图像处理和打印技术方面拥有多项专利。via: https://opensource.com/article/17/1/providing-corresponding-source-agplv3-license作者：Jeffrey Robert Kaufman 译者：geekpi 校对：Bestony本文由 LCTT 原创编译，Linux中国 荣誉推出