4 ms·

> red hat circumvents that by using a support contract that terminates when users share their copy. This is not true. Subscribers are allowed to share copies

by oso2k 3y ago

> red hat circumvents that by using a support contract that terminates when users share their copy. This is not true. Subscribers are allowed to share copies of source code, per the GPL, without penalty. See Section 1.4 of https://www.redhat.com/licenses/Appendix-1-Global-English-20230620.pdf https://www.redhat.com/licenses/Appendix-1-Global-English-20... Also, penalizing customers for sharing source code makes no sense when we already do that by upstreaming our work and our internal policy is to "Upstream First". https://www.redhat.com/en/blog/what-open-source-upstream https://www.redhat.com/en/blog/what-open-source-upstream

em-bee 3y ago
if they can share all the sources freely, then what exactly is preventing anyone from building RHEL clones?
- oso2k 3y ago
  Skill? Funding? Effort? Nothing? It’s why we have CentOS’s origination before we hired the developers, Oracle’s Enterprise Linux, RockyLinux, AlmaLinux. We have invested massive amounts of dollars & human resources into our CI/CD, QA/QE, and performance testing. Maybe that worries people? That’s speculation on my part. What we changed (my opinion: doesn’t represent what Red Hat is saying, has said, or will say) was an optimization (or correction for an oversight) to our CI/CD process after making CentOS the upstream to RHEL. We used to sanitize the RHEL srpms of Red Hat trademarks, graphics, proprietary information, embargoed information or source, etc. Since of a lot of the RHEL developers are CentOS, Fedora, upstream developers and this helped especially those CentOS developers. But if RHEL is downstream and already a git pull of those CentOS, Fedora, upstream, then sanitizing srpms is redundant, duplicative and even unnecessary for CentOS’s benefit.
  - em-bee 3y ago
    i am not doubting your words, but if it were that simple then we would not have all this brouhaha about RHEL clones not being able to continue. or well some of them did. there was one who said that they would be able to continue as before which would confirm that this is actually possible. note that i am not arguing whether RHEL clones should exist, but only whether they are able to exist without anyone breaking any kind of contract. i do hope you are right, but the current public sentiment seems to be that this is not the case.
    - oso2k 3y ago
      I agree public sentiment does not seem to align with the change. And I believe a lot of sentiment was influenced by social media personalities, leaders of the post CentOS upstream projects. Even our competitors like Oracle and SUSE jumped in. Almost all my accounts have some CentOS or other RHEL clones. We’re not suing those customers because they chose another Linux for a part of their footprint. We’re also not suing the clone makers. You’d think with all the lawyers we have access to, that would be an easy way to kill off clones. But we’re upstream first. Best ideas win. They tell you that on day one.
      - oso2k 3y ago
        Also, thinking of this a bit more. I must admit, if my business plan was to clone Red Hat’s srpm repos and rebuild them (overly simplified), then losing access to Red Hat’s srpm repos would cause a lot of emotions. That srpm repo was taken away. That said, the access to the upstream git repos hasn’t changed.
        em-bee 3y ago
        That srpm repo was taken away exactly that is the crux of the problem that is getting everyone upset. do customers still have access to that? the access to the upstream git repos hasn’t changed but that does not allow building a 100% RHEL clone. although it is probably enough to build something sufficiently compatible. which is i think the way one of the former clones went and which is probably good enough for at least a subset of clone users. like for me, i just want a distribution that has long term stable releases. RHEL compatibility is actually secondary to not important at all in my use case. btw: i am happy we can have this discussion without the emotions that usually go along with it. it can be difficult to get something across with all the noise everyone else is making.
        oso2k 3y ago
        >> That srpm repo was taken away > exactly that is the crux of the problem that is getting everyone upset. do customers still have access to that? Customers will always have access to srpms. They will, however, contain legally encumbered artifacts. >> the access to the upstream git repos hasn’t changed > but that does not allow building a 100% RHEL clone. although it is probably enough to build something sufficiently compatible. Taking away sanitized srpm drops probably does affect those distros who would like to be a downstream of RHEL. Playing devil's advocate to downstreamers: But why wouldn't you want to collaborate with us in the upstream? Are they maybe implicitly recognizing the value in the engineering that Red Hat does? Or maybe even just the name Red Hat Enterprise Linux? The GPL is a license and contract between two entities. We have no such contracts with non-customers. Maybe that is unfortunate. In 2019 before IBM completed the acquisition, (https://www.sec.gov/Archives/edgar/data/1087423/000108742319000012/rht-10kq4fy19.htm https://www.sec.gov/Archives/edgar/data/1087423/000108742319...), we had Sales & Marketing expenses of $1.38B. We spent $668.5M on R&D. About $2B spent on employees selling, marketing, teaching, documenting, building, maintaining, certifying, supporting, enhancing, testing OSS, including contributions to conferences, foundations, consortiums, of many, many different OSS interests. Over 200 upstream projects (https://redhatofficial.github.io/#!/main https://redhatofficial.github.io/#!/main). I think about all the folks I've worked with in Consulting, Support, Engineering, Sales, Product Management, Technical Marketing, Recruiting. I think about their families and loved ones. ...And I feel like we're doing alright by OSS with what we're getting out of it. It might not be a perfect or ideal model for everyone. Most of us are willing to improve where we can. > btw: i am happy we can have this discussion without the emotions that usually go along with it. it can be difficult to get something across with all the noise everyone else is making. Agreed. I do wish the discourse was less emotional that it has been. Many folks making assumptions without taking the chance to ask clarifying questions.

by oso2k 3y ago

em-bee 3y ago

if they can share all the sources freely, then what exactly is preventing anyone from building RHEL clones?

oso2k 3y ago
Skill? Funding? Effort? Nothing? It’s why we have CentOS’s origination before we hired the developers, Oracle’s Enterprise Linux, RockyLinux, AlmaLinux. We have invested massive amounts of dollars & human resources into our CI/CD, QA/QE, and performance testing. Maybe that worries people? That’s speculation on my part. What we changed (my opinion: doesn’t represent what Red Hat is saying, has said, or will say) was an optimization (or correction for an oversight) to our CI/CD process after making CentOS the upstream to RHEL. We used to sanitize the RHEL srpms of Red Hat trademarks, graphics, proprietary information, embargoed information or source, etc. Since of a lot of the RHEL developers are CentOS, Fedora, upstream developers and this helped especially those CentOS developers. But if RHEL is downstream and already a git pull of those CentOS, Fedora, upstream, then sanitizing srpms is redundant, duplicative and even unnecessary for CentOS’s benefit.
- em-bee 3y ago
  i am not doubting your words, but if it were that simple then we would not have all this brouhaha about RHEL clones not being able to continue. or well some of them did. there was one who said that they would be able to continue as before which would confirm that this is actually possible. note that i am not arguing whether RHEL clones should exist, but only whether they are able to exist without anyone breaking any kind of contract. i do hope you are right, but the current public sentiment seems to be that this is not the case.
  - oso2k 3y ago
    I agree public sentiment does not seem to align with the change. And I believe a lot of sentiment was influenced by social media personalities, leaders of the post CentOS upstream projects. Even our competitors like Oracle and SUSE jumped in. Almost all my accounts have some CentOS or other RHEL clones. We’re not suing those customers because they chose another Linux for a part of their footprint. We’re also not suing the clone makers. You’d think with all the lawyers we have access to, that would be an easy way to kill off clones. But we’re upstream first. Best ideas win. They tell you that on day one.
    - oso2k 3y ago
      Also, thinking of this a bit more. I must admit, if my business plan was to clone Red Hat’s srpm repos and rebuild them (overly simplified), then losing access to Red Hat’s srpm repos would cause a lot of emotions. That srpm repo was taken away. That said, the access to the upstream git repos hasn’t changed.
      - em-bee 3y ago
        That srpm repo was taken away exactly that is the crux of the problem that is getting everyone upset. do customers still have access to that? the access to the upstream git repos hasn’t changed but that does not allow building a 100% RHEL clone. although it is probably enough to build something sufficiently compatible. which is i think the way one of the former clones went and which is probably good enough for at least a subset of clone users. like for me, i just want a distribution that has long term stable releases. RHEL compatibility is actually secondary to not important at all in my use case. btw: i am happy we can have this discussion without the emotions that usually go along with it. it can be difficult to get something across with all the noise everyone else is making.
        oso2k 3y ago
        >> That srpm repo was taken away > exactly that is the crux of the problem that is getting everyone upset. do customers still have access to that? Customers will always have access to srpms. They will, however, contain legally encumbered artifacts. >> the access to the upstream git repos hasn’t changed > but that does not allow building a 100% RHEL clone. although it is probably enough to build something sufficiently compatible. Taking away sanitized srpm drops probably does affect those distros who would like to be a downstream of RHEL. Playing devil's advocate to downstreamers: But why wouldn't you want to collaborate with us in the upstream? Are they maybe implicitly recognizing the value in the engineering that Red Hat does? Or maybe even just the name Red Hat Enterprise Linux? The GPL is a license and contract between two entities. We have no such contracts with non-customers. Maybe that is unfortunate. In 2019 before IBM completed the acquisition, (https://www.sec.gov/Archives/edgar/data/1087423/000108742319000012/rht-10kq4fy19.htm https://www.sec.gov/Archives/edgar/data/1087423/000108742319...), we had Sales & Marketing expenses of $1.38B. We spent $668.5M on R&D. About $2B spent on employees selling, marketing, teaching, documenting, building, maintaining, certifying, supporting, enhancing, testing OSS, including contributions to conferences, foundations, consortiums, of many, many different OSS interests. Over 200 upstream projects (https://redhatofficial.github.io/#!/main https://redhatofficial.github.io/#!/main). I think about all the folks I've worked with in Consulting, Support, Engineering, Sales, Product Management, Technical Marketing, Recruiting. I think about their families and loved ones. ...And I feel like we're doing alright by OSS with what we're getting out of it. It might not be a perfect or ideal model for everyone. Most of us are willing to improve where we can. > btw: i am happy we can have this discussion without the emotions that usually go along with it. it can be difficult to get something across with all the noise everyone else is making. Agreed. I do wish the discourse was less emotional that it has been. Many folks making assumptions without taking the chance to ask clarifying questions.