開放公開，火力全開（第二部分）

作者： Shay Banon

請注意：最初發布這篇博客后，我們又增發了兩篇博客來補充一些詳細資訊：許可協議變更澄清 和 為什么我們必須變更許可協議，

Elasticsearch 和 Kibana 的許可協議即將變更

我們即將把根據 Apache 2.0 許可授權的 Elasticsearch 和 Kibana 的源代碼變更為雙重許可模式（即 SSPL 1.0 和 Elastic 許可），以便用戶選擇適合自己的許可，通過這一許可協議的變更，這樣既能確保我們的社區和客戶繼續以免費開放的方式使用、修改和重新分發代碼，又能開展基于代碼的協作，而且還可以限制云服務提供商在不向社區提供任何回饋的情況下，將 Elasticsearch 和 Kibana 作為一項對外提供的服務，從而保護我們在開發免費及開放產品方面的持續投資，此次變更將適用于 Elasticsearch 和 Kibana 的所有維護分支，并從我們即將發布的 7.11 版本開始生效，我們的發行版將繼續使用與三年前相同的 Elastic 許可，

此次源代碼許可協議變更對絕大部分免費使用默認分發版的社區用戶沒有影響，也不會影響我們的云服務客戶或自管型軟體客戶，

近年來，市場已發生了很大的變化，社區開始逐漸的認識到，開源公司只有更好地保護了自己的軟體，才能夠實作持續創新和進行必要的投資，隨著很多公司不斷的轉型到 SaaS 產品，有些云服務提供商已經采用了開源產品，并在不向社區提供任何回饋的情況下，將其作為一項對外提供的服務，在大約三年前，我們開放了商業代碼，并將他們全面的開放，所有這些都是在 Elastic 許可下進行的，從而讓我們現在可以采用 SSPL 和 Elastic 許可的雙重授權許可策略，這對我們來說是水到渠成的一步，這與近年來許多其他開源公司（包括開發 SSPL 的 MongoDB）的做法類似，SSPL 雖然允許自由隨意地使用及修改產品源代碼，但有一個基本要求，也就是，在 SSPL 協議下，如果您將產品作為服務對外提供，則必須同時公開發布所做出的任何修改，以及您自己構建的管理層源代碼，

我們的開源之旅

我個人的開源之旅可以追溯到很久以前，2005 年，我開源了我的第一個專案 — Compass，在 Apache Lucene 的基礎上提供了一個 Java 框架，那時我在為我妻子開發一個關于菜譜的應用，在接下來的五年間里，我投入了無數個周末和夜晚來完善這個專案，從撰寫代碼到幫助用戶解決故障、功能等方面的各種問題，

我并沒有細想自己做這件事的目的是什么，尤其是我還有一份已經淪為“副業”的作業，但我醉心于此，因為這是能產生如此積極影響的機會 — 嘗試通過開源的力量，打造出一款優質產品，而且更重要的是，圍繞這款產品構建起一個良好的社區，

2009 年，我決定重新再來一次，于是開始撰寫一個全新的專案，它就是 Elasticsearch，我花了很多個夜晚和周末來構建這個專案，并在 2010 年開放了源代碼，我甚至辭掉了作業，決定全力以赴，通過撰寫代碼、在 GitHub 上寫博客、發郵件及通過 IRC 聊天工具，為用戶提供幫助，

而當我們在 2012 年成立 Elastic 公司時，也將這種精神帶到了我們的公司，我們在免費開放的產品上投入了大量資金，并支持用戶社區的快速發展，我們從單純的 Elasticsearch 擴展到 Kibana、Logstash、Beats，現在，Elastic Stack 中內置了一系列的解決方案：Elastic 企業搜索、可觀測性和安全，

我們有成熟的產品，圍繞這些產品培育了充滿活力的社區，并專注于為用戶提供最大價值，今天，我們有數百名工程師，他們每天的作業內容就是努力讓我們的產品變得更好，而且我們還有成千上萬的社區成員參與其中，幫助我們取得共同成功，

我為我們建立的公司感到驕傲，更為我們贏得用戶的信任而深感責任重大，我們從成立之初就是一家開放、透明的公司，并且我們在各項決策中也一直堅持全心全意為社區和廣大用戶服務，

免費開放 — 無可替代

早在 2018 年，我們就在 Elastic 許可（一種可獲得源代碼的許可）下開放了免費和付費專有功能的代碼，并將默認分發版更改為了包含所有功能，并默認啟用所有免費功能，

這樣做有幾個原因，首先，這讓我們能夠像與社區互動一樣接觸我們的付費用戶：實作公開交流，再者，讓我們能夠構建更多賦予我們用戶的免費功能，而不是將這些功能提供給某些公司，他們不只是自己使用我們的產品，還會將我們的產品作為他們對外提供的服務（如 Amazon Elasticsearch Service）之一，并從我們的開源軟體中獲利，而并沒有做出任何回饋，

我們的這種做法很受歡迎，今天，超過 90% 的新下載用戶都選擇了這個分發版，這使得我們能夠免費提供這么多的功能，同時也建立了一家成功的公司，

在這項新的免費、開放（但又是專有的）許可下，我們推出了大量改進，我為我們的團隊和社區在所有產品上取得的驚人進步所折服，我非常樂意與大家分享其中的一些改進：

我們通過一種新的分布式一致性演算法極大提高了 Elasticsearch 的速度、可擴展性和可靠性，并顯著降低了記憶體使用量；此外，還應用了新的資料存盤和壓縮方法，在提高索引和查詢吞吐量的同時，將典型索引大小縮減了近 40%，我們針對地理空間分析添加了新的欄位型別，以更有效的方式來存盤和搜索日志，并對安全性資料執行快速、不區分大小寫的搜索，在 Kibana 中，我們將加載時間縮減了 80%，消除了整頁重繪，這都要歸功于一個多年的平臺重構專案，同時我們還引入了 Kibana Lens 直觀的拖放式資料可視化體驗，以及儀表板深入分析等關鍵功能，

在過去三年里，我們還圍繞最常見的用例構建了一流的體驗，在安全解決方案方面，我們直接在 Kibana 內部創建了一個免費開放的 SIEM，它有一個強大的檢測引擎，通過 Elasticsearch 中新的查詢語言 EQL 支持簡單的規則和復雜的關聯，我們與社區協作，公開開發了數百條檢測規則，而且，我們還與領先的終端安全公司 Endgame 聯手，發布了免費且功能強大的惡意軟體防護功能，這也是 Elastic Agent 中的一項重要功能；Elastic Agent 是我們針對服務器和終端推出的統一、集中管理的可觀測性和安全管理代理軟體，未來還會推出更多功能，

在可觀測性方面，改進也齊頭并進，我們直接在 Kibana 內部構建了一個完整的可觀測性套件，從實時的 tail 日志 UI 到直觀的基礎架構級視圖，能夠查看主機、Pod 和容器中的各項關鍵指標和告警，現在，我們有了一個功能齊全的 APM 產品，配備了開源資料收集器和代理，支持 OpenTelemetry、真實用戶監測 (RUM)、綜合監測，以及最近添加的用戶體驗監測，

在 Elastic 企業搜索中，我們引入了 App Search，這是基于 Elasticsearch 的，它簡化了復雜應用程式的構建程序，并提供了強大的管理界面，用于相關性調優，以及使用情況分析，此外，我們還提供了一個免費的 Workplace Search 產品，可以輕松的集成和搜索您所使用到的有關個人或公司的各種內容資料源，如 Google Workplace、Microsoft 365、Atlassian Jira 和 Confluence 以及Salesforce，

我們能夠構建所有這些功能，并免費的提供給我們的社區，這真是太了不起了，看到我們產品的參與度和采用率，以及這些新功能幫助這么多人和企業取得了成功，我們深感責任重大，之所以能夠做到這一點，正是因為我們社區的絕大多數人都選擇了 Elastic 許可下的默認分發版，其中所有這些功能都是免費開放的，

為什么要變更許可協議？

如前所述，在過去三年中，市場不斷發展，社區逐漸認識到，開源公司只有更好地保護自己的軟體，才能保持高水平的投資和創新，隨著以 SaaS 作為交付模式的轉變，一些云服務提供商利用了開源產品的優勢，將其作為一項服務對外提供，而不向社區提供任何回饋，這種做法轉移了本可以再投資到產品上的資金，損害了用戶和社區的利益，

與眾多開源同行一樣，我們也親身經歷過這種情況，從我們的商標被濫用，到企圖通過對我們的 OSS 產品進行“公開”重新包裝，甚至從我們的專有代碼中獲得“靈感”，這些做法徹底的分裂了我們的社區，雖然每個開源公司解決這個問題所采取的方法略有不同，但為了保護他們在免費軟體上的投資，他們在試圖保持開放、透明和協作原則的同時，通常都修改了自己的開源許可，同樣，我們也本能地采取了這樣的做法，就如何授權我們的源代碼做了有針對性的變更，此次變更對絕大部分用戶沒有影響，主要是限制云服務提供商將我們的軟體作為一項服務對外提供，

我們估計，會有一些競爭對手圍繞這一變更試圖傳播各種各樣的擔憂、不確定性和質疑，我在這里對那些唱反調的人鄭重說明：我們對產品免費開放，以及對社區透明的原則堅信不疑，我們以往的表現也證明了這一承諾，我們將繼續在此基礎上再接再厲，

到底有哪些變化

從即將發布的 Elastic 7.11 版開始，我們將把根據 Apache 2.0 許可授權的 Elasticsearch 和 Kibana 源代碼變更為雙重授權許可模式（即 SSPL + Elastic 許可），以便用戶選擇適合自己的許可，SSPL 是 MongoDB 原創的一個可獲得源代碼的許可，它既體現了開放原則，同時又起到了保護作用，防止公共云提供商在不向社區提供任何回饋的情況下將開源產品作為一項服務對外提供，SSPL 雖然允許免費隨意地使用及修改產品源代碼，但有一個基本要求，也就是，在 SSPL 協議下，如果您將產品作為服務對外提供，則必須同時公開發布任何修改以及您自己管理層的源代碼，

我們之所以選擇這條道路，是因為它給了我們一個盡可能開放的機會，同時還保護了我們的社區和公司，在某些方面，這一變更會讓我們更加開放，作為這一變更的后續作業，我們會著手將我們的免費專有功能從 Elastic 許可改為 SSPL 下的雙重授權許可，這將更加寬松，更符合我們使產品盡可能免費開放的目標，

雖然更改源代碼的許可在某些方面是一件大事，但對我們社區的絕大多數人實際上沒有任何影響，如果您是我們的客戶，無論是在 Elastic Cloud 還是本地部署，請放心，一切都沒變，如果您已經下載并在使用我們的默認分發版，它們都是的 Elastic 許可，仍然是免費且開放，如果您一直在為 Elasticsearch 或 Kibana 的專案代碼做貢獻（非常感謝！），對您來說也沒什么變化，

我們會與過去三年一樣，將繼續以開放的方式開發我們的代碼，與我們的社區協作，并在 Elastic 許可下免費發布我們的版本，我們仍然承諾保持我們所有的免費功能繼續免費，不會做任何改變，以前免費使用的功能依然免費，需要付費訂閱的功能繼續付費訂閱，

我們對統一社區的重要性的信念從未如此堅定，這一變化能夠使我們像過去 10 年那樣，繼續表明我們的承諾，并用未來的行動贏得您的信任，

資源：

• 許可變更常見問答

前瞻性陳述

本篇博文包含了涉及重大風險和不確定性的前瞻性陳述，其中包括但不限于：關于公司代碼許可、軟體即服務和開源服務器端軟體的市場機會、開源創新的好處、公司采用的許可模式的影響、我們未來在研發方面的投資，以及我們對解決方案和產品優勢的評估等陳述，這些前瞻性陳述符合 1995 年《私人證券訴訟改革法案》中安全港條款的規定，這些前瞻性陳述反映了我們目前對其計劃、意圖、預期、戰略和前景的看法，是基于我們目前所掌握資訊和我們所作假設提出的，盡管我們認為這些前瞻性陳述所反映或建議的計劃、意圖、預期、戰略和前景是合理的，但我們不保證將達到或實作這些計劃、意圖、預期或戰略，由于不確定性、風險和環境變化，實際成果和結果可能與這些前瞻性陳述中所預期的成果和結果存在重大差異，包括但不限于：我們及時、成功地實施新的雙重授權許可模式并實作其各項優勢的能力；客戶和我們的用戶社區對新許可模式的接受程度；我們繼續建立和維護開發人員社區信譽的能力；競爭對手 SaaS 服務的影響；我們維護、保護、執行和增強我們知識產權的能力；SaaS 產品的擴展和采用對開源許可模式的影響，以及我們對未來運營的信念和目標，我們向證券交易委員會（簡稱 SEC）提交的檔案中包含了可能導致實際成果和結果發生重大差異的其他風險和不確定性，其中包括截至 2020 年 4 月 30 日本財年的 10-K 年度報告，以及隨后提交給 SEC 的任何報告，SEC 檔案可在 Elastic 網站 (ir.elastic.co) 的“投資者關系”部分或 SEC 網站 (www.sec.gov) 找到，除法律規定外，Elastic 公司不承擔更新任何此類前瞻性陳述的義務，目前也沒有更新的打算，

原文出處：https://www.elastic.co/cn/blog/licensing-change