平台的開發者 數據可視化 Grafana宣布過渡到AGPLv3許可證， 而不是以前使用的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符合免費和開放許可的標準，另一方面，它不允許寄生化開源項目。
我們公司一直試圖在開源和社區的“價值創造”與我們的獲利策略的“價值獲取”之間取得平衡。 選擇許可證是該策略的關鍵支柱，這是自公司成立以來我們一直在深思熟慮的事情。
在過去的幾年中，我們密切關注著幾乎每一個我們仰慕的開源公司，例如Elastic，Redis Labs，MongoDB，Timescale，Cockroach Labs和許多其他公司，都在發展其許可製度。 在幾乎所有這些情況下，結果都是切換到未經OSI批准的可用字體許可證。
那些使用未修改版本的人 Grafana在其服務上或發布更改代碼（例如，Red Hat Openshift和Cloud Foundry） 它們將不受許可證更改的影響。 該更改也不會影響Amazon，後者為Grafana（AMG）提供了Amazon Managed Service雲產品，因為該公司是戰略開發合作夥伴，並為該項目提供許多服務。
具有禁止使用AGPL的公司政策的公司可以繼續使用Apache的較舊許可版本，預期將繼續為其發布漏洞補丁。 另一種解決方法是使用Grafana的專有企業版，如果沒有通過購買密鑰激活其他付費功能的話，該版本可免費使用。
回想一下， AGPLv3許可證的特殊之處是引入了附加限制 用於確保網絡服務運行的應用程序。 當使用AGPL組件來確保服務運行時， 開發人員有義務向用戶提供源代碼 對這些組件所做的所有更改中，即使未分發服務基礎的軟件，並且僅在內部基礎結構中使用該軟件來組織服務的操作也是如此。
AGPLv3許可證僅與GPLv3兼容，GPLv2會與GPLv3許可證下提供的應用程序產生許可證衝突。 例如，要在AGPLv3下發布庫，則所有使用該庫的應用程序都必鬚根據AGPLv3或GPLv2.0許可證來分發代碼，因此某些Grafana庫是根據Apache XNUMX許可證獲得許可的。
除了更改許可證之外， Grafana項目與開發人員簽訂了新協議 （CLA）， 它決定了代碼的產權轉讓， 允許Grafana Labs未經所有開發參與者的同意而更改許可證。
由Apache Foundation貢獻者簽署的基於文檔的協議取代了舊的Harmony貢獻者協議。 表明該協議對開發人員而言更易於理解和熟悉。