Redis 7.4修改協議的事情這陣子一直很熱門，大家都在討論還有哪些開源軟件有變更協議的可能性。實際上我前些年也寫過多篇關于開源協議的文章，探討過一些這方面的問題。當Redis 6.0修改了一些高級功能的開源協議的時候，我也曾預言過不排除今后進一步修改開源協議的可能性。

圖片

圖片

圖片

圖片

圖片

實際上從2015年Infobright直接從開源變為閉源開始，就已經陸陸續續有不少軟件當過開源的叛徒了。ElasticSearch更是在2021年直接從APACHE開源協議直接向左轉改為SSPL，再早些時候的2018年，MongoDB也來過這么一手。

國內的很多朋友都在探討某些開源軟件是否會受到美國政府的影響，從而修改開源協議。這種可能是存在的，不過對于大多數開源軟件來說，可能性并不大。大家可以看出，這些年修改開源協議的軟件，幾乎與政治無關，而是與企業自身的商業利益有關。大多數修改開源協議的軟件都是受控于某個單一的企業，而這些企業出于某種商業經營方面的原因而修改了開源協議。要么是公司準備上市或者被金主收購，要么是上市公司迫于經營壓力而必須開拓新的財源。因此這些公司大多轉向SSPL協議。    

圖片

一般我們認為SSPL協議是為了防止一些云廠商去薅開源軟件的羊毛，實際上也大多如此，云廠商這些年成為了開源軟件最大的受益者，他們雖然也對開源社區有不小的貢獻，但是收益遠遠高于貢獻。因此某些由單一企業主導的開源軟件的許可協議轉向更能夠保護自己的SSPL，我覺得這也是合理的。優秀的軟件的貢獻者群體享受大家使用開源軟件的好處的同時獲得足夠的回報，是很合理的訴求。

對于大多數自建云平臺和自己使用這些開源軟件的用戶SSPL開源協議并不會對自己帶來很大的影響。受影響比較大的是公有云或者商用私有云的用戶。雖然開源協議是無國界的 ，但是一旦涉及到SSPL這種商用性質的軟件授權協議，會涉及到相關銷售方的出口管控政策。比如某個企業上了老美的黑名單，而SSPL協議的擁有企業是美國公司，那么國內的云廠商就無法賣給這個企業涉及SSPL的軟件了。這個企業就只能自己去下載開源版本的軟件，自己安裝部署在云上了。    

圖片

在三年前Grafana修改開源協議的時候，我就在《從開源項目的割韭菜行動看開源項目的風險》一文中提到了在商業利益面前談情懷是沒有用的，擁抱開源，但是善用開源才是正道。

基于上述原因，我覺得開源軟件修改開源協議的事情，今后會越來越多，我們需要關注，不過對于大多數用戶來說不需要恐慌，更不需要不分青紅皂白地認為開源軟件不安全。如果有多個開源項目可以選擇的時候，我們要盡可能選擇開源協議更加友好的，開源軟件contributor和貢獻者更為分散的開源軟件，因為這些開源軟件想要修改開源協議的難度更大。而對于一些已經上了某些黑名單的企業，選擇開源軟件的時候要盡可能避免容易受到某些政府控制的軟件，有實力的企業開啟自己的分支更為穩妥。

總的來說，我個人觀點是對于這件事，可以重視，但是無需恐慌，更沒必要對開源軟件敬而遠之。處于不同的企業，從系統安全的要求不同也會有不同的選擇。而對于將開源軟件包裝后做商業銷售的企業，可能要更為關注這方面的問題。