这两天，Grafana 修改开源协议为 aGPL v3 的新闻在朋友圈和社媒备受热议，特别是在开源圈子里，厂商和用户都在高度关注这个事件带来的影响。Grafana 在云原生技术领域的监控工具中几乎是事实标准一般的存在，我们不禁会猜想，为什么 Grafana 在这个时间突然修改开源协议？是否是由于前不久 Elasticsearch 和 MongoDB 的影响？

Grafana 社区用户反响如何

注：以下截图来自 Grafana 官方 Twitter。

GrafanaLabs 此次将社区的三款开源产品 Grafana、Loki 和 Tempo 都更改为了 aGPL v3，此消息在 Grafana 的社交媒体发出后，社区用户除了对能否继续使用 Grafana 产生了顾虑，有一部分人甚至对 Grafana 产生了信任危机，也有用户表示自己公司不允许使用 aGPL 协议的开源软件，将会寻找替代品。

不过也有部分用户表示非常理解 Grafana 这一举措的原因，理解支持开源项目背后的商业公司本身的生存与竞争压力，毕竟还是有其他公司会 Rebranding 开源项目来直接进行商业化，选择白嫖开源并且不给上游开源项目做任何贡献的公司不胜枚举。

Grafana CEO 也在第一时间表示 Grafana 社区始终以开源为核心，对用户来说，aGPL v3 协议并不会影响 Grafana 作为自由的开源免费软件。Raj Dutt 也在官网发布了一篇非常详细的 Q&A 文档，基本可以解答社区大部分的疑问。这其中有几个问题，对于大家通俗理解 aGPL 协议的基本含义，以及 aGPL 协议的开源软件在使用与分发上，有极大的参考价值。

为什么是 aGPL v3

为什么 Grafana 会选择 aGPL 协议，而不是更严格的 SSPL？

实际上，aGPL 是 OSI 认证的开源 License，而 SSPL 并非 OSI 认证的开源 License（如 Elasticsearch 和 MongoDB），关于 OSI 认证的开源 License，在 OSChina 这篇文章中有一份完整的列表。因此从开源协议层面来说，aGPL 的开源软件依旧是符合免费和开源软件的所有标准。

将 Grafana 集成到自家产品是否会有影响？

有一些厂商将 Grafana 作为产品或服务集成到自家产品中，后续是否会受到限制？

答案是未作代码修改的二次分发是不受影响的，比如 Cloud Foundtry 和 Red Hat OpenShift 也集成了 Grafana，但是其本身的代码是开源的，也没有修改过 Grafana 代码，这是符合 aGPL v3 开源协议的。

另外，云厂商也有提供 Grafana 托管服务的，比如 AWS，也无需为这一事件做任何调整，因为 Grafana Labs 和 AWS 是战略合作伙伴。这也暗示着其他云厂商，如果以后想基于 Grafana 提供商业化的托管产品服务，得先跟 Grafana Labs 达成商务合作。

aGPL v3 开源项目是否流行与成熟？

aGPL v3 开源协议是否是一个没有广泛流行的严格开源协议？

事实上，aGPL v3 协议已经存在并运行了长达 14 年，也有大量的开源软件在使用 aGPL v3 开源协议，维基百科还专门有一份列表列出了哪些开源项目是采用了 aGPL v3 开源协议的，表单中收录的 134 个 aGPL v3 的开源项目，这其中就有著名的 Neo4j、Nextcloud。

aGPL v3 完全符合开源与自由软件的标准，只有一个非常关键的点，即对修改上游开源项目代码后的二次分发版本必须也要开源，这其实限制的是部分云厂商想 Folk 开源项目代码后进行闭源商业分发，跟上游开源项目的维护厂商进行直接的商业竞争。如果仅仅只是企业内部自己使用，用户大可不必担心 aGPL v3 协议带来的限制。

如何绕开公司不让使用 aGPL 的软件的限制？

如果企业有规定无法使用 aGPL v3 的开源软件，但又想继续使用 Grafana 该怎么办？

除了继续使用老版本的 Grafana（Apache 开源协议），用户还可以选择 Grafana Cloud 或者具有专有许可的企业版。如果企业就是想对 Grafana 二次分发并修改开源协议，或是进行闭源的商业化版本维护，Grafana Labs 也接受购买他们专有许可的 License 来满足这一类企业的个性化商业需求。

KubeSphere 项目的开源协议

既然聊到了 Grafana 的开源协议，也顺便解答一下社区的部分用户对于 KubeSphere 开源协议的问题。KubeSphere 项目的后端代码是 Apache v2，前端代码是 aGPL v3，社区也有很多用户对前端项目的开源协议有很多疑问，特别是对于修改 Logo 以及二次修改后的商业分发。

相信大家看了 Grafana Labs 对 aGPL v3 相关问题的解答，也会对这个问题有更多的理解，实际上只要完全遵守 aGPL v3 开源协议，比如二次修改后的代码也开源，这个协议就不会有任何影响；如果你是在企业内部使用，也无需担心 aGPL v3 带来的限制。同样，对于想对 KubeSphere 进行二次修改商业分发的用户，KubeSphere 项目背后的商业公司青云 QingCloud 也提供类似 Grafana Labs 这样的商业授权。

Grafana 修改开源协议为 aGPL v3，你怎么看？

我个人尊重和理解 Grafana Labs 修改开源协议的这一举措，毕竟开源项目背后的商业公司只有在商业上取得成功，才能更好地为开源项目提供新特性的开发、支持与维护，形成良性循环，这样开源项目的维护才会更加长久。假如其他企业基于上游的开源项目进行商业二次分发，直接与该开源项目以及背后的商业公司进行商业竞争，这就很有可能会对开源生态造成较为恶劣的影响。

aGPL v3 相较于 Apache v2 肯定不如后者更加宽松，对于二次分发有明确的开源要求，不知道大家对于 Grafana Labs 此次修改开源协议怎么看？同时，如果大家对于 KubeSphere 前端 aGPL v3 开源协议还有更多问题，欢迎大家在社区随时提问交流。

注：以上观点仅代表个人观点。