你正确理解 AGPL 了吗？

引言

最近，Elastic 新增 AGPL 协议的消息登上了社区的热搜，无论是社区的忠实用户、其他开源社区的吃瓜群众，还是其他同类产品的维护者和用户，似乎都在关注这个事情。我读了不少相关的文章，很多讨论说了很多观点，却很少真正触及问题的核心。

为了让大家更清楚地了解这件事，我决定写这篇文章，来详细解析一下这个话题，也算是后到的有感而发吧。与此同时，许多朋友也向我咨询这个问题，所以我也想借此机会从技术层面进行一些澄清。

需要强调的是，本文中的观点仅代表我个人的看法，大家可以作为参考，也欢迎讨论和交流。

AGPL 对我们有什么影响

为了照顾那些可能只有耐心读一两分钟的朋友，我决定打乱一下逻辑，直接把结论写在前面：对大多数人来说，Elastic 新增 AGPL 协议没有实质性的影响。所以，大家可以放心，别被热搜吓到了。

我们都知道，AGPL 是有“传染性”的许可证。简单来说，如果你使用了 AGPL 许可的软件，你的软件也必须采用 AGPL 许可证，这就是大家普遍担心的问题所在。但实际上，AGPL 的影响只有在你直接使用和修改相关代码时才会生效。

如果你压根没有使用和修改呢？

如果你只是把 Elasticsearch 当作一个后端服务（这也是 99% 的用户场景），通过client端，以调用API的方式把 Elasticsearch “集成” 到你的应用中（实际上，这并不叫集成，只是调用或者使用）。那么你使用的仅仅是 Elasticsearch 的客户端代码，而这些代码并不会触发 AGPL 的传染性条款，因为这里只有 Apache 2.0。我们先来看看在 Java 和 Python 中如何引入 Elasticsearch 客户端库，并列出它们的许可证信息：

Java 示例

// 引入 Elasticsearch 客户端库
import org.elasticsearch.client.RestHighLevelClient;
import org.elasticsearch.client.RestClient;
import org.apache.http.HttpHost;
import org.elasticsearch.client.RequestOptions;
import org.elasticsearch.action.search.SearchRequest;
import org.elasticsearch.action.search.SearchResponse;

public class ElasticExample {
    public static void main(String[] args) {
        RestHighLevelClient client = new RestHighLevelClient(RestClient.builder(new HttpHost("localhost", 9200, "http")));
        SearchResponse response = client.search(new SearchRequest("index"), RequestOptions.DEFAULT);
        // 处理搜索结果
    }
}

Python 示例

# 引入 Elasticsearch 客户端库
from elasticsearch import Elasticsearch

def search_index():
    client = Elasticsearch("http://localhost:9200")
    response = client.search(index="index", body={"query": {"match_all": {}}})
    # 处理搜索结果
    return response

客户端库的许可证信息

• Java 客户端库: 由 Apache v2 许可，这是一种宽松的开源许可证，允许自由使用、修改和分发，而不要求公开源代码。

• Python 客户端库: 同样由 Apache v2 许可。

这意味着，无论你使用的是 Java 还是 Python 客户端库，实际上，所有的Elasticsearch客户端都是Apache v2的许可，这些库都不会对你的代码产生“传染性”影响。

这也是为什么说，对我们 99% 的，或许我说得保守了，应该是99.999% 的社区开发者，或者社区用户来说，这个变化是一点影响也没有。同理，SSPL 也是一样的。

如何让自己受影响？

换一个角度来思考，如何让自己能够受 AGPL和SSPL 的影响？我们先来看第一个，就是你把Elasticsearch 服务端的源码集成到你的应用中

使用 Elasticsearch 本身库的示例

这里我们来看一个简单的示例，展示在你应用中直接修改或嵌入了 Elasticsearch 的核心库代码的情况：

// 引入 Elasticsearch 核心库
import org.elasticsearch.node.Node;
import org.elasticsearch.common.settings.Settings;
import org.elasticsearch.node.NodeValidationException;
import org.elasticsearch.client.node.NodeClient;

public class ElasticNodeExample {
    public static void main(String[] args) throws NodeValidationException {
        Settings settings = Settings.builder().put("cluster.name", "myCluster").build();
        Node node = new Node(settings);
        node.start();

        NodeClient client = node.client();
        // 直接与 Elasticsearch 核心库进行交互
    }
}

在这个示例中，代码直接依赖于 Elasticsearch 的核心库（比如：org.elasticsearch.node.Node），并在你的应用中直接启动一个Elasticsearch集群，那么这时，你就可能涉及到AGPL或者SSPL的许可传染性了。

但这仅仅只是涉及，并不意味着你的应用必须也跟着开源，我们还需要进一步分析，因为只有满足特定的条件，你的应用才会被许可传染。接下来让我们看看，AGPL或者SSPL是如何传染的。

AGPL 或者 SSPL 的特点

既然提到了 AGPL 和 SSPL 的传染性，让我们深入了解一下这两种协议的特点，以及它们对开发者和企业的影响。

什么是协议的传染性

传染性，顾名思义，就是当你使用了一段带有特定许可证的代码时，这段代码的许可要求可能会“传染”到你的整个应用中。具体来说，传染性许可证通常要求，如果你使用了带有该许可证的代码，并且在你的应用中进行了修改或组合，你的应用也必须使用相同的许可证发布。

这意味着，当你开发的应用中引入了一个带有传染性许可证的开源库时，哪怕只是使用了一小部分代码，整个应用的许可证要求可能都会受到影响。这也是为什么 google 等大企业不允许在代码中包含或者使用AGPL/SSPL许可的代码。但这并不意味着 google 等企业不会使用 elasticsearch，mongodb, redis, grafana，正如我们开篇所说，要正确理解客户端代码和服务端代码的区别。这两者是不一个 License。

回过头来，也就是说，如果你使用的库是基于 AGPL 的，那么你的整个应用可能也必须采用 AGPL 许可证发布，这也就是“传染性”的由来。

多协议是如何叠加的？

但是，问题往往比这更复杂。如果你的应用中引入了多个开源库，而这些库的许可证宽松度各不相同，比如 Apache 2.0、GNU、MIT、AGPL 等等，那么最终的许可证选择将取决于这些库中最严格的那个。通常情况下，许可证的严格程度将按照以下顺序递增：

• MIT 许可证：非常宽松，基本没有传染性要求，只要求在分发时保留原始的版权声明。
• Apache 2.0 许可证：稍微严格一点，但依然允许修改和分发闭源代码，只要求保留版权声明和通知文件。
• GNU GPL 许可证：开始具有传染性，要求任何基于 GPL 代码的衍生作品也必须采用 GPL 许可证发布。
• AGPL 许可证：在 GPL 的基础上增加了“远程网络交互”条款，进一步扩展了传染性的范围，要求通过网络提供服务的应用也必须开源。

因此，如果你的应用同时使用了 Apache 2.0 和 AGPL 许可证的库，由于 AGPL 是更严格的许可证，你的应用可能会被要求遵守 AGPL 的开源要求。这种情况下，AGPL 的传染性会覆盖掉 Apache 2.0 的宽松性，迫使整个应用采用 AGPL 许可证发布。

总结来说，在应用中引入多个开源库时，必须仔细考虑这些许可证之间的相互影响，尤其是要警惕传染性较强的许可证（如 AGPL）对整个应用的潜在影响。如果其中一个库的许可证具有较强的传染性，那么很可能它的许可证要求会覆盖掉其他更宽松的许可证，导致整个应用都必须遵循最严格的开源要求。

什么情况下会被传染

不同的许可证对传染的触发条件各有不同。为了简化解释，我们重点关注 AGPL 和 SSPL 这两种具有较高传染性的许可证。

传染性主要在以下两种情况下会被触发：

1. 直接修改或嵌入：如果你在应用中直接修改了 AGPL 或 SSPL 许可的代码，或者将这些代码嵌入到你的应用程序中，这是传染性触发的一个条件。修改或嵌入代码意味着你在某种程度上“定制”了开源软件，因此你需要遵守许可证的条款。
2. 通过网络提供服务：即使你没有修改或嵌入 AGPL 或 SSPL 的代码，但如果你使用这些代码来通过网络提供服务（如 SaaS 模型），传染性仍会触发。AGPL 的“远程网络交互”条款要求，只要你通过网络提供基于 AGPL 许可的服务，你就必须公开相应的源代码。SSPL 进一步要求，不仅要公开使用的 SSPL 许可代码，还需要公开整个服务环境的代码，包括任何与服务运行相关的工具和脚本。

关键点：

• AGPL：如果你使用 AGPL 许可的代码提供网络服务，哪怕你没有修改或嵌入代码，也必须公开该服务使用的 AGPL 代码的源代码。
• SSPL：如果你使用 SSPL 许可的软件提供网络服务，必须公开不仅是使用的 SSPL 代码，还要公开服务运行所需的所有代码和工具。

因此，只要你通过网络提供基于 AGPL 或 SSPL 许可的服务，即便你没有修改或嵌入代码，仍然会受到这些许可证的传染性要求，需要公开相关的源代码。

什么叫通过网络提供服务？

在理解 AGPL 和 SSPL 的传染性时，理解“通过网络提供服务”的概念至关重要。这个概念决定了你是否需要公开你的源代码。可能有些读者会担心：“我的应用调用了基架部门提供的 Elasticsearch 服务，这算是通过网络提供服务吗？”或者，“我的应用调用了我购买的 Elasticsearch 云服务，这算是通过网络提供服务吗？”

这里我们来逐一解答这些疑问：

1. 内部调用（调用基架部门提供的 Elasticsearch 服务）：
   • 如果你的应用调用的是企业内部部署的 Elasticsearch 服务，比如由基架部门提供的服务，并且这些服务只在内部网络中使用，那么这通常不被视为“通过网络提供服务”。AGPL 和 SSPL 的传染性主要针对的是那些向外部用户提供服务的场景。所以，在这种情况下，你的应用代码不受 AGPL 或 SSPL 的传染性影响，不需要公开源代码。
2. 调用第三方提供的云服务（如购买的 Elasticsearch 云服务）：
   • 如果你的应用调用的是第三方提供的 Elasticsearch 云服务，比如 Elastic 官方的 Elasticsearch Service 或者其他云提供商的托管 Elasticsearch 服务，这种情况下，你是作为一个服务消费者在使用这些服务，而不是提供服务。因此，这也不被视为“通过网络提供服务”，而是你在利用已有的服务进行开发。由于你没有修改或重新分发这些服务代码，你的应用代码也不受 AGPL 或 SSPL 的传染性影响。

关键点：

• 内部服务调用：只要服务是在内部网络中使用，不向外部用户提供，这不属于“通过网络提供服务”的范畴，AGPL 和 SSPL 的要求不适用。
• 第三方云服务调用：作为服务消费者使用第三方提供的云服务（如 Elastic 云服务），你不需要公开应用代码，因为你没有通过网络提供该服务。

总结来说，通过网络提供服务通常指的是你作为服务提供者向外部用户提供基于 AGPL 或 SSPL 许可代码的服务。如果你只是内部使用或调用第三方云服务，这些情况并不需要公开源代码。

到这里，你应该隐隐能够猜到，谁会受到 AGPL 和 SSPL 的影响了。

AGPL 和 SSPL 到底会影响谁？

简单来说，AGPL 和 SSPL 的传染性主要影响那些云服务提供商和SaaS 服务提供商。

1. 云服务提供商： 如果你是一家提供云服务的厂商，并且你在你的服务中使用或扩展了 AGPL 或 SSPL 许可的软件，那么这些许可证的传染性要求可能会影响到你。这意味着你需要公开那些基于 AGPL 或 SSPL 的服务所使用的相关代码。如果你的云服务是基于这些开源软件的修改版本，那么你必须按照许可证的要求公开这些修改后的代码。
2. SaaS 服务提供商： 如果你是一家提供 SaaS 服务的公司，并且这些服务的基础是 AGPL 或 SSPL 许可的软件，那么你需要非常小心。即使你没有修改软件本身，只要你通过网络提供基于这些软件的服务，你可能需要公开相应的源代码。SSPL 的要求更为严格，它可能要求你公开整个服务运行的所有代码和工具，而不仅仅是核心的服务代码。

结论：

• 普通开发者：如果你只是在项目中使用 Elasticsearch 客户端库与 Elasticsearch 进行交互，或者使用托管的 Elasticsearch 服务，你不会受到 AGPL 或 SSPL 的影响。
• 云服务和 SaaS 提供商：如果你的业务涉及提供基于 AGPL 或 SSPL 许可的软件服务，你需要认真评估这些许可证的要求，并确保遵守相关的开源义务。

简而言之，AGPL 和 SSPL 的主要影响范围是那些通过网络提供服务的云厂商和 SaaS 服务提供商，而对于普通用户和大多数开发者来说，这些许可证带来的影响相对较小。

AGPL 和 SSPL 的细微区别

尽管 AGPL 和 SSPL 都属于传染性许可证，它们在传染性范围和适用场景上有所不同：

• AGPL：要求你在通过网络提供服务时，公开应用中所使用的 AGPL 许可代码的源代码。如果你直接修改或嵌入了 AGPL 代码，那么整个平台的相关部分可能需要开源。
• SSPL：相较于 AGPL 更严格，不仅要求公开使用 SSPL 代码的部分，还要求公开整个服务的所有相关代码，包括任何支撑服务运行的代码（如管理工具、监控脚本等）。

ELv2 与前面两者的区别

与 AGPL 和 SSPL 相比，Elastic License v2（ELv2）在传染性方面更加宽松。ELv2 是由 Elastic 专门为其产品设计的许可证，目的是在保护 Elastic 的商业利益的同时，尽量减少对用户和开发者的限制。与 AGPL 和 SSPL 这些强调开源和代码共享的许可证不同，ELv2 主要关注的是对商业行为的控制，而不是传染性要求。

ELv2 有传染性吗？

没有。 ELv2 并不像 AGPL 或 SSPL 那样具有传染性。使用 ELv2 许可的 Elastic 产品，你可以自由地使用、修改和分发，而不必担心需要公开你的源代码。这意味着你可以在闭源环境中使用 Elastic 产品，而无需遵守开源代码的发布要求。

ELv2 主要限制的是一些特定的商业行为，尤其是以下两点：

1. 禁止将 Elastic 产品作为服务重新打包和销售：ELv2 不允许你将 Elastic 产品作为基础，以自己名义提供服务，尤其是在不进行二次开发或增值的情况下。换句话说，你不能简单地将 Elastic 产品打包并出售，或者以原样提供为收费服务。
2. 限制未经授权的公有云托管服务：ELv2 明确规定，你不能在未经 Elastic 授权的情况下，将其产品用于提供公有云托管服务。这意味着，如果你想将 Elastic 产品部署在公有云上并作为服务提供，你需要获得 Elastic 的明确授权。这个条款是为了保护 Elastic 的商业模式，防止未经授权的第三方利用其产品来提供竞争性服务。

总的来说，ELv2 是一种更为宽松的许可证，它允许用户在较少的限制下使用 Elastic 的产品，而无需担心传染性条款的影响。对于那些希望在闭源项目中使用 Elastic 技术的企业，ELv2 提供了一个更加灵活和安全的选择。

我们应该如何选择？

对于开发者和企业来说，选择合适的许可证取决于你的业务模式和使用场景。在 99.999% 的情况下，如果你只是使用 Elasticsearch 的客户端库进行数据交互，那么你无需过多担心许可的问题，因为这些客户端库是基于 Apache v2 许可证发布的。这意味着你的应用和我们今天讨论的许可问题没有一点关系。

然而，如果你的使用场景涉及到更复杂的情况，以下几点是你需要考虑的：

1. 直接使用或修改 Elasticsearch 核心代码： 如果你在应用中直接使用或修改了 Elasticsearch 的核心代码，或者开发了与其紧密集成的功能，那么你需要仔细评估许可证的影响。例如，如果你编写了一个新的 Elasticsearch 实现（如一个自定义的搜索引擎），其中大量借鉴或使用了 Elasticsearch 的核心代码，那么你有两个选择：
2. 选择开放你的源码：你可以遵循 AGPL 或 SSPL 许可证的要求，公开你的源码，确保你符合开源社区的期望。
3. 与 Elastic 合作：如果你不希望公开你的源码，特别是当你的产品具有商业价值时，你可以选择与 Elastic 合作，取得适当的授权。这可能包括商业许可，允许你在不公开代码的情况下使用 Elasticsearch 的核心技术。
4. 提供基于 Elasticsearch 的云服务： 如果你的业务是提供基于 Elasticsearch 的云服务（例如，PaaS 平台），但你没有计划与 Elastic 合作并取得授权，你仍然有一些选择：
5. 选择 AGPL 许可证：你可以选择使用 AGPL 许可证的代码。虽然 AGPL 要求你公开你的服务代码，但它不要求你像 SSPL 那样公开支撑服务运行的所有代码（例如管理工具、部署脚本等）。这可能是一个相对较少的妥协，允许你在遵守开源义务的同时，保持部分代码的私密性。
6. 避免 SSPL 许可证：SSPL 的要求更为严格，可能会迫使你公开整个服务堆栈的代码。因此，如果你希望尽量减少开源的负担，AGPL 可能是一个更好的选择。
7. 与 Elastic 合作： 无论你选择 AGPL 还是 SSPL，如果你的业务依赖于 Elasticsearch 的核心功能，并且你不希望公开代码，与 Elastic 合作可能是最为稳妥的途径。通过合作，你可以取得必要的商业授权，避免传染性条款的影响，同时还可以获得 Elastic 的技术支持和资源，助力你的业务发展。

总结

选择许可证时，关键在于理解你的业务需求和使用场景。如果你只是普通用户或开发者，Apache v2 许可证的客户端库已经能够满足你大部分需求，并且不会带来传染性的问题。但如果你在更复杂的场景中使用 Elasticsearch 的核心技术，特别是涉及到修改代码或提供云服务，你需要谨慎选择适当的许可证，以确保你的项目能够顺利进行，并符合所有法律和商业要求。

最后，再次总结，这是我个人的观点和看法，仅代表我自己。