Redis 7.4修改协议的事情这阵子一直很热门，大家都在讨论还有哪些开源软件有变更协议的可能性。实际上我前些年也写过多篇关于开源协议的文章，探讨过一些这方面的问题。当Redis 6.0修改了一些高级功能的开源协议的时候，我也曾预言过不排除今后进一步修改开源协议的可能性。
图片
图片
图片
图片
图片
实际上从2015年Infobright直接从开源变为闭源开始，就已经陆陆续续有不少软件当过开源的叛徒了。ElasticSearch更是在2021年直接从APACHE开源协议直接向左转改为SSPL，再早些时候的2018年，MongoDB也来过这么一手。
国内的很多朋友都在探讨某些开源软件是否会受到美国政府的影响，从而修改开源协议。这种可能是存在的，不过对于大多数开源软件来说，可能性并不大。大家可以看出，这些年修改开源协议的软件，几乎与政治无关，而是与企业自身的商业利益有关。大多数修改开源协议的软件都是受控于某个单一的企业，而这些企业出于某种商业经营方面的原因而修改了开源协议。要么是公司准备上市或者被金主收购，要么是上市公司迫于经营压力而必须开拓新的财源。因此这些公司大多转向SSPL协议。
图片
一般我们认为SSPL协议是为了防止一些云厂商去薅开源软件的羊毛，实际上也大多如此，云厂商这些年成为了开源软件最大的受益者，他们虽然也对开源社区有不小的贡献，但是收益远远高于贡献。因此某些由单一企业主导的开源软件的许可协议转向更能够保护自己的SSPL，我觉得这也是合理的。优秀的软件的贡献者群体享受大家使用开源软件的好处的同时获得足够的回报，是很合理的诉求。
对于大多数自建云平台和自己使用这些开源软件的用户SSPL开源协议并不会对自己带来很大的影响。受影响比较大的是公有云或者商用私有云的用户。虽然开源协议是无国界的 ，但是一旦涉及到SSPL这种商用性质的软件授权协议，会涉及到相关销售方的出口管控政策。比如某个企业上了老美的黑名单，而SSPL协议的拥有企业是美国公司，那么国内的云厂商就无法卖给这个企业涉及SSPL的软件了。这个企业就只能自己去下载开源版本的软件，自己安装部署在云上了。
图片
在三年前Grafana修改开源协议的时候，我就在《从开源项目的割韭菜行动看开源项目的风险》一文中提到了在商业利益面前谈情怀是没有用的，拥抱开源，但是善用开源才是正道。
基于上述原因，我觉得开源软件修改开源协议的事情，今后会越来越多，我们需要关注，不过对于大多数用户来说不需要恐慌，更不需要不分青红皂白地认为开源软件不安全。如果有多个开源项目可以选择的时候，我们要尽可能选择开源协议更加友好的，开源软件contributor和贡献者更为分散的开源软件，因为这些开源软件想要修改开源协议的难度更大。而对于一些已经上了某些黑名单的企业，选择开源软件的时候要尽可能避免容易受到某些政府控制的软件，有实力的企业开启自己的分支更为稳妥。
总的来说，我个人观点是对于这件事，可以重视，但是无需恐慌，更没必要对开源软件敬而远之。处于不同的企业，从系统安全的要求不同也会有不同的选择。而对于将开源软件包装后做商业销售的企业，可能要更为关注这方面的问题。
