為了將開源專案的使用者轉變為付費使用者，Elastic今天宣佈，他們將把Elasticsearch和Kibana的許可證從開源Apache v2許可證改為伺服器端公共許可證(SSPL)。如果您的組織在其產品或專案中使用了Elasticsearch或Kibana的開源版本，那麼它現在就有可能被迫根據別人的要求釋出其智慧財產權。

如果您還不瞭解SSPL，可以在這裡瞭解一下。從商業的角度來看，這是一個相當大的問題。我給每個智慧財產權律師看了SSPL的文字，他們甚至在看完之前就已經感到相當不安了。基本上，它是一個披著開源外衣的惡意專利許可。透過在您的程式碼中使用SSPL專案，您同意如果您使用該程式碼提供線上服務，那麼您不僅將釋出該程式碼，而且還將釋出所有在SSPL下的每個支援軟體的程式碼。將許可證的措辭解釋為要求使用SSPL軟體的使用者因此釋出所有直接到裸金屬的程式碼並不是一種延伸。有些人會指出關於SSPL的FAQ，並聲稱該許可不是按照這種方式解釋的，因為FAQ是這麼說的。不幸的是，當您同意一個許可時，您同意的是該許可檔案的文字，而不是FAQ。如果該許可檔案的文字是模糊的，那麼您在該許可下的權利和責任也是模糊的。如果你對許可證的遵守情況出現在法官面前，他們對這些權利和責任的解釋將發揮支配作用。這種模稜兩可將你的組織置於危險之中。

在它的宣告中，Elastic聲稱這只是對開源許可證的一個改變。在某種程度上，他們是正確的:他們正在改變開源Apache v2許可證。然而，它們正在向可以被最好地描述為專有原始碼可用許可的方向轉變，而不是向開源許可轉變。SSPL的發起者MongoDB要求開源倡議組織(OSI，維護開源定義和作為開源認證許可證的標準組織)對SSPL進行認證。在法律、許可和開源專家小組進行了大量討論後，MongoDB撤銷了SSPL作為開源許可的考慮，因為它似乎不太可能被認證為開源。SSPL不是一個開源許可，這一點已不再存在爭議。那艘船已經開走了。如果你對此有問題，我建議你與OSI交涉。至於Elastic公開聲稱SSPL是一個開源許可，這是可以證實的錯誤說法，我希望OSI能與他們進行對話，並在短期內發表他們自己的公開宣告。

不，這是一個商業決定，不是意識形態決定。Elastic做了一個商業決定，改變這個充滿敵意的專有許可證，給他們提供了一種方法來強迫使用者成為他們的客戶。沒有更多關於Elastic業務和運營的戰略資訊，我們沒有資格判斷這是否是正確的決策，但決策本身是有效的。他們被允許為他們的公司做出這類戰略舉動。

然而，您和您的組織現在也被迫作出業務決策。如果您的組織在其專案或產品中使用Apache v2授權的Elasticsearch或Kibana，它現在必須假定自己處於某種風險中。它可以升級到7.11版本的這些專案,從而接受的條款SSPL也可能被要求釋放整個堆疊的程式碼(大量的它不會有版權,將無法釋放,從而可能違反SSPL)。它可以保留在版本7.10上，但之後它將不再接收未來的更新，包括重要的安全修復，從而承擔另一種風險。它可以選擇為該軟體支付Gold+許可證，但預算不太可能為這種意外費用做好準備。最後，它可以重新設計它的專案或產品，用替代產品替代Elasticsearch和/或Kibana。坦率地說，考慮到今天Elastic不友好的舉動，從長遠來看，在it和你的組織之間留出一些空間可能是最安全的選擇，但這也會帶來可觀的價格標籤，以及其他潛在的機會和轉換成本。

你們的組織不能忽視這一點。現在是時候召集您的法律、軟體開發、產品、財務和戰略團隊開會，開始找出適合您的最佳選擇。

本文：http://jiagoushi.pro/node/1464