可以说 Red Hat 做得有点绝，但完全公开本来就是情分不是本分，法律上没问题就行。

这个世界上从来就不缺靠谱的发行版，Debian 、Ubuntu 、OpenSUSE 放在那自己不去用。我从最开始接触 Linux 的时候就奇怪为什么要用 CentOS 这个奇怪的发行版，甚至有人专门用盗版的 RHEL ，活该。

这种事情本来就是相辅相成 如果 redhat 一开始就这么封闭还会有今天的 redhat 么

不过这么改硬件厂商应该会加大对其他发行版本的投入了 或许对于其他发行版而言并不是坏事

@Jirajine 请相信 redhat 的法务能力

@owen800q 你这是不看主贴呀，rhel 已经不公开源码了，除非你是商业订阅用户，而且商业订阅不允许自己构建再分发

@ZRS 企业级意味着 软硬件兼容性，一系列的测试，即使的 cve 安全更新，甚至 内核的一些定制修改

@Jirajine 这个链接里的评论应该完全解释了这个问题，为什么 红帽似乎能对 gpl 规定的权益做出限制。

https://www.reddit.com/r/linux/comments/14gfvuz/rhel_locks_sources_releases_behind_customer_portal/

No. Here user ubernostrum from lobte.rs explains better than me:

What we’re really talking about is a situation where two legal documents are involved, but they are separate from and orthogonal to each other:

1 - The GPL, which governs your rights to software you have already received.

2 - A contract with the vendor, which governs whether and under what conditions they will provide new versions, bugfixes, and other support on an ongoing basis in the future.

What document (2) does is actually give you more rights than the base GPL would – after all, the GPL does not impose any obligation on a distributor to continue distributing future versions, or to fix bugs (in fact, the GPL explicitly disclaims any warranty), etc.

And document (2) can condition those additional rights on anything it wants. It can take those additional rights away if you stop paying an agreed-on fee. It can take those additional rights away, and bonk you with the Calvinball, if you don’t cover your eyes when you’re in the Invisible Zone. And, yes, it can take those additional rights away if you use or distribute the software in a manner not permitted by the support contract.

You still have all the rights the GPL grants you, for the software you already received. You can run the software for any purpose. You can modify it. You can redistribute it, in modified or unmodified form. Even if you breach the terms of the support contract you retain those rights. You just lose the additional rights the support contract was providing, and that is perfectly compatible with the GPL, because the GPL only prevents people from taking away rights it grants, not from conditionally granting additional rights on top.

And that is basically how “enterprise support” contracts for GPL’d software work, and always have.

https://lobste.rs/s/a0mucw/red_hat_cutting_back_rhel_source#c_q41ht9

至今不知道 RHEL 有什么好，企业公司付费就行了，出了问题还有人背锅。

个人用户可选的发行版太多了，更没有必要上 RHEL 。

> 因为 gpl 之规定你分发二进制的时候必须附上源代码，现在你不花钱就无法获得 rhel ，而花了钱的用户可以通过红帽的 portal 协议获得源代码，对了通过 portal 获取的源码直接构建是违反红帽协议的。

这个描述直接违反 GPL 第 7 条吧，GPL 是不允许给 GPL 协议授权的源码添加额外的限制条件的...

@DeWjjj 做了什么改动还是告诉的，但是需要第三方发行版自己做一遍那些打包维护测试的事情，相当于原先那些商业公司/基金会的逻辑不成立了（ rocky alma 等）

@Trim21 较真的话请看 24F ，法务的高薪不是白拿的，简单说，gpl 不要求红帽提供后续的维护和支持

@Trim21 RedHat 的逻辑是这样的：
GPL：如果你分发二进制，你就必须分发源码，而且不得限制该源码的再分发
RedHat：你如果你买/注册我的服务，我就不给你二进制，既然我没给你二进制，我就没有义务给你提供源码
如果你买了我的服务，同时去分发源码。那我就不再给你提供新服务了。你已有的二进制和源码可以继续使用和再分发没有限制。我只是不再给你提供新的二进制和源码了。

不得不说，确实思路清奇。

@2NUT 从
For Red Hat customers and partners, source code will remain available via the Red Hat Customer Portal.
来看，应该是还是会从 portal 提供，当然前提是你得是红帽的消费者或合作伙伴。
你说的防止白嫖 patch 只能说是一个猜想，我记得大学的时候我们老师好像说过，用 GPL 发布的包，哪怕只是改了一个空格，只要 release 出来，就要不能加限制条件的开源。打过 patch 的包只是自用，没关系，只要你发布了，就必须遵守。

说句大实话，现在什么东西都能上 docker ，至少也能上个虚拟机，只要不碰物理服务器，谁会在乎用什么系统啊？就算用 Gentoo ，只要硬件厂商售后不找麻烦，想用什么用什么，反正就第一波可能会有点痛苦，之后都脚本化了。
反之，只要硬件厂商支持，老子才懒得管什么更新及时不及时呢？公司买不起红帽，那就看硬件厂商支持什么，支持 Centos 就用 centos 。支持 Rocky 就用 Rocky ，支持 Ubuntu server 就用 ubuntu server 。不然换块硬盘、电源都她妈让你重装系统，你闹不闹心？升级个固件由于系统版本不对，硬件损坏要求用户负责，这锅谁背得起？

忘了红帽被 IBM 收购的事情了……关于 IBM ，我只想说，这公司自从卖了 X86 业务，就越来越有国内大厂的风范。但是毕竟是老牌外企，应该不会这么难看吧！

@tin3w5

不给你二进制就不需要给你源码，不花钱就不算朴昌

从应用角度说，docker 能解决 99% 的问题，其他的就是一些不适合 docker 的专有服务；应用系统选择其实是 云厂商的事情，毕竟 xaas 屏蔽了大部分问题。

对于 RedHat 的决定我还挺开心的
因为我在公司碰到不少迷信 CentOS 的运维，把服务器搞得乱七八糟的，编译安装一堆包都不好更新/卸载
还会上网下一堆二进制库直接扔/usr/lib 里

然而那些包在 Debian 官方源里都有……
不如直接用 Debian ，这还是虚拟机里面，没什么硬件兼容不兼容的说法
问 CentOS 好在哪，答：“大家都在用，都说好”

我一直很好奇 楼主提到的 2 ，红帽的限制分发到底是怎么办到的，能直接禁用别人构建还不触犯 GPL 协议。然后翻看了半天大家的讨论还有 外国用户的说法，最终结果确实如楼主所说，但中间原理完全不一致。

由于 GPL 限制， 红帽必须给客户二进制的同时给客户源码， 同时无法限制客户使用源码修改和重新构建，所以实际上客户是可以自行编译构建再分发的，它做不到禁止客户构建。
但是，红帽的销售协议和 GPL 是不冲突的， 它可以规定当你通过源码重新构建并提供给其他用户后，你就违反了红帽的销售协议，你依然拥有当前版本的二进制和源码，但红帽的售后支持(服务)会自动终止，你将无权使用后续更新的软件和源码。

也就是说如果 rocky 购买了 RHEL 9.0.17 版本的授权， 然后通过源代码构建后， 这是意味着当前销售合同中止作废，rocky 再登录 redhat 官网只能下载，9.0.17 版本， 如果下载 9.1.45 这类版本的二进制和源码则属于盗版行为，redhat 就可以起诉你。
所以要么你从你购买的哪个版本的源码开始继续自行维护更新兼容，要么每次升级你都来买一份再分发给别人。

有一说一操作挺骚，但确实好像和 GPL 不冲突...

@gencoo 衍生发行版们难道从 gitlab 上 centos stream 那边 fork 一个分支维护

这个工作量挺大的，软件包很多，而且还有安全更新散落在 git 不同版本提交里，很难保证以前的及时性了，还有测试工作

@2NUT 我相信这些搞 Redhat 下游发行版的社区，不可能不是 Redhat 的客户或合作伙伴。
不适合 docker 的服务就等等呗！等发行版出解决方案了再更行也来得及。
生产上安全修复没那么急的，日常做好隔离就好。当年在某国内大型头部公有云厂商工作的时候，即使是来自厂商验证过的非常紧急的软件包更新，也都是要先在测试环境里跑半个月看稳定性再上预发布、最后再上生产灰度的。
在一个正常的企业环境里，安全是“锦上添花”，毕竟企业要优先以业务的连续性为第一要务。
至于稳定性，反正用过硬件服务器的都知道只要硬件厂商支持列表里有，那就肯定能确保硬件支持稳定，不会从底层崩溃。

@ShadowPower 很多时候存在即合理，你说的 case 只能说这个运维比较迷糊，或者说有些话不愿跟你讲。毕竟运维是要讲究运维成本的，维护两套发行版的出错概率肯定比维护一套发行版的概率高。即使是用了 ansible 之类的工具替代了 shell 脚本，Ubuntu 系和 Redhat 系差异还是很大的。这就是为什么一些大型外企，业务会分的非常明确。虚拟化团队的硬件服务器运维和业务层使用虚拟机的运维完全是两个 team 。但是国内很多时候会压着，宁可把一个人掰成三个人来用，哪还有精力搞发行版兼容？

@zpf124 很多人对 GPL 和红帽添加的限制理解还不够透彻，简单总结就是:

1. GPL 规定分发二进制文件就必须同时要能够提供源码，RH 只向订阅用户分发二进制文件，同时只向这部分用户提供源码，这一点不违反 GPL 。
2. 红帽无法限制用户通过订阅拿到源码之后再重新分发源码、或者通过这个源码重构建，也就是说用户通过订阅拿到源码之后要做什么红帽管不了，那是 GPL 赋予的权利，但是红帽可以通过订阅协议终止你的订阅服务，也就是说红帽有权利说我不和你做生意了，不收你的钱了，我可以关闭你的订阅，你就没法通过订阅服务继续拿到我的源码了。

那现在有个问题，红帽有办法通过技术手段来识别源码是通过哪个账户获取并且向外分发或者用来重构建的吗？我的看法是不能，对于大企业或者组织来说，更多的是基于道德和合规方面考虑不会走这种漏洞，小公司，个人之类你就是不鸟红帽，红帽也拿你没办法。

@vtgoal 小公司...和个人...

其实直接下载免费的 rhel dvd iso ，不订阅随便用就是了....

确实不知道讨论的意义是啥，白嫖的人不在乎，rh 不贵，买的人不嫌贵。

@ShadowPower #45 培训班，鸟哥都是 CentOS ，出了问题有人解答，社区多，回答多。

因为社区多，用户多，吸引更多的人去用它入门。如此循环惯性造成了用户众多，windows 用户同理

@digimoon 比较安全的就是 RHEL SUSE 了

到底是不懂 CentOS 跟 RHEL 的区别呢，还是不懂开源跟免费的区别呢，还是仅仅只是「白嫖有理」呢。

RHEL = 免费 CentOS + RedHat 的付费支持（含额外软件包和人工支持），原本就不存在免费 RHEL ，只有 RedHat 无法提告的盗版 RHEL 。现在只不过是堵上了「不好找证据告你盗版」的漏洞而已。

centos 变 centos stream ，这才是开源社区上杀千刀的事。至于 RHEL 这种商业开源软件的变动，原本就跟开源社区没任何关系。