Grafana数据可视化平台的开发人员宣布过渡到AGPLv3许可证，而不是之前使用的Apache 2.0许可证。 Loki 日志聚合系统和 Tempo 分布式跟踪后端也进行了类似的许可证更改。 插件、代理和一些库将继续根据 Apache 2.0 许可证获得许可。
有趣的是，一些用户指出，Grafana 项目成功的原因之一是，该项目在初始阶段尝试优化现有 Kibana 产品的界面，以可视化时变数据，摆脱与 Elasticsearch 存储的束缚，是选择更宽松的代码许可证。 随着时间的推移，Grafana 开发人员成立了 Grafana Labs 公司，开始推广 Grafana Cloud 云系统和商业解决方案 Grafana Enterprise Stack 等商业产品。
做出更改许可证的决定是为了维持生存并承受与未参与开发但在其产品中使用 Grafana 修改版本的供应商的竞争。 与 ElasticSearch、Redis、MongoDB、Timescale 和 Cockroach 等转向非开放许可证的项目所采取的严厉措施相反，Grafana Labs 试图做出平衡社区和商业利益的决定。 Grafana Labs 认为，向 AGPLv3 的过渡是最佳解决方案：一方面，AGPLv3 满足免费和开放许可证的标准，另一方面，它不允许寄生在开放项目上。
那些在其服务中使用未经修改的 Grafana 版本或发布修改代码的用户（例如 Red Hat Openshift 和 Cloud Foundry）将不会受到许可证变更的影响。 这一变化也不会影响亚马逊，该公司为 Grafana（AMG）提供云产品 Amazon Managed Service，因为该公司是该项目的战略开发合作伙伴，并为该项目提供了许多服务。 公司政策禁止使用 AGPL 许可证的公司可以继续使用旧的 Apache 许可版本，他们计划继续发布漏洞修复程序。 另一种出路是使用 Grafana 的专有企业版，如果没有通过购买密钥激活额外的付费功能，则可以免费使用该版本。
让我们回想一下，AGPLv3 许可证的一个特点是为确保网络服务正常运行的应用程序引入了额外的限制。 当使用AGPL组件来保证服务的运行时，开发者有义务向用户提供对这些组件所做的所有更改的源代码，即使该服务底层的软件不是分布式的并且专门用于内部基础设施组织服务的运作。 AGPLv3 许可证仅与 GPLv3 兼容，这会导致与根据 GPLv2 许可证提供的应用程序发生许可冲突。 例如，在 AGPLv3 下发布库需要所有使用该库的应用程序在 AGPLv3 或 GPLv3 许可证下分发代码，因此一些 Grafana 库保留在 Apache 2.0 许可证下。
除了更改许可证之外，Grafana 项目还转移到了新的开发者协议（CLA），该协议定义了代码产权的转移，这使得 Grafana Labs 可以在无需所有开发参与者同意的情况下更改许可证。 取代了基于 Harmony 贡献者协议的旧协议，引入了基于 Apache 基金会参与者签署的文档的协议。 表明该协议对于开发者来说更加容易理解和熟悉。
来源： opennet.ru