• 如果您觉得本站非常有看点,那么赶紧使用Ctrl+D 收藏吧

CentOS 事件背后,谁该为开源生态负责?

互联网 diligentman 4天前 8次浏览

CentOS 事件背后,谁该为开源生态负责?

Jeff Geerling,来自密苏里州圣路易斯的作家和软件开发人员,活跃于许多开源开发社区(例如Drupal和Ansible)。
作为一名经验丰富的开发人员,喜欢在YouTube频道上分享工作和流程,日常积极地为GitHub上的开源项目做贡献。

过去几个月中,红帽高级副总裁兼首席技术官 Chris Wright 宣布将不再维护 CentOS Linux 这一爆炸性信息多次被开发者们关注于讨论。

红帽官方提出用户可以迁移至使用 CentOS Stream,但也有许多开发者另寻出路,CentOS Linux 创建者发起新项目,也有许多人猜测有没有其他项目能来接班。

近期 Elastic 也更改了 Elasticsearch 的云协议,限制了云服务提供商对其使用。

以上事件众说纷纭,有一位外国博主 Jeff Geerling 提出——谁该为这样的开源生态系统负责?圈内久有 leeches 这一说法,免费到底好不好?开源项目应该由谁掌握?又该如何回报构建开源软件的开发人员?

下面是对其视频内容的整理,原版权归作者所有,视频链接:https://www.youtube.com/watch…


我的职业生涯几乎都服务于开源,而最近发生的事件让我很担心其对开源生态系统的影响,过去几个月中,Red Hat 扼杀了 Linux,Elastic 扼杀了 ELasticsearch,或许有的朋友觉得这种说法太过了,但事情远比看起来的要复杂。

Red Hat 和 AWS 想利用“漏洞”,通过免费开源软件盈利,这种做法容易让开源软件失去用户群体后陷入被放弃的境地。

多年来我们都太关注 Red Hat 通过开源成功建立公司有多么的成功,但是自从其被 IBM 收购后,短时间就消耗了前期积累的好评。

这段日子,kubernets 日志生态系统中的开源项目 Elasticsearch 正在崩溃,Apache License 2.0 许可证变为了 Elasticsearch 的非自由许可证,视频讲分两个部分进行讲述,首先是 Red Hat 和 CentOS,其次回到 Elasticsearch。

Red Hat 接管 CentOS

当时人们对于把 CentOS 交付给 Red Hat 的态度可谓是喜忧参半,但主要还是喜。

那段时间内,CentOS 操作系统的维护人员有时感到难以跟上 Enterprise Linux 上游的变化,不论 Version 7 还是 8,发行都极其具有挑战性。

Red Hat 的加入让 CentOS 的构架变动更为安全,这是当时人们高兴的事情。

但现在,Red Hat 告知用户到 2021 年底将会停止维护 CentOS 8,如需继续使用其功能,则需切换到 CnetOS Stream,后者是 Red Hat 开发的商业 Linux 发行版,虽然比 Fedora 稳定,却不及 Enterprise Linux 稳定。

这一消息激怒了许多人,其中包括为 CentOS 做贡献的开发者们,诚然大多数对 CentOS 进行开发的人们,除非追述到多年前,现在贡献值已经不高了。

但另外一群被激怒的人,他们使用 CentOS 8 进行开发/测试,但不太可能采用 CentOS Stream 来生产产品,即使 Red Hat 以减少授权的形式抛出橄榄枝,如果想在 CI 中进行测试而不需要关注订阅和访问,大概还要做很多工作,这样一来倒不如不使用 Enterprise Linux 以及放弃对自身开源项目的支持。

两相比较,我更支持 Debian 和 Ubuntu。

也许增加收入是 Red Hat 这样做的动因之一,但不是全部,其中还有什么微妙的地方,大家可以想想。

而那些围绕着 Red Hat 协作却没有签署合同的企业和行业从事者们,更是对 Red Hat 此举很是紧张。

最后我期待 Rocky Linux 的诞生,希望它拥有我们所期待的稳定性。

Elastic 和 Elasticsearch

首先声明其中发生了许多事情,这里不能全部表述完毕,但下面会说一下基本故事。

Elasticsearch 是在 Apache LICENSE 2.0 许可下创建的,目前已经成长为一种必不可少的开源云基础设施组件了。

而亚马逊网络服务(AWS)希望把它打包为自己的 Elasticsearch,作为风险资本支持公司的 Elastic 不喜欢这个做法,他们认为这样做是通过项目收费来把开发货币化与向投资者展示收益增长。

于是 AWS 与 Elasic 开始竞争,但 AWS 却不如 Elasic 那样需要投入大量资金以及对开源负责。

这个过程中我们看到许多开源包所固有的问题:当 Google、AWS、Microsoft 这样的云计算巨头决定把免费软件变为可以盈利的软件,你会如何处理这个问题?

Elasic 的做法是更改许可证,现在许多开源社区软件的人谴责这一做法不是真正的开源,SSPL 被吹捧为 GPL Version 3.0 许可证,他们类似,但其中最主要的限制是:不能为某人建立一个托管服务且以此盈利。

Fedora 社区公开表示,将 SSPL 视为免费或开放的源码会让其他所有许可证蒙上阴影。

开源组织也在文章《SSPL》中表示,Fedora 不是一个开源许可证,声称开源后会拥有何种好处,何种保障,这是一种显而易见的欺骗。

其中有许多细微的变化,视频都无法很好地反映,问题不像 IBM 不好、leeches 不好、开源不好等等这么简单,所以希望大家能多关注相关新闻,了解其中变化。

最后

我提出了一些问题:

  1. 我们如何确保构建开源软件的开发人员能以公正的方式获得报酬?
  2. 如何让大公司以及大的风投支持初创公司且对免费和开源软件负责,却不给予他们相应的报酬?
  3. 如何减少许可证改变为我带来的烦恼,还能继续使用喜欢的软件和服务,是让我的许可证更具有约束力,选择为个人而非是公司提供保护的许可证,还是怎么做?
  4. 如果想靠开源来谋生或建立一家公司,应该如何选择?
  5. 企业越融合,开源就越有力量,这些力量掌握在巨型企业手中,罪魁祸首是谁?

针对第五个问题进行反省后我不得不承认,其中或许也有我的责任,那些总是嚷嚷着选择正确许可证重要性的怪人,他们被解雇,也许真的是因为做了什么。

盲目开放源码或许可以吸引更多公司,但这不是好的做法。

https://www.bilibili.com/vide…

CentOS 事件背后,谁该为开源生态负责?


程序员灯塔
转载请注明原文链接:CentOS 事件背后,谁该为开源生态负责?
喜欢 (0)