云服務商拿來主義或大限將至，Elastic 表示將變更開源許可協議并進行訴訟-有解無憂

【編者按】每個開源專案都會有自己的一個開源協議，例如 Apache、MIT、BSD、GPL 等等，可以說是對于該專案開發者、使用者甚至是商業化受益者的一種約束，不過，開源專案的開源協議也不是一條路走到黑的，不少著名的專案都曾經更換過開源協議，很大程度上是因為一個原因——云服務商白嫖，拿來別人辛苦開發的東西去做自己的收費產品，卻并不進行反饋，這種『拿來主義』令很多開源專案團隊表示不滿，Elatic 這次更換協議的發聲，不是第一個，也肯定不是最后一個，隨著開源的普及和發展，未來此類事件會越來越多，也希望更多人能夠從使用者、支持者，成為開源的貢獻者，當然，尤其是云服務公司，總不能當貔貅吧～

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-wxf52oMI-1610967709953)(image/20210118_175914_97.png)]

作者 | 八寶粥

出品 | CSDN（id:CSDNnews）

日前 Elastic 公司宣布，將對旗下 Elasticsearch 和 Kibana 進行開源許可修改，從 Apache 2.0 許可的源代碼移到服務器端公共許可（SSPL）和 Elastic許可的雙重許可下，使用戶可以選擇要應用的許可，該公司市值 140 多億美元，根據官方資訊，從7.11版本開始，兩個產品的所有維護分支，默認發行版將繼續使用 Elastic 協議，

目前，兩個專案的協議分別更新于 2018 年和 2019 年

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-m23O7Kn9-1610967709962)(image/20210118_174344_72.png)]

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-6FndRZ0p-1610967709965)(image/20210118_174456_70.png)]

為什開源專案要改協議？

官方表示，為了保證社區和用戶能夠自由開放地訪問、使用、修改和分發這兩個產品和原始碼，重點來了：它還通過限制云服務提供商在不共享其修改內容和服務管理層的源代碼的情況下限制其將我們的產品作為服務提供，從而保護了我們在開發免費和公開分發的產品方面的持續投資，畢竟誰的錢也不是天上掉下來的，云服務商直接白嫖，云服務直接裝上作為自己的產品打包賺錢，沒有支持和回饋，這顯然不合情理了，

Elastic 表示，同阿里巴巴和騰訊建立了合作伙伴關系，兩個產品不受影響，微軟、谷歌、阿里和騰訊甚至是 AWS 的 Elastic Cloud 也可以正常使用，不過，Elastic 我們與 Amazon Elasticsearch Service 上的 AWS 沒有商業關系，不積極支持該服務，也不再希望我們對軟體的投資直接受益于該服務，為了透明起見，我們還在與AWS進行持續訴訟，都鬧到對簿公堂了，可見積怨已久，

此次更換協議對于使用者有什么影響？

官方表示：沒有影響，您還可以像之前一樣使用，

改開源協議，還有誰？

當然有，而且不少，

1.Redis
2018 年 8 月，Redis Lab 表示，Redis 開源許可依然是 BSD,但是模塊許可協議修改為 Apache 2.0并附帶 Commons　Clause，

2019年，Redis Labs 決定洗掉 Commons Clause，更換成心的許可 RSAL，Redis 表示該協議不針對開發人員，僅僅是為了自己對于產品的維護，防止云服務商打包產品進行壟斷牟利，

2.MongDB

2018 年 10 月，MongoDB 宣布更改開源協議將從 GNU AGPLv3 更改為 SSPL，此舉遭到了紅帽等組織的啟用，因為他們認為 SSPL 不是真的開源，當然，MongoDB 也不否認，畢竟自己的產品一直被云服務商白嫖甚至是公然售賣，擱誰都受不了了，

3.OpenCV
2020 年 7 月，OpenCV OpenCV 官方宣布，將開源協議從 BSD 變更為 Apache 2.0，目的是針對其中的“專利”相關進行說明，盡管代碼本身免費，如果使用 BSD 許可的代碼，當中包含的專利可能涉及到一系列的復雜問題，目前，OpenCV 4.5.0及更高版本使用 Apache2.0 協議，而 4.4.0 以下版本采用了 BSD 協議，

4.Google
這里也是針對云服務商，不過不是協議，2019 年，Google 表示將不會將旗下的開源專案　Knative　捐給 CNCF,畢竟自己造出了 K8S 眼睜睜看著云服務商吃肉而自己連口湯都不好喝，所以就決定利用自己的發明者的優勢和云服務商競爭一下到底誰該吃這塊肉，當然，Google 此舉也遭到了一些開源專案創建者的反對，

那些神奇的協議

開源協議，規定開發者和使用者對于專案的修改和使用、分法等一系列行為，了解開源專案的朋友們可能對 Apahce，MIT，GPL 之類的開源協議再熟悉不過了，這里擱置不表，有興趣的朋友可以直接去訪問開源協議的官網去了解，

GitHub 當中默認能夠直接選擇的是哪些協議呢？

Apache License 2.0
GNU General Public License v3.0
MIT License
BSD 2-Clause "Simplified" License
BSD 3-Clause "New" or "Revised" License
Boost Software License 1.0
Creative Commons Zero v1.0 Universal
Eclipse Public License 2.0
GNU Affero General Public License v3.0
GNU General Public License v2.0
GNU Lesser General Public License v2.1
Mozilla Public License 2.0
The Unlicense

如果使用其他協議，只要自己建立一個 License.txt 宣告即可，除了這些之外，通常我們使用的開源協議是通過開源促進會（OSI，Open Source Initiative）批準的開源協議，去年 2 月，OSI 首次通過了來自中國的木蘭開源許可證v2版本(MulanPSL-2.0),正式成為一個國際化開源許可證，

SSPL 是由 MongoDB 最初創建的可提供源代碼的許可證，旨在體現開放原始碼理想的許可證，允許自由和不受限制地使用，修改和重新分發，其簡單要求是：如果您以服務給他人，您還必須根據SSPL公開發布任何修改以及管理層的源代碼，SSPL 是基于GPLv3 的 copyleft 許可證，并沒有經過 OSI 批準，因此官方還特意宣告：『為了避免混淆，我們暫時不將兩個產品稱為開源，而使用“免費和開放” 進行描述』

這里還有兩個奇奇怪怪的協議，WTFPL 和 DBAD 協議，我知道一說這個你們就來精神了，

WTFPL，全稱 Do What The F*ck You Want To Public License 就是你 ** 想用它做點啥就做點啥吧
目前也是通過了 FSF 和 GPL 許可的，當然了這個存在一定的爭議，有些人表示這個權限給的太散漫了，不過，既然作者同意了，那就隨他去吧，

另外一個神奇的協議叫做 DBAD，全稱 Don’t be a dick，該協議的最神奇之處是，他是要求開發者的，協議里面還對 dick 進行了定義，意思是可別整幺蛾子了，

開源專案這么多，你喜歡哪一個？你的開源專案用的什么協議？歡迎評論留言，

【參考資料】
https://www.elastic.co/cn/blog/licensing-change

https://www.elastic.co/cn/pricing/faq/licensing

http://www.wtfpl.net/

https://dbad-license.org/

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/251710.html

標籤：其他

上一篇：極客日報第 54 期：騰訊、火絨分別回應關于“QQ 讀取瀏覽器歷史記錄；俄羅斯加密交易所遭黑客攻擊關閉；華為商城全面下架榮耀產品；

下一篇：寒假學習——ES6（2）