3 ms·

Your analysis seems to be ignoring all of the work required to create and maintain the CentOS Stream / RHEL distribution in the first place, which is substantia

Your analysis seems to be ignoring all of the work required to create and maintain the CentOS Stream / RHEL distribution in the first place, which is substantial. Prior to CentOS Stream, if you were a CentOS user or maintainer who experienced a bug, your only option was to file a bug on the RHEL bug tracker and wait for a Red Hat employee to fix it for you. It was the Android-esque "throw the code over the wall" model of open source. Post CentOS Stream, a CentOS user or maintainer files the bug in the CentOS Stream bug tracker, can write a patch and have it reviewed by other users/maintainers/Red Hat employees tracking the issue, and then benefit from Red Hat QA'ing the fix. So counter to your claim, I would argue that the CentOS Stream model provides more bidirectional / mutual benefits.

thesuperbigfrog 3y ago
>> Your analysis seems to be ignoring all of the work required to create and maintain the CentOS Stream / RHEL distribution in the first place, which is substantial. Substantial enough to effectively "close source" RHEL? Red Hat's changes (https://www.redhat.com/en/blog/red-hats-commitment-open-source-response-gitcentosorg-changes https://www.redhat.com/en/blog/red-hats-commitment-open-sour...) effectively converted RHEL from a fully open source Linux distribution to "source available to paying customers only" proprietary product. The changes are effectively a violation of the GPL by prohibiting customers from distributing RHEL sources through Red Hat's Terms of Service and EULAs: https://rockylinux.org/news/keeping-open-source-open/ https://rockylinux.org/news/keeping-open-source-open/
- dralley 3y ago
  RHEL is not "effectively closed source" by any stretch of the imagination. The sources are available as CentOS Stream -- from which RHEL is built in the first place!! It is true that, in order to put together an exact copy of RHEL, you would need to do a bit of work to figure out exactly what versions RHEL uses, and specifically pick those versions out of CentOS Stream. It isn't as simple as downloading the entire tree of sources from a single git repository anymore. But that's not the same as "effectively closed source", either.
  - orthoxerox 3y ago
    If you provide GPL software to your customers, you have to provide everything they need to build this exact version yourself, not point them at a repo and tell them to figure it out.
    - dralley 3y ago
      Red Hat does provide all of that to RHEL customers. This is a discussion about what non-RHEL customers get. Even non-customers are provided with all of the sources they they could use to build RHEL, given some additional effort. It's less trivial than it used to be, but not particularly difficult. Alma takes the approach of reconstructing RHEL using these public sources, Rocky takes the approach of buying AWS VMs running RHEL for a few minutes at a time so that they can download RHEL sources as a "customer" while only paying a few dollars a month to do so. The point is, even non-customers can rebuild RHEL using sources made publicly available by Red Hat if they so desire. It's not "effectively closed source", even to them.
josephcsible 3y ago
Prior to CentOS Stream, couldn't you file the bug in the upstream project's bug tracker instead, and then still do all of the other stuff you said?
- dralley 3y ago
  You'd still have to wait for someone at Red Hat to backport the fix themselves. There wasn't really a way to actually participate in the engineering of CentOS itself.
  - josephcsible 3y ago
    Won't you still have to wait for someone at Red Hat to move the change from Stream into RHEL?
    - dralley 3y ago
      You'd have to wait on it to be QA'd before it would get into Stream officially, but once it's in Stream the process of it getting into RHEL is mostly automatic. It would just be a matter of waiting, since RHEL only does releases every 6 months whereas Stream releases constantly. With CentOS you would have the same problem, except that there's no way to make the engineering part happen any faster than Red Hat's staffing and priorities allowed.

thesuperbigfrog 3y ago

>> Your analysis seems to be ignoring all of the work required to create and maintain the CentOS Stream / RHEL distribution in the first place, which is substantial. Substantial enough to effectively "close source" RHEL? Red Hat's changes (https://www.redhat.com/en/blog/red-hats-commitment-open-source-response-gitcentosorg-changes https://www.redhat.com/en/blog/red-hats-commitment-open-sour...) effectively converted RHEL from a fully open source Linux distribution to "source available to paying customers only" proprietary product. The changes are effectively a violation of the GPL by prohibiting customers from distributing RHEL sources through Red Hat's Terms of Service and EULAs: https://rockylinux.org/news/keeping-open-source-open/ https://rockylinux.org/news/keeping-open-source-open/

dralley 3y ago
RHEL is not "effectively closed source" by any stretch of the imagination. The sources are available as CentOS Stream -- from which RHEL is built in the first place!! It is true that, in order to put together an exact copy of RHEL, you would need to do a bit of work to figure out exactly what versions RHEL uses, and specifically pick those versions out of CentOS Stream. It isn't as simple as downloading the entire tree of sources from a single git repository anymore. But that's not the same as "effectively closed source", either.
- orthoxerox 3y ago
  If you provide GPL software to your customers, you have to provide everything they need to build this exact version yourself, not point them at a repo and tell them to figure it out.
  - dralley 3y ago
    Red Hat does provide all of that to RHEL customers. This is a discussion about what non-RHEL customers get. Even non-customers are provided with all of the sources they they could use to build RHEL, given some additional effort. It's less trivial than it used to be, but not particularly difficult. Alma takes the approach of reconstructing RHEL using these public sources, Rocky takes the approach of buying AWS VMs running RHEL for a few minutes at a time so that they can download RHEL sources as a "customer" while only paying a few dollars a month to do so. The point is, even non-customers can rebuild RHEL using sources made publicly available by Red Hat if they so desire. It's not "effectively closed source", even to them.

josephcsible 3y ago

Prior to CentOS Stream, couldn't you file the bug in the upstream project's bug tracker instead, and then still do all of the other stuff you said?

dralley 3y ago
You'd still have to wait for someone at Red Hat to backport the fix themselves. There wasn't really a way to actually participate in the engineering of CentOS itself.
- josephcsible 3y ago
  Won't you still have to wait for someone at Red Hat to move the change from Stream into RHEL?
  - dralley 3y ago
    You'd have to wait on it to be QA'd before it would get into Stream officially, but once it's in Stream the process of it getting into RHEL is mostly automatic. It would just be a matter of waiting, since RHEL only does releases every 6 months whereas Stream releases constantly. With CentOS you would have the same problem, except that there's no way to make the engineering part happen any faster than Red Hat's staffing and priorities allowed.