作者： 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 公司不承擔更新任何此類前瞻性陳述的義務，目前也沒有更新的打算。