Red Hat refuses Alma's CVE patches to CentOS Stream; says "no customer demand"

https://lemmy.world/post/1818665

Red Hat refuses Alma's CVE patches to CentOS Stream; says "no customer demand" - Lemmy.world

It’s a bold strategy, Cotton. Let’s see if it pays off for them.

As someone interviewing for Canonical’s Security team (they make you do like 10 interviews, I’m like 5 deep over 3 weeks), I cannot imagine anyone security-minded writing that comment. It either:

  • Comes from higher up
  • Michal doesn’t think security is important

Can you prove that your joining Canonical (picture proof), as you know, people can be anything in the internet while they’re in their parent’s basement.

If you are, what type of interview questions do they ask?

He has not joined yet. What is he supposed to prove?

Proof that he is being interviewed by canonical, which he did send, which I am grateful for.

Ain’t nothing wrong with asking for proof and you shouldn’t be mad as anyone can be behind a username with or without a pfp.

Are you this obnoxious to people you meet offline?
@MrOzwaldMan first you attack someone then want an answer, interesting strategy

I mean anyone can be behind a username with or without a pfp.

How would I know NoobMaster69 is a Google Software Engineer or a part time Janitor or a 9yo using ChatGOT

I mean sure, here you go. I’m in stage 3 of 4 right now:

Congrats, I hope you excel in your journey with canonical.
Wasn’t Red Hat just complaining that Alma and Rocky didn’t add value because they weren’t submitting fixes upstream?
There goes the narrative. Didn’t last very long, did it?
Its funny how podcasters and commenters seem to have taken Redhat’s spin about “contributing value to the community” seriously, while to the rest of us the whole thing was obviously only about money (same as all the follow-ups from other parties… I would say “including Alma” but that would probably deserve its separate debate).

The point of FOSS is not and has never been that people should “contribute value”, that’s the capitalist rhetoric and christian protestant ethic that’s so ingrained in many that people fall for it.

None of the FOSS licenses contain anything about having to contribute, they’re all about preserving the freedom of the software, and contributions automatically emerge from that concept: having the source available empowers people to solve their problems, and the license ensures that they contribute their solutions, but there is absolutely no requirement nor moral obligation for anyone who takes, uses or redistributes FOSS to make a contribution.

Exactly. "Oracle freeloading" isn't through some loophole they're exploiting. It's the core premise of the license to allow them to do exactly that.

Red Hat saying that argument in-particular shows they’ve pivoted their philosophy significantly, it’s a seemingly subtle change but is huge - presumably due to the IBM acquisition, but maybe due to the pressures in the market right now.

It’s the classic argument against FOSS, which Red Hat themselves have argued against for decades and as an organisation proved that you can build a viable business on the back of FOSS whilst also contributing to it, and that there was indirect value in having others use your work. Only time will tell, but the stage is set for Red Hat to cultivate a different relationship with FOSS and move more into proprietary code.

— “we don’t like people ripping off our work without any added value”

— “Here, let me push this to your prod environment, totally breaking your quality process”

— “No”

— “Well, what the hell do you want broo?”

“we don’t like people ripping off our work without any added value”

  • “Shouldn’t have based your entire OS on FOSS software then.”

The end.

  • they are not breaking any law. This is totally allowed. You can use FOSS to create a commercial product.

  • they are major contributors to the Linux space. And they’ll keep contributing.

  • It’s their effort, they created a business around it, and it cycles back to push Linux forward.

  • this isn’t even going to affect average users. This is going to take money from companies that probably have the money to pay. For other companies, there are other distributions available.

  • Absolutely! They are not breaking the law by building upon FOSS software, but by exactly the same logic rebuilders and forkers aren’t breaking the law either.

  • Irrelevant. Contribution doesn’t mean ownership or entitlement.

  • Irrelevant. They built a business around FOSS software that they don’t own and never owned. If they want to have the benefits of that, they should take the consequences of it too.

  • Irrelevant. This is not a matter of money but a matter of freedom and principles.

  • Well, the re-builders would be breaking the law now that the source code isn’t available for non-paying customers. They weren’t breaking the law before.

    So, do you expect every company to release the source code of their products just because they used a FOSS web framework? That’s such an unreasonable position.

    Well, the re-builders would be breaking the law now that the source code isn’t available for non-paying customers. They weren’t breaking the law before.

    No they would not. The sources are still licensed under the GPL, and if the rebuilders can acquire the sources, they are legally allowed to use them. Red Hat does not have the liberty to relicense the sources because they don’t own them. Do you understand that?

    So, do you expect every company to release the source code of their products just because they used a FOSS web framework or a FOSS programming language like Python? Or by the same logic, for companies to release the source code of their products if their developers use Linux in their development machines? Or if they use Linux to deploy their applications in the cloud? That’s such an unreasonable position.

    That is an invalid comparison. Of course it’s possible to write non-FOSS code in most languages, including python. A C program is not a derivative work of GCC, a python script is not a derivative work of python and so on. If you use external libraries or a framework, you indeed have to be mindful of the license it comes under, because it may affect the licensing of your program (LGPL vs GPL comes into play here), but of course that’s only an issue if you distribute the software.

    But … that’s not what Red Hat is doing with RHEL, and this is why your comparison is invalid. They are not merely distributing some independently written python or C programs, they are distributing the actual FOSS software itself or derivative works thereof. RHEL includes things like the linux kernel, systemd, selinux, gcc, glibc, all the gnu utilities, bash, python, perl, … all this is code under FOSS licenses that Red Hat does not own the copyright to, so they can’t just choose to relicense it and they need to obey the respective FOSS licenses. I don’t think it’s an unreasonable position at all to expect companies to obey the licenses of the software that they use or distribute. In fact I think it’s the only position you can take.

    OK, so is Redhat breaking any license?
    RedHat is not breaking any licenses, but neither are people who acquire the source code and redistribute it. This is also covered under GPL.
    Maybe I just don't get it, but how does this work in any way that doesn't make them liable for some company being exploited by something that they were aware could've been prevented?

    Maybe, but in practice nothing happens. Microsoft has had numerous issues reported to them before, years ago, and the issue reported to them was never fixed or taken seriously. Then years later, the issue is sometimes rediscovered and they find the report from years earlier, and nothing happens.

    Until legislation gets passed to force companies to take liability of their software, nothing will change.

    Everyone is going to have to accept that RHEL is over and done. Since paying customers are not allow to release the code publicly, overtime it could turn into its own ooerating system that happens to use the Linux kernel, similar to Android.

    Forget about Red Hat, they're gone, they're not an option for any small company. Individuals should never have been using Red Hat, but companies are going to have to find something else like Debian/Devuan, FreeBSD, something with a stable branch that gets 3 to 4 years of updates.

    RHEL ultimately comes from Fedora (plus Redhat has a great say in where Fedora is headed), so… RHEL won’t become sort of an AIX or HPUX anytime soon.

    That said, Redhat’s move opens up the position of “enterprise-like distro for scientific/technical shops and other people who do their own support” (think, from CERN to small software houses) that so was the reign of RHEL clones (together with Ubuntu, of course).

    Those are people who will probably never buy RHEL licenses for all their machines no matter what, so in a sense it stands to reason that RH doesn’t care about them (if you think their move is about money rather than falling for the “value to the community” PR spin), but those same people are also trend setters whose choices, in time, trickle down to universities and then companies, and to me it looks like there’s a huge opportunity there (and that Alma is currently in the best position to harvest from it in the long run).

    Is there a reason that Alma and/or Rocky shouldn't try to release their own version of SLES and SLED?

    Everyone is going to have to accept that RHEL is over and done

    Except they’re not. Almost nobody in their customer base (enterprises) is going to care one bit about any of this drama. They’ll have their support contracts and software certified for RHEL and they’ll keep paying Red Hat for the privilege, and RHEL will remain the dominant distribution in the enterprise market.

    The danger is that if we stop caring, and let Red Hat have their way, distros like Rocky and Alma will become endangered and access to a free and unencumbered RHEL compatible distribution may eventually be cut off entirely. This would give Red Hat a de facto monopoly and a stranglehold on the enterprise market, and eventually it may even drift so far away from mainstream Linux that due to incompatibilities you just can’t run the same workloads on a Debian system anymore. This would land us right back to the situation where we started in the 1990s, where a select few companies (i.e. IBM, Sun, Microsoft, HP,…) controlled the market with their closed source mutually incompatible operating systems.

    Saying things like “forget about Red Hat” is defeatism and running away from a fight that should be fought.

    That's exactly what's already happened. Rocky and Alma are already no longer an option for a free version of Red Hat since Red Hat code is not allowed to be shared, it can only be viewed. Read their own words from Alma and Rocky, what they themself said about oing forward.

    Red Hat can also change the license agreement further to include anyone proven to have published source code of Red Hat branded material agrees to pay a fee to Red Hat of no less than $10 million, or whatever price they want to put on it.

    Everyone can scream about Red Hat, all they have to have to do is change some wording in agreement that includes fees(fines) for multi millions of dollars, BOOM! Red Hat becomes a proprietary system built on open source software.

    SUSE says they will fork RHEL, but Alma and Rocky are over in terms of being a clone. People have asked for years why there is no free 1 to 1 clone of SLES and SLED. IBM is free to choose to turn all of RHEL in a proprietary development and lock it down, unless you can get a court order that says Red Hate's code must be made public, but I don't dare test IBM lawyers over any code that is not released under AGPLv3, only then I would.

    Red Hat can also change the license agreement

    It’s not a license agreement, it’s a terms of service agreement. The license of the software is still the GPL (or any of the other FOSS licenses that apply).

    all they have to have to do is change some wording in agreement that includes fees(fines) for multi millions of dollars

    The point where they introduce punitive terms to the terms of service agreement in response to redistribution, is also the point where their argument that “they’re free to choose who they do business with” breaks down because they’re no longer just ending their business relationship with you, they’re imposing a punishment. They wouldn’t just be skirting the GPL, they would be blatantly violating it.

    I would love to see IBM lawyers try to get that fee enforced when a customer exercises their GPL granted freedom to distribute a piece of software that Red Hat didn’t create and own to begin with.

    The GNU/Linux GPLv2 does not apply to any software developed and owned by Red Hat like all of the Red Hat security programs, that is not covered by the Linux license. If Red Hat never modifies or changes a single line of code in GNU/Linux, they are free to run closed source programs on top of it. They own .rpm file format so they have the legal freedom to make the system and all RH software proprietary.

    That's how Rocky and Alma are now permanently locked out from accessing the code.

    There is much more GPL (and other FOSS licensed) software in Linux than just the kernel, and for the vast majority of it Red Hat does not own the copyrights even if they made enhancements to it, so Red Hat is not at liberty to relicense it. Often if they did write the software they don’t own the copyrights to it. For example: systemd is largely written by but not owned by Red Hat, copyright belongs to the individual contributors so it’s near impossible to ever relicense it. Same with selinux, Red Hat owns parts of it, but not completely (it was originally created by the NSA), so they can never relicense it without completely ditching the parts they don’t own.

    As for RPM, no they don’t own the format (which is just something trivial like cpio with text header files anyway), it’s even part of the LSB. They do own the copyright to the program, but it’s licensed under the GPL. Going forward, they could theoretically relicense it and make future versions closed source and incompatible, but they can never un-release or un-license the versions of the software they’ve already put out there.

    Anyway, this relicensing of Red Hat owned sources is not what they have been doing, because they still want to reap the benefits of open source software (i.e. community contributions). So most of the software they hold the copyrights to is licensed under the GPL as well. The only immediate example I can think of is the anaconda installer, which you can find here: github.com/rhinstaller/anaconda License: GPL v2.0

    GitHub - rhinstaller/anaconda: System installer for Fedora, RHEL and other distributions

    System installer for Fedora, RHEL and other distributions - rhinstaller/anaconda

    GitHub

    Until someone gives legal notice to IBM lawyers forcing Red Hat source code to be released pulicly, all of this debating over it means jack nothing.

    If nobody takes IBM to court, the matter is settled and all developers must accept Red Hat's choices.

    If they dismiss the online talk, ignore all criticisms, and nobody pays for a lawsuit, the case is done and finished.

    I'm not trying skip over your points, as I said from my first first, everybody can talk all they want, who has the power of persuasion or legal force to change IBM's decision?

    I may be wrong, but I believe only the Linux Foundation is a position to call IBM CTO, President, whoever, and say "We heard about the changes to with holding Red Hat's source code, you will not be doing that, it shall remain public. If you want to discuss this further, please send your most expensive lawyers to our offices and we will explain in detail why you won't be doing that."

    Until someone gives legal notice to IBM lawyers forcing Red Hat source code to be released pulicly, all of this debating over it means jack nothing.

    That’s a misunderstanding. Even according to the GPL Red Hat doesn’t have to release their source publicly (though it would have been nice if they had kept doing that), they only have to give it to those who they give the binaries to (i.e. RHEL customers). The big issue is that they are trying to restrict their users from redistributing the sources that they are legally entitled to, which is a freedom they should have according to the GPL.

    Section 6 of the GPL v2.0 says:

  • Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients’ exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.
  • If nobody takes IBM to court, the matter is settled and all developers must accept Red Hat’s choices.

    I believe it’s the other way around. IBM needs to take someone to court over this to enforce their rules. For example, a customer who re-distributes RHEL sources or the Rocky Linux developers if (according to IBM) they “illegitimately” acquire RHEL sources.

    I may be wrong, but I believe only the Linux Foundation is a position to call IBM CTO, President, whoever

    You would be wrong indeed. Technically, anyone who holds a copyright on any part of a GPL licensed program that is included in RHEL could sue IBM for GPL violations. So even a developer of something silly like for example, cowsay, could do this.

    The likely retaliation RH/IBM would take is simply banning the account, not starting a lawsuit immediately. However, rights holders may attempt sue before or after such an event, but likely after.

    RH thinks they have the right to distribute code in this manner, and they can keep doing so until challenged in court. You can do actions in general without asking the court every time, I think the same applies here as well.

    I personally think it is a violation in a strict sense, but at the same time I don’t think it really matters too much realistically. Stream is upstream RHEL, and they are very similar, and at some points in time, should be identical. It’s also not clear what you get exactly by suing RH/IBM. The likely case is that they settle or rule to have that section removed from the ToS.

    Why do people care about RHEL? Is it really any better than Debian based stuff?
    I really don't care about RHEL. Unless companies want to buy their services to be allowed access to the software it, everyone should forget about Red Hat. It's done, it's gone. And there will never be a free version of Red Hat, so look at other long term alternatives.
    It checked a lot of boxes for corporation use. SELinux isn’t/wasn’t on debian either. But it’s not any ‘better’. Debian has been rock solid for me. ZFS is the only thing I’d like to see in Debian feature-wise.
    Because I have to use rhel7 at work 😬

    This makes me much more upset than Red Hat asking people to rebase on CentOS Stream.

    This is ridiculous.

    I haven’t been really keeping up with this RHEL drama, so I’m probably going to regret making this comment. But about this bug merge request in particular, you have to remember that RHEL’s main target audience is paying enterprise customers. It’s the “E” right there in RHEL. So stability is a high priority for their developers, since if they accidentally introduce a bug to their code, then they’ll have a lot of unhappy paying customers.

    The next comment that was cropped out of that screenshot basically explains exactly that. While the Red Hat developers probably appreciate the bug fix, the reality is that the bug was listed as non-critical, and the Red Hat teams didn’t have the capacity to adequately regression test and QA the merge request. But the patch was successfully merged into Fedora, so it will eventually end up in RHEL through that path, which is exactly what the Fedora path is for.

    The blowup about this particulat bug doesn’t seem justified to me. Red Hat obviously can’t fix every single bug that’s listed in their bug tracker. So why arbitrarily focus on this one medium priority bug? if it were listed as a critical bug, then yes, the blowup would be justified.

    That could have been better communicated though. What you said is reasonable, what Michal said isn’t as much.
    But it is also another stab in the community, they took centos that was a community project for them, then transformed this project that was downstream to upstream, then called all other distros a negative net worth cause they don’t engage in the process of RHEL, then blocked the acess to this distros to the downstream, then reject the work of this ppl they called net negative without a decent process. This is what everyone is pissed, what actually red hat wants? Centos that was a community process was kidnapped and is only a beta branch now? Ppl who wants derive from centos should be fixing everything downstream and duplicate work just cause centos is just an internal beta from red hat? If yes, why they took the project from the community?
    I’m making no comment on CentOS being absorbed and repurposed by Red Hat. I’m just saying it makes sense why Red Hat would rather have this fix in Fedora than CentOS Stream.
    I’m making no comments about you making or no comments on centOS being repurposed. I’m just saying that this blown-up is probably caused by a mixture of miscommunication between RHEL and a community that feels like being tossed aside, I just said that because you said that you felt unjustified.

    I’m getting downvoted on my comment about not making a comment on CentOS, so now I feel obligated to reply to this.

    I don’t know, dude. I don’t really care about the miscommunication. I was just focusing solely on the merits of the merge request’s code changes.

    For the miscommunication, it seems like a two way street to me. That was GitLab, so the Red Hat dev was probably operating under the assumption that people there already understood everything about their testing process. But obviously that’s not the case, so Red Hat should create better boilerplate responses for these scenarios. But on the other side of the coin, whoever took this screenshot and posted it to reddit or wherever did so prematurely, imo. They should’ve asked around a bit to make sure it was a legitimate thing to blow up about before they sent a lynch mob to the merge request.

    I’m still getting downvoted, so I’m just going to put this here and be done with this:

    RTFM about DevOps

    I’m getting downvoted on my comment about not making a comment on CentOS

    No, you are probably getting downvoted because you said this:

    The blowup about this particulat bug doesn’t seem justified to me.

    And seems somewhat offended that I replied to this statement trying to explain (not necessarily justify)

    I’m getting downvoted because I’m not conceding that the miscommunication was a legitimate excuse for that blowup. And I’m going to continue to not concede that. I found this whole situation to be embarrassing, and I think instead of getting mad at the miscommunication, you should all be getting mad at the moron who took that screenshot and whipped up the mob frenzy to swarm that merge request, because ultimately Red Hat was 100% justified in not accepting that merge request, and it made you all look like morons.

    It’s fine to get mad on social media, but if you’re contributing to GitLab or someplace else, then you need to slow your roll. There’s always a process involved when contributing to a project, and you have to learn that process in order to contribute effectively. You can’t blow up and whip up a social media frenzy at the slightest inconvenience.

    What actually red hat wants?

    All the money.

    Besides that, I suspect they have no clear vision. And if they do, they are absolutely terrible at communicating that.

    Except that they are not expecting to merge this into Red Hat. They are sending it to CentOS Stream.
    CentOS Stream is midstream of RHEL and Fedora. That sounds like it’s like a cert type of environment for RHEL. The same logic would apply there. You don’t want to be introducing a bunch of new changes to code once it’s in the cert environment unless they’re critical.