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