最近,Elastic 新增 AGPL 协议的消息登上了社区的热搜,无论是社区的忠实用户、其他开源社区的吃瓜群众,还是其他同类产品的维护者和用户,似乎都在关注这个事情。我读了不少相关的文章,很多讨论说了很多观点,却很少真正触及问题的核心。
为了让大家更清楚地了解这件事,我决定写这篇文章,来详细解析一下这个话题,也算是后到的有感而发吧。与此同时,许多朋友也向我咨询这个问题,所以我也想借此机会从技术层面进行一些澄清。
需要强调的是,本文中的观点仅代表我个人的看法,大家可以作为参考,也欢迎讨论和交流。
为了照顾那些可能只有耐心读一两分钟的朋友,我决定打乱一下逻辑,直接把结论写在前面:对大多数人来说,Elastic 新增 AGPL 协议没有实质性的影响。所以,大家可以放心,别被热搜吓到了。
我们都知道,AGPL 是有“传染性”的许可证。简单来说,如果你使用了 AGPL 许可的软件,你的软件也必须采用 AGPL 许可证,这就是大家普遍担心的问题所在。但实际上,AGPL 的影响只有在你直接使用和修改相关代码时才会生效。
如果你压根没有使用和修改呢?
如果你只是把 Elasticsearch 当作一个后端服务(这也是 99% 的用户场景),通过client端,以调用API的方式把 Elasticsearch “集成” 到你的应用中(实际上,这并不叫集成,只是调用或者使用)。那么你使用的仅仅是 Elasticsearch 的客户端代码,而这些代码并不会触发 AGPL 的传染性条款,因为这里只有 Apache 2.0。我们先来看看在 Java 和 Python 中如何引入 Elasticsearch 客户端库,并列出它们的许可证信息:
// 引入 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);
// 处理搜索结果
}
}
# 引入 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 还是 Python 客户端库,实际上,所有的Elasticsearch客户端都是Apache v2的许可,这些库都不会对你的代码产生“传染性”影响。
这也是为什么说,对我们 99% 的,或许我说得保守了,应该是99.999% 的社区开发者,或者社区用户来说,这个变化是一点影响也没有。同理,SSPL 也是一样的。
换一个角度来思考,如何让自己能够受 AGPL和SSPL 的影响?我们先来看第一个,就是你把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 的传染性,让我们深入了解一下这两种协议的特点,以及它们对开发者和企业的影响。
传染性,顾名思义,就是当你使用了一段带有特定许可证的代码时,这段代码的许可要求可能会“传染”到你的整个应用中。具体来说,传染性许可证通常要求,如果你使用了带有该许可证的代码,并且在你的应用中进行了修改或组合,你的应用也必须使用相同的许可证发布。
这意味着,当你开发的应用中引入了一个带有传染性许可证的开源库时,哪怕只是使用了一小部分代码,整个应用的许可证要求可能都会受到影响。这也是为什么 google 等大企业不允许在代码中包含或者使用AGPL/SSPL许可的代码。但这并不意味着 google 等企业不会使用 elasticsearch,mongodb, redis, grafana,正如我们开篇所说,要正确理解客户端代码和服务端代码的区别。这两者是不一个 License。
回过头来,也就是说,如果你使用的库是基于 AGPL 的,那么你的整个应用可能也必须采用 AGPL 许可证发布,这也就是“传染性”的由来。
但是,问题往往比这更复杂。如果你的应用中引入了多个开源库,而这些库的许可证宽松度各不相同,比如 Apache 2.0、GNU、MIT、AGPL 等等,那么最终的许可证选择将取决于这些库中最严格的那个。通常情况下,许可证的严格程度将按照以下顺序递增:
因此,如果你的应用同时使用了 Apache 2.0 和 AGPL 许可证的库,由于 AGPL 是更严格的许可证,你的应用可能会被要求遵守 AGPL 的开源要求。这种情况下,AGPL 的传染性会覆盖掉 Apache 2.0 的宽松性,迫使整个应用采用 AGPL 许可证发布。
总结来说,在应用中引入多个开源库时,必须仔细考虑这些许可证之间的相互影响,尤其是要警惕传染性较强的许可证(如 AGPL)对整个应用的潜在影响。如果其中一个库的许可证具有较强的传染性,那么很可能它的许可证要求会覆盖掉其他更宽松的许可证,导致整个应用都必须遵循最严格的开源要求。
不同的许可证对传染的触发条件各有不同。为了简化解释,我们重点关注 AGPL 和 SSPL 这两种具有较高传染性的许可证。
传染性主要在以下两种情况下会被触发:
因此,只要你通过网络提供基于 AGPL 或 SSPL 许可的服务,即便你没有修改或嵌入代码,仍然会受到这些许可证的传染性要求,需要公开相关的源代码。
在理解 AGPL 和 SSPL 的传染性时,理解“通过网络提供服务”的概念至关重要。这个概念决定了你是否需要公开你的源代码。可能有些读者会担心:“我的应用调用了基架部门提供的 Elasticsearch 服务,这算是通过网络提供服务吗?”或者,“我的应用调用了我购买的 Elasticsearch 云服务,这算是通过网络提供服务吗?”
这里我们来逐一解答这些疑问:
总结来说,通过网络提供服务通常指的是你作为服务提供者向外部用户提供基于 AGPL 或 SSPL 许可代码的服务。如果你只是内部使用或调用第三方云服务,这些情况并不需要公开源代码。
到这里,你应该隐隐能够猜到,谁会受到 AGPL 和 SSPL 的影响了。
简单来说,AGPL 和 SSPL 的传染性主要影响那些云服务提供商和SaaS 服务提供商。
简而言之,AGPL 和 SSPL 的主要影响范围是那些通过网络提供服务的云厂商和 SaaS 服务提供商,而对于普通用户和大多数开发者来说,这些许可证带来的影响相对较小。
尽管 AGPL 和 SSPL 都属于传染性许可证,它们在传染性范围和适用场景上有所不同:
与 AGPL 和 SSPL 相比,Elastic License v2(ELv2)在传染性方面更加宽松。ELv2 是由 Elastic 专门为其产品设计的许可证,目的是在保护 Elastic 的商业利益的同时,尽量减少对用户和开发者的限制。与 AGPL 和 SSPL 这些强调开源和代码共享的许可证不同,ELv2 主要关注的是对商业行为的控制,而不是传染性要求。
没有。 ELv2 并不像 AGPL 或 SSPL 那样具有传染性。使用 ELv2 许可的 Elastic 产品,你可以自由地使用、修改和分发,而不必担心需要公开你的源代码。这意味着你可以在闭源环境中使用 Elastic 产品,而无需遵守开源代码的发布要求。
ELv2 主要限制的是一些特定的商业行为,尤其是以下两点:
总的来说,ELv2 是一种更为宽松的许可证,它允许用户在较少的限制下使用 Elastic 的产品,而无需担心传染性条款的影响。对于那些希望在闭源项目中使用 Elastic 技术的企业,ELv2 提供了一个更加灵活和安全的选择。
对于开发者和企业来说,选择合适的许可证取决于你的业务模式和使用场景。在 99.999% 的情况下,如果你只是使用 Elasticsearch 的客户端库进行数据交互,那么你无需过多担心许可的问题,因为这些客户端库是基于 Apache v2 许可证发布的。这意味着你的应用和我们今天讨论的许可问题没有一点关系。
然而,如果你的使用场景涉及到更复杂的情况,以下几点是你需要考虑的:
选择许可证时,关键在于理解你的业务需求和使用场景。如果你只是普通用户或开发者,Apache v2 许可证的客户端库已经能够满足你大部分需求,并且不会带来传染性的问题。但如果你在更复杂的场景中使用 Elasticsearch 的核心技术,特别是涉及到修改代码或提供云服务,你需要谨慎选择适当的许可证,以确保你的项目能够顺利进行,并符合所有法律和商业要求。
最后,再次总结,这是我个人的观点和看法,仅代表我自己。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。