开源软件基于以下原则：应免费提供给任何人使用，分发或改进。开源理想的倡导者认为，免费提供的源代码将鼓励代码的更广泛的分发和使用，从而推动进一步的创新和改进。考虑到当今软件应用程序的复杂性以及典型的模块化或基于对象的设计，开源软件为开发人员提供了显着的效率，他们可以将精力集中在核心产品和技术上，而无需为某些启用或外围代码重新设计轮子。
许多开放源代码项目的用户和贡献者社区不断增长，已使它们成熟成为当今互联网大部分骨干网中必不可少的技术。如今，大多数网站都使用诸如Apache Web服务器之类的开源软件。同样，MySQL，MariaDB，Postgres，Cassandra，Redis，MongoDB和Neo4J等数据库技术也支持现代Internet基础结构。对于使用这些成熟的开源技术的公司而言，好处之一就是能够围绕已经在市场上得到证明的产品进行商业化，并且该产品具有比专有解决方案所能提供的更大的支持者。而且由于贡献者基础庞大，因此开源软件通常比仅作为最终手段而开发的许多内部解决方案更强大。
开源项目使用版权许可，以确保其源代码可自由使用，并且可以轻松地将软件的改进提供回开源社区。一些著名的开源许可证已成为提供管理法律对开源项目的知识产权贡献的法律框架的重要手段。这些通常是开放源代码倡议（OSI）批准的满足其“开放源代码定义”标准的许可证。1一些开放源代码许可证，例如MIT，BSD或Apache许可证，在允许被许可方方面是“允许的”修改软件以创建可能根据不同版权许可获得许可的衍生作品。通常仅要求被许可方在源代码中包括许可证的副本。其他开放源代码许可（例如GNU通用公共许可（GPL））提出了要求，即基于该软件的任何发行版或派生作品都必须以相同的许可条款公开提供源代码。这些许可证有时称为“ copyleft”。
开源社区中的一些人对现有的开源许可证不足以保护版权所有者利用其软件获利的能力表示关注。尽管开源软件是免费提供的，但这并不意味着它必须免费。但是，开发开放源代码软件的公司通常会在源代码已经公开可用的情况下很难销售其软件。公司可以通过与该软件相关的托管，咨询或支持服务获利。理想情况下，可以将此类工作的至少一部分收益重新投资于进一步开发和改进开源软件以及管理其开源项目。
基于云的服务（例如软件即服务（SaaS），平台即服务（PaaS）和基础架构即服务（IaaS））的激增凸显了其中一些获利能力关注。未对开源项目做出贡献的云服务提供商可以免费获取开源软件的副本，将其重新命名为自己的软件，然后将其作为基于云的应用程序收费使用。在这种情况下，云服务提供商可能不会将其任何收益再投资于改进软件或管理开源项目。结果，从开源软件中产生收入的公司不一定是已经对其开发进行投资的公司（通常是大量投资）。
Commons条款是作为许可条件而开发的，可以响应于使云服务提供商从自由获取的开源软件中获利的明显不公平现象而添加到常规的开源许可中，而该软件的作者和贡献者可能不会获得任何补偿。为他们的工作。 Commons条款旨在迫使开放源代码软件的开发人员与“那些利用开源开发的掠夺性商业优势的开发人员”进行谈判。2那些希望出售根据Commons条款获得许可的软件的人，必须进行谈判，并单独谈判。获得开放源代码软件开发人员的许可，以从其开放源代码项目中重命名软件并从中获利。
Commons条款于2018年8月在开源社区中变得更加突出，当时流行的Redis内存数据库的制造商Redis Labs将该条款作为其许多Redis模块的Apache 2.0许可的合同约定。这些模块是用于增强或向核心Redis数据库添加功能的软件，该数据库本身仍根据许可的BSD许可证进行许可。3在更改许可之前，Redis模块已根据创建的Affero通用公共许可证（AGPL）4进行了许可。解决用于SaaS和其他基于云的应用程序的开源软件。 AGPL旨在解决GPL系列许可证中的漏洞，因为它们的源代码公开要求仅由分发许可软件来触发，并且这种“分发触发器”不适用于从未分发过的基于云的产品。 AGPL解决了源代码公开要求，但并未解决上述获利问题。
在Redis模块的许可使用Commons Clause从AGPL更改为Apache 2.0时，Redis Labs的联合创始人兼CTO在博客文章中解释道：
多年以来，云提供商一直在利用开放源代码社区的优势，他们以他们未开发的开放源代码（例如Docker，Spark，Hadoop，Redis，Elasticsearch等）出售（价值几亿美元）。这不鼓励社区投资开发开源代码，因为任何潜在的利益都将流向云提供商，而不是代码开发人员或其赞助商。
尽管如此，Redis Labs最终在许可其Redis模块时停止使用Commons子句。下议院条款的这种示例性的兴衰象征了这种许可条款可能提供的利弊平衡。在这里，我们考虑了公共条款以及在决定是否修改现有开放源代码许可证时可能出现的竞争性政策问题。
The Commons Clause
Commons条款是一项契约条款，可以添加到现有的开放源代码许可证中，以限制许可软件的销售。它是在数家开源公司之间协调后于2018年初创建的，由FOSSA公开提供。6关于开源许可证（“许可证”），该条款在相关部分中指出：
在不限制许可中的其他条件的情况下，许可下的权利授予将不包括，并且许可也不会授予您销售软件的权利。
出于上述目的，“出售”是指出于许可或其他考虑（包括但不限于与托管服务相关的托管或咨询/支持服务的费用），行使许可下授予您的任何或全部权利，以提供给第三方软件），其价值完全或实质上来源于软件功能的产品或服务。许可证要求的任何许可证声明或出处，也必须包括本“公共条款”许可条件声明。
因此，《通用条款》禁止云服务提供商复制开源软件，对其进行品牌重塑，以及出售其价值完全或实质上源于该软件功能的基于云的产品或服务。该条款类似地不允许云服务提供商通过其价值完全或实质上源自软件功能的任何产品或服务来通过“托管或咨询/支持服务”获利。但是，只要不向用户收取访问软件功能的费用，云服务提供商仍可以将开源软件作为产品或服务提供。
Commons子句的文档明确表明它不符合开放源代码许可的要求。例如，它增加了对销售许可软件的限制，该限制不能满足OSI开源定义中的某些标准。8相反，Commons子句将开放源代码许可证转换为“可用资源”许可证，同时具有更严格的限制。而不是许可许可，它试图提供比版权许可更大的商业自由。将Commons子句添加到开放源代码许可后，原始许可的所有权限都将保留，除了可以“出售” Commons子句中定义的软件。因此，开放源代码许可证不等同于由Commons条款修改的同一许可证。例如，在Redis Labs的情况下，Redis模块在Apache 2.0许可下通过Commons Clause（可从源获得的许可）获得许可，这与单独的Apache 2.0许可（开源许可）不同。
将Commons子句添加到开源许可证中的优点
Commons条款旨在防止大型的基于云的服务提供商在不向开源社区回馈的情况下出售开源软件并从中受益。虽然对许多许可的开放源代码许可证没有固有的商业限制，但通常不鼓励使用对社区贡献很小或没有贡献的开放源代码项目。此外，可以理解的是，向社区提供开放源代码软件的开发人员希望保护自己的知识产权，防止其与他们直接竞争，并希望通过开发开放源代码软件来获得投资回报。
下议院条款可以成为实现这些目标的有效工具。它使版权所有者（通常是开发人员）可以控制哪些公司可以从使用开源软件的功能中获利。它还为版权拥有者提供了杠杆作用，可以与第三方（例如云服务提供商）进行进一步谈判，后者可能希望将软件作为服务出售，但在开源项目中不活跃。
此外，Commons条款对基础和公认的开源许可证的使用使该条款具有某些固有的权限。以这种方式来看，Commons条款只是对早已接受并建立良好的开放源代码许可证的微小改动。例如，熟悉常规开源许可证（例如Apache 2.0许可证）的软件开发人员将理解，当该许可证与Commons子句结合使用时，该许可证的所有规定仍然适用，后者仅向现有的条款中添加了另一项规定执照。因此，带有Commons子句的Apache 2.0许可证包括Apache 2.0许可证的所有预期条款。另外，由于Commons子句除销售条款外没有限制开放源代码软件，因此它仍然允许分发和修改源代码，更重要的是允许社区提供帮助。
Commons条款还不要求每个参与开发的公司或公司都使用双重许可策略或开放核心许可模型来协商单独的许可。例如，使用双重许可策略，软件产品可以根据基于云的应用程序的专有许可获得许可，而对于其他用途则可以根据单独的开源许可获得许可。在这种情况下，可能会要求每个云服务提供商获得专有许可才能在基于云的产品中使用该软件并向版权所有者提供赔偿，而该软件的其他用户可能会在许可的开放源代码许可下单独获得许可，例如Apache，MIT或BSD许可证。相比之下，下议院条款可能会达到类似的结果，而不会产生管理和谈判多个许可证的管理开销和相关成本，因为它在单个开放源代码许可证中增加了销售限制条款，该许可证可用于所有被许可方。
相对于开放核心模型，Commons子句具有类似的优势。使用这种许可模式，公司可以通过在许可的开源许可下分发“核心”软件产品来限制云服务提供商对某些软件的使用，尽管其支持模块是在专有许可下许可的。像双重许可策略一样，与使用Commons条款为所有被许可人修改单个开源许可相比，开放核心模型可能需要更多的开销和成本来管理和协商多个许可。
最后，用Commons条款修改的开源许可证也可能比AGPL更可取，因为AGPL无法阻止云服务提供商在基于云的应用程序中出售开源软件的功能，而不会通过补偿或补偿来补偿开源社区。贡献回开源项目。 AGPL也因其自身的含糊和疑虑而受到批评。9由于许多公司由于这些原因未采用AGPL，因此Commons条款可能为基于云的应用程序中的开源软件许可提供更好的选择。
在开放源代码许可中使用公共条款的缺点
下议院条款不乏批评者。尽管具有上述优点，但Commons子句的许多方面引起了开源社区成员的关注。尽管Commons子句的既定目标是成为众所周知的和易于理解的开源许可证的基础上的简单合同约定，但有效地将许可证转换为非开源许可证。在选择项目的情况下，这尤其会造成问题，因为它使用OSI批准的许可证。作为公司政策，许多公司将仅使用经OSI批准的许可证许可的开源软件，以确保它们符合开源理想。但是，由于增加了销售限制，公共条款将OSI批准的许可证更改为不满足OSI开源定义的许可证，这可能会危害此类项目的采用。同样，一些开发人员可能将Commons子句视为放弃了开源软件的宗旨，并避免为此类项目做出贡献。
使用Commons子句在许可证命名上的相似性也可能会误导或在开源社区中引起混乱。以Redis Labs许可为例，“带有Commons子句的Apache 2.0许可”或“由Commons子句修改的Apache 2.0许可”与Apache 2.0许可并不相同。开发人员可能会因其名称的相似性而错误地认为这些许可证可以解释为与Apache 2.0许可证完全相同，这可能会导致无意中违反了Commons子句添加的销售限制。
此外，由于《通用条款》对开放源代码许可证增加了销售限制，因此一些批评者表示担心，这可能是一个滑坡，其中可能会将多个可能的合同骑手或骑手组合添加到同一开放源代码许可证中，从而导致具有相似名称的不同有效许可证。除了Commons子句外，您还可以想象其他有关开源许可证的提议子句，例如，限制系统类型，存储形式，分发方法，复制类型等。这可能会导致混乱的开源环境，其中多个不同的许可证具有相似的名称。例如，假设第1-5条是作为单独的合同条款创建的，每个条款都可以单独添加到常规的三条款BSD许可证中。在此示例中，区分由附加条款的各种组合修改的BSD许可证（例如，由条款1、3和4修改的BSD许可证与由条款2、3和5修改的BSD许可证）可能会造成混淆。等等。
此外，对“普通条款”的批评者认为，该术语的模棱两可。通用条款限制了“其产品的全部或实质价值来自软件功能的产品或服务”的销售。通用条款文档认为“实质上”是一个常见的法律术语，10但是，该条款或条件未能提供明确的有关允许或禁止的活动的指南。例如，如果用户向云服务提供商支付固定的订阅费，以访问由多个软件模块组成的SaaS应用程序，其中一个软件模块需受Commons条款的许可，那么如何在所有模块功能之间分配订户费用？ ？如果受“通用条款”约束的功能是否在费用范围内，但用户从未真正访问过，这有关系吗？此外，如果该费用仅用于内部或公司内部会计目的，并不代表各方之间的公平交易，该怎么办？11
通用条款在禁止销售任何其价值完全或很大程度上源自软件功能的产品或服务的“与软件相关的托管或咨询/支持服务”方面也含糊不清。对此条款的通俗了解表明，云服务提供商不能免费托管许可的软件，并且不能向客户支持或咨询与该软件功能有关的费用（例如，如何使用该软件）。 Commons Clause文档是指讨论板，建议可以进行咨询，但该条款的语言和在线讨论的内容似乎有其他建议。12
我们从这里去哪里？
在开放源代码社区中，关于Commons条款的争论可能会继续，因为公司和开发人员都在努力在开放源代码运动的基础上找到开放和自由软件理想之间的平衡，以及需要开放源代码公司将其创新和创新货币化的需求。在市场上蓬勃发展。公司和开发人员可能会继续对第三方获取其开源软件并在竞争激烈的市场中对他们使用该软件产生合理的担忧。
下议院条款提出了一种实现这种平衡的潜在解决方案，但如上所述，这并非没有其自身的复杂性。虽然Commons条款在已知的开放源代码许可证中添加了销售限制条款，以防止云服务提供商对代码进行不良的掠夺性使用，但它也会在其修改的许可证中产生歧义，并将经OSI批准的已建立许可证转换为未批准，未开放的许可证源许可证。
Redis Labs通过并拒绝Commons条款的决定表明了它的不确定性。如上所述，Redis Labs最初根据AGPL许可了某些Redis模块，然后使用Commons子句将这些许可转换为Apache 2.0。 Redis最终再次更改了这些许可证，而是选择创建自己的专有Redis源可用许可证（RSAL）。 RSAL旨在向大多数用户授予与开放源代码许可等效的权利，但限制了许可软件不能用于数据库，缓存引擎，流处理引擎，搜索引擎，索引引擎或ML / DL / AI服务引擎。13因此，Redis Labs更改了防止云服务提供商通过将具有销售限制的源可用许可证（带有Commons子句的Apache 2.0）切换为具有销售限制的源可用许可证来从其Redis模块中获利的策略。使用范围限制（RSAL）。
当Redis Labs首次对Commons子句进行更改时，在开源社区中有赞成或反对其使用的强烈意见。14最终，Redis Labs决定放弃该条款，并确定了以下注意事项：术语“ Apache2已修改通过Commons Clause”引起了一些用户的困惑，他们认为他们仅受Apache 2.0许可条款的约束。普通条款中的“实质性”一词不清楚；并且关于“支持”的公共条款限制似乎与Redis Labs围绕Redis模块发展生态系统的意图背道而驰。15
尽管事后普遍认为Redis Labs采用Commons条款是修改OSI批准的开源许可证问题的案例研究，但Redis Labs试图解决的基本问题仍然存在。想要使用开源社区并为之做出贡献的公司必须继续寻找方法，同时保护其投资和知识产权。这些动机必须与创建新许可证或修改现有许可证，可能疏远开源社区，扼杀采用或阻止对项目的有意义贡献的风险进行权衡。尽管Redis Labs在Commons子句中的经验可能是一个警告，但它也暴露了公司和开发人员在使用开源软件时必须做出的许多与许可相关的选择。
尾注
1 See The Open Source Definition, Open Source Initiative, https://opensource.org/osd (last modified Mar. 22, 2007).
2 Commons Clause, https://commonsclause.com (last visited Oct. 2, 2019).
3 See Yiftach Shoolman, Redis’ License Is BSD and Will Remain BSD, Redis Labs (Aug. 22, 2018), https://redislabs.com/blog/redis-license-bsd-will-remain-bsd.
4 See Sarah Schlothauer, Is Commons Clause Open Source? Weighing In on the Redis License Change, JAXenter (Aug. 23, 2018), https://jaxenter.com/redis-commons-clause-open-source-148558.html.
5 Shoolman, Redis’ License Is BSD, supra note 3.
6 See Salil Deshpande, Commons Clause Stops Open-Source Abuse, TechCrunch (Sept. 7, 2018), https://techcrunch.com/2018/09/07/commons-clause-stops-open-source-abus…;Commons Clause, GitHub, https://github.com/fossas/commons-clause (last updated Dec. 4, 2018).
7 Commons Clause, supra note 2.
8 See The Open Source Definition, supra note 1 (“The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources.” (emphasis added)).
9 See Commons Clause, supra note 2.
10 Id.
11 See Stephen O’Grady, Tragedy of the Commons Clause, RedMonk (Sept. 10, 2018), https://redmonk.com/sogrady/2018/09/10/tragedy-of-the-commons-clause.
12 Commons Clause, supra note 2; see Tobias Davis, Preventing Specialized Consultants?, GitHub (Aug. 22, 2018), https://github.com/fossas/commons-clause/issues/4.
13 See Yiftach Shoolman, Redis Labs’ Modules License Changes, Redis Labs (Feb. 21, 2019), https://redislabs.com/blog/redis-labs-modules-license-changes.
14 See Steven J. Vaughan-Nichols, Open-Source Licensing War: Commons Clause, ZDNet (Aug. 28, 2018), https://www.zdnet.com/article/open-source-licensing-war-commons-clause.
15 See Shoolman, Redis Labs’ Modules, supra note 13.
本文：http://jiagoushi.pro/node/911
讨论：请加入知识星球或者微信圈子【首席架构师圈】