但即便如此，對于 AWS 的這個舉動，依然有人認為是在分裂 Elasticsearch，甚至是在分裂開源。

有觀點認為，因為亞馬遜對待開源的方式，再加上像開放源代碼促進會(OSI)這樣的行業協會缺乏領導力，這將扼殺開源的創新，并使得開源商業化不那么可行。

而這最后導致的結果就是越來越多的開源軟件變成專有和閉源軟件 —— 以抵制像 AWS 這種云廠商的“掠奪”（在 2018 年有數十家公司更改了他們的授權許可），或切換成諸如 "source-available" 這樣的許可證。

當然，上面所說的選擇閉源的軟件主要是指基礎設施類軟件。不過如果 AWS 等云廠商與開源軟件之間的問題無法解決，相信這些開源軟件會將“更豐富的功能”放在企業版提供。

有人為此列舉了亞馬遜在開源方面做出的具有“侵略性”的行為：

1. 使用開源項目并將其作為商業服務提供，但不向創造和維護開源項目的商業實體提供任何回報，這無疑是斷了他們的“財路”。
2. 分叉開源項目，并強行控制它們遠離創造和維護開源項目的商業實體，就像 Elasticsearch。
3. “劫持(hijacks )”開源 API，并將它們置于自己的專有解決方案之上，從而將客戶從開源項目吸引到自己的專有解決方案，例子就是 AWS 推出與 MongoDB API 兼容的新數據庫產品 Document（主要是為了繞過 MongoDB 的新許可證）。

亞馬遜對待開源的態度顯然很自私，但站在它的角度來看，這是十分合理的舉動，甚至是一個最優解，因為它所做的事都是在許可證規則允許之下的。不過既然大家對這種行為都頗有微詞，所以這就需要行業協會創建新的開源許可證標準以滿足開源作者的合理訴求 ——

“不希望自己的開源代碼作為商業服務運行”。

只有如此，才能遏制像 AWS 那樣的行為，并避免導致出現不良的后果。

但當 MongoDB 向 OSI 提交自己的 SSPL 許可證申請時，卻引起了社區的質疑，有人認為 SSPL 違反了開源的本質，因為開源的價值正是能讓任何人以任何形式進行使用開源軟件（在開源協議允許的范圍內）。不過，MongoDB 也始終堅信 SSPL 符合符合開源計劃的批準標準。

既然行業協會不承認開源軟件廠商提交的開源許可證，那么他們為了“自保”該如何做？只能變更軟件授權方式，甚至將開源軟件閉源？

如果缺乏對“濫用”開源行為的制約，無論對開源軟件貢獻者還是使用者，乃至整個市場都會帶來很大的傷害。