從MongoDB更換開源許可協議談開源軟件法律風險是怎樣的

今天就跟大家聊聊有關從MongoDB更換開源許可協議談開源軟件法律風險是怎樣的，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

(一)事件背景

隨著開源軟件在云計算、大數據、人工智能等ICT新興領域發揮越來越重要的作用，企業也逐漸成為開源的主要推動力量。開源不僅僅是一種可以匯集產業力量進行協同開發的生產模式，而且也是企業競爭的重要手段。一些維護開源項目的企業通過修改開源項目的許可協議以實現降低產品風險、打擊競爭對手的目的。2018年10月，MongoDB宣布其開源許可協議從AGPL  v3切換到 Server Side Public License (SSPL)。2018年10月16日之前發布的MongoDB社區服務器版本采用AGPL  v3許可協議，2018年10月16日當天或者是以后發布的所有的MongoDB社區服務器補丁和新版本都采用SSPL許可協議，包括舊版本的未來的補丁。

(二)SSPL許可協議解讀

1、SSPL許可協議基本介紹

SSPL許可協議是在GPL v3基礎上修改得到的。SSPL許可協議共有17個條款，除第13條款與GPL v3規定不同外，其余條款與GPL  v3大致相同。SSPL許可協議有以下特點：

***，SSPL與GPL等開源許可協議一樣，賦予被許可人四項基本的權利，包括：自由運行程序、自由獲得源代碼、自由發布復制程序、自由修改程序并將自己作出的改進版本向公眾發行傳播。

第二，SSPL是強傳染性許可協議。這意味著：用戶如果對SSPL許可的軟件或基于SSPL許可的軟件的作品再發布時，必須以SSPL許可協議進行再發布。

第三，將SSPL許可下的程序再發布或將程序作為服務提供時，必須提供源代碼。無論SSPL約束的軟件以目標代碼或是可執行程序復制、發布時，都必須提供源代碼。

第四，SSPL明示了專利授權。與GPL  v3完全相同，SSPL許可協議的第11條款明示了專利授權。程序發布者即使就發布的貢獻申請了專利，在獲得專利授權后也必須將相關專利授權都免費許可給使用該程序的每一個人。

第五，SSPL存在不擔保條款。幾乎所有的開源許可協議都存在不擔保條款，不提供任何明示或暗示的擔保，包括但不限于適銷性和用于特定目的的適用性擔保。對于使用開源程序發生的任何損失，版權所有人或其他第三方均不承擔任何責任。因為開源軟件已經是免費許可，因此就不對軟件版權所有人要求擔保義務。

2、SSPL、GPL v3、AGPL v3對比分析

GPL v3、AGPL v3、SSPL這三個許可協議的差異主要體現在第13條款。GPL v3第13條款是“和AGPL一起使用”的相關條款的規定。AGPL  v3第13條款是“遠程網絡交互：和GPL許可協議一起使用”的相關條款規定。SSPL第13條款是關于“將程序作為服務提供”的規定。通過對比這三個許可協議的第13條款的規定，可以發現：

***，AGPL、SSPL許可協議的規定比GPL更為嚴苛。按照GPL許可協議的規定，任何人都可以以提供技術服務為目的，運行私有修改的GPL許可下的程序，只要不發布軟件，不需要公開源代碼。但是，AGPL許可協議將Copyleft這一概念延伸至網絡上自由軟件所交付的服務。在AGPL的規定中，如果其許可的程序與用戶通過網絡進行遠程交互，那么就需要提供源代碼給用戶，所有的修改也需要提供給用戶。常見的“通過計算機遠程網絡交互”的場景有：網絡和郵件服務器、基于互動的網絡應用程序和在線播放的游戲服務器等。在SSPL許可協議中，明確規定將程序或程序的修改版本的功能作為服務向第三方提供時，需要提供“服務源代碼”。最為典型的場景即云平臺提供商將軟件托管產品打包成服務。

第二，GPL、AGPL、SSPL都是強著佐權型許可協議。GPL、AGPL許可協議第13條款分別規定了GPL許可下的程序和AGPL許可下的程序在一起使用的情況，因此，GPL、AGPL許可協議是兼容的。但是，SSPL許可協議與GPL、AGPL都不兼容，也即：SSPL許可的代碼不能和GPL或AGPL許可的代碼組成一個程序發布。

二、MangoDB更改許可協議原因分析

(一)法律層面分析

AGPL v3許可協議的規定不明確導致很多企業一直在考驗AGPL的邊界。AGPL  v3第13條款規定了“遠程網絡交互”的限制條件。但是，業界對于AGPL遠程網絡交互的觸發條件以及范圍存有爭議。因此，SSPL明確規定了將程序作為服務提供的條件限制。

AGPL v3傳染性范圍判斷也較為模糊。GPL v3/AGPL  v3提出了“聚合體”的概念，認為將GPL許可下的程序納入到聚合體中不會導致對聚合體的其他部分適用GPL v3/AGPL  v3許可協議，即不會產生“傳染性”。然而，關于兩個程序是否組成了“聚合體”，產業界仍然有很大爭議，司法界也沒有相關判例。這直接導致很多企業一直游走在違反AGPL許可協議的灰色地帶。

(二)商業層面分析

“軟件即服務”的興起沖擊了MangoDB的商業模式。開源不僅是一種軟件開發模式，也代表了一種獨特的商業模式。MangoDB開源軟件采用了雙許可的商業模式。MangoDB分為企業版、開源社區版兩個版本。開源社區版本以SSPL許可協議免費許可給用戶，這樣便于測試軟件、獲得改進信息、得到開發者的支持、贏得口碑，有助于市場推廣。企業版本采用商業許可，為企業使用者提供更為豐富的功能以及提供技術支持、擔保等服務。MangoDB通過向商業用戶收取授權費用而盈利。采用雙許可模式的開源企業，通常會為其社區版本選擇如GPL、AGPL這樣的強著佐權型的許可協議，一定程度上限制了其他企業在社區版本的基礎上修改并銷售軟件。

近幾年，“軟件即服務”的觀念深入人心，IT產業逐漸向服務化轉型。用戶不需要購買軟硬件，而是通過互聯網向廠商訂購所屬的應用軟件服務。IT廠商越來越傾向于通過服務收費，而不是通過售賣軟硬件收費。一些云服務廠商將MangoDB的社區版本修改后向用戶提供其數據庫的托管商業版本，而不將修改的源代碼公開回饋給社區。如此一來，這些云服務廠商相當于從MangoDB企業版銷售中分了一杯羹，搶占了其銷售份額。MangoDB更換許可協議就是要遏制云服務提供商攫取開源軟件價值卻不給予開源社區任何回報的行為。

三、MangoDB更改許可協議影響分析

(一)許可協議更改對開源社區的影響

許可協議更改不影響MangoDB社區服務器的常規用戶。在開源社區中，SSPL賦予用戶的自由與AGPL許可下的MongoDB賦予用戶的自由是相同的——用戶仍然可以自由地使用、審查、修改、再發布源代碼。如果某公司僅僅將MangoDB在公司內部使用，或將其作為服務提供給子公司使用，不屬于提供服務給第三方的情況，不需要受13條款的約束，也不受更換許可協議的影響。此外，許可協議更改后，要求云服務廠商將其對MangoDB的修改反饋給開源社區，這將有助于開源軟件不斷完善，對開源社區的發展有長遠意義。

(二)許可協議更改對云服務商的影響

MangoDB更換許可協議之后，云服務廠商如果想銷售基于MangoDB的云服務，要么需要完全公開其服務源代碼，要么需要向MangoDB購買商業許可。MangoDB許可協議中，對“服務源代碼”的范圍界定非常寬泛，不僅包括MangoDB或其修改版本對應的源代碼，還包括管理軟件、用戶界面、應用程序接口、自動化軟件、監控軟件、備份軟件、存儲軟件和托管軟件的源代碼。將這些“服務源代碼”完全公開，意味著這些云服務廠商喪失了產品差異化的能力。因此，其他云服務廠商可能也就沒有積極性銷售基于MangoDB的云服務。

四、MangoDB更改許可協議對我國企業開源的啟示

(一)理解開源的游戲規則

隨著商業公司逐漸成為開源的主要力量，開源變得越來越不那么“純粹”，逐漸成為企業盈利的一種方式。開源軟件開發模式的選擇、開源許可協議的選擇、開源軟件的盈利模式的選擇，都是一脈相承、緊密相關的。例如，開源基金會主導的開源軟件，往往會選擇Apache、BSD、MIT這樣的寬松的開源許可協議，以吸引更多的商業公司參與。商業企業主導的開源軟件，往往會選擇GPL這類強著佐權型許可協議，以保證其雙許可商業模式的實現。企業只有理解了開源的游戲規則，才能在開源中獲利，有效降低知識產權侵權風險。

(二)謹慎選擇開源軟件

開源不是“免費的午餐”，企業主導的開源項目往往充滿了層層陷阱。如果一個開源軟件是一家企業主導，這家企業又擁有全部開源代碼的著作權的話，那么這家企業就可以隨時變更該開源軟件的開源許可協議，甚至將其變為閉源。例如，Redis將自建的Redis模塊——RediSearch，Redis  Graph，ReJSON，ReBloom和Redis-ML的許可協議由AGPL v3變更為Apache v2與Commons  Clause相結合的許可協議，實際上是這些自建模塊已經不是開源軟件，而僅僅是可以獲得源代碼。這種許可協議的突然變更，會使得使用這些開源軟件的企業陷入兩難境地。在自己的產品中更換開源軟件，則替換成本很高;如不更換開源軟件，新的許可協議往往需要將私有代碼公開甚至不允許商業銷售。因此，企業一開始就謹慎選擇開源軟件，不僅僅要對其性能進行檢測，也需要對充分考慮其知識產權風險。

(三)使用開源軟件應遵從開源許可協議

開源軟件不是公共領域的軟件，不可以任意使用。絕大部分開源軟件都是有著作權，且受著作權法保護的。開源軟件的著作權人通過開源許可協議將開源軟件的復制權、修改權、發行權等部分權利讓渡給了被許可人，被許可人在遵從開源許可協議規定的前提下，才可以行使這些權利。如果企業沒有按照開源許可協議的規定使用開源軟件，就存在很大的著作權侵權風險。

(四)做好開源軟件的風險防控

開源許可協議往往都有“不擔保”條款，這意味著企業使用開源軟件需要風險自負。在這種情況下，企業對開源軟件的風險防控顯得尤為重要。一方面，要完善企業開源軟件管理流程，規范企業內部對開源軟件的使用，降低因不合規使用開源軟件帶來的法律風險;另一方面，要關注所使用的開源軟件的相關法律糾紛，建立風險預警機制，及時在產品中更換有風險的開源代碼。

看完上述內容，你們對從MongoDB更換開源許可協議談開源軟件法律風險是怎樣的有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。