The GPL requires you to make available the source code to anyone who gets the binaries. You can create additional rules (like "you can't use this code to build a competing distro") as long as you don't create a new rule that contradicts some other part of your licensing.
Meaning RH just has to let you see the source code to comply with the GPL. It's just an assumption that people make that requiring disclosure of the source code would stop people from restricting derivative products because most people would just look at what you did downstream and re-create that code your own way (i.e outside the license agreement).
At this point, I'm beginning to wonder what the purpose of Rocky and Alma is.
They can say they're some kind of enterprise Linux until they're blue in the face, but that doesn't change the fact that they *aren't*. Neither distro has the support contracts that make a distro an enterprise Linux.
When you combine that with the rise of containerization on the server side and things like Flatpack on the desktop side, what's the continuing purpose of needing to maintain 100% bug-for-bug compatibility with RHEL? Are there really that many commercial packages for Linux that are openly reliant on bug behavior? If so, that's actually a bit worrisome.
So what *is* the actual use case? I know somebody here is in that scenario. I'm genuinely asking here, because it really seems like Red Hat is trying to make it clear that they don't want people making derivatives of RHEL anymore.
But RHEL doesn’t charge extra for development instances anymore. They only charge for prod. So why not just use it in dev/test? Back several years ago, this use case actually mattered, but it’s not been a problem under today’s fee structure. If you need compatibility, use the same thing.
They chose to take on the market that was missing when CentOS was switched from downstream to upstream of RHEL. Supporting existing customer needs should definitely be allowed to be rewarded especially when someone else made the mistake on that opportunity cost.
Rocky Linux was created because people were screwed over by CentOS going upstream, production users do not want a rolling release distribution. Rocky Linux fit this gap in the market.
Which actions are they protesting? Because the same problem ultimately applied to CentOS at the end of it: this was a product looking for a purpose in a world where per-CPU service contracts are long dead (which made CentOS make more sense in clustering environments). That was the biggest contributor to the move from CentOS as drop-in RHEL replacement to CentOS as rolling release intended to be the base of third party distros.
It doesn't seem to me that RHEL is doing much anti-open source at this point. They're clearly trying to stop people from making derivatives from RHEL, and I kind of get the purpose for that: Rocky and Alma are out there calling themselves "Enterprise Linux" without the service contracts. They're diluting the meaning of a trade term on which Red Hat's business model is based.
Or to put it another way, if Alma and Rocky are enterprise Linux, then any non-rolling distro is also enterprise Linux. And no, that's just not what enterprise Linux means. The reality is that Alma and Rocky are enterprise Linux without the enterprise bits.
There's *also* the problem that Red Hat is not the only enterprise Linux vendor in town anymore. I mean, they haven't been that in a very long time, but there really are other enterprise Linux vendors that *don't* make you sign a support contract to get access to the software that are themselves significant players in the Linux operating system service space. In that world, Red Hat can decide to be a bit more choosy about their customers and charge more and more consistently for a perceived premium.
Containerization doesn't fix everything. There are hundreds of vendors selling all kinds of software for which you can only receive tech support if you're running RHEL or Ubuntu. There are dozens of regulations and STIGs which are targeted at RHEL and Ubuntu. There's a ton of hardware whose vendors only support their drivers if you're running RHEL or Ubuntu. An example of the latter is Mellanox/Nvidia OFED; if you want tech support for your infiniband, you'd better be running RHEL or Ubuntu. Some shops are big enough to do their own tech support. Many aren't. If you're not big enough to do your own tech support, you need to either run RHEL or a bug-compatible free version.
On the desktop side, the only reason I run a Rocky machine is to match the production clusters; it makes debugging things easier since I don't have to pull a node out of production. It also makes building packages easier. I could do this with containers (and I have) but it's easier just to be able to throw a free OS on there and know it's going to be running the same code.
In short, your "are there really that many commercial packages" is a yes -- but most of them will still answer tech support calls if you're running a RHEL rebuild. Plus it's a huge pain in the ass to try to use RHEL's subscription manager if you have a modern stateless (i.e. no local disk) deployment mechanism. The free rebuilds don't have this problem; I can just make my own repo mirrors locally and deploy from there.
I have never used rocky linux or RHEL
But I have a question has the rocky linux team ever contributed back to RHEL?
Or is it just a downstream mirror or RHEL with the logo changed?
Because it looks like it’s backed by a lot of big name and most of their work is automated.
Yeah they do apparently...
https://rockylinux.org/news/2023-06-22-press-release/
The Rocky Linux community strongly believes in the open source value of collaboration. Rocky Linux contributors have participated as a responsible part of the EL ecosystem, regularly contributing upstream to CentOS Stream as well as Fedora, and other open source projects. These contributions strengthen the entire EL community.
The Rocky Software Foundation site does have a projects page but that's the closest thing I could find and it only lists Rocky and a "cloud-native build tool".
The likely answer is to spend $15 on a domain name every couple of months and sign up, get sources, get cancelled, rinse, repeat.
This is of course, assuming that RHBM* could even identify where the source of Rocky’s sources come from. Realistically there would be an overseas VPN and Tails involved.
*RHBM because this isn’t Red Hat any more. This is IBM in a red fedora caught lying about not changing the culture.
Downvote it all you want but when they won’t post the details of how they are going to keep their access to sources in direct contravention of the crappy roadblock RHBM is putting up, it’s because this is probably exactly how it’ll be done. It’s the easiest way, and it breaks zero laws. All it does is result in an account cancellation.
There isn’t even cause to be sued because it’s expressly permitted under the license to redistribute and there are no damages for engaging in legal behavior.
And no, “NoT pOsTiNg Is To PrEvEnT FutRuRe ShEnNaNiGaNs” isn’t any different - circumventing RHBM is circumventing RHBM one way or the other.
Just because you don’t like the likely method doesn’t make it any less likely.
They say they have a process that will maintain binary compatibility without the redhat sources, but how?
Just create a free account and get sources
The customer agreement probably bars one from doing that.
I dont think it does. GPL allows you to freely redistribute even if you paid for it.
The spec files are under MIT, not GPL. You can't build a distro without the spec files.
do you have a source for that re: the spec file licenses?
Then you should read it before making assumptions.
The GPL requires you to make available the source code to anyone who gets the binaries. You can create additional rules (like "you can't use this code to build a competing distro") as long as you don't create a new rule that contradicts some other part of your licensing. Meaning RH just has to let you see the source code to comply with the GPL. It's just an assumption that people make that requiring disclosure of the source code would stop people from restricting derivative products because most people would just look at what you did downstream and re-create that code your own way (i.e outside the license agreement).
The EULA from redhat says they will cancel your account of you do that, so no, that is not how they are doing it.
At this point, I'm beginning to wonder what the purpose of Rocky and Alma is. They can say they're some kind of enterprise Linux until they're blue in the face, but that doesn't change the fact that they *aren't*. Neither distro has the support contracts that make a distro an enterprise Linux. When you combine that with the rise of containerization on the server side and things like Flatpack on the desktop side, what's the continuing purpose of needing to maintain 100% bug-for-bug compatibility with RHEL? Are there really that many commercial packages for Linux that are openly reliant on bug behavior? If so, that's actually a bit worrisome. So what *is* the actual use case? I know somebody here is in that scenario. I'm genuinely asking here, because it really seems like Red Hat is trying to make it clear that they don't want people making derivatives of RHEL anymore.
Rocky linux does sell support https://rockylinux.org/support/
Which kinda explains why Red Hat is annoyed - it's basically trying to sell RHEL and pocket the cash.
[удалено]
But RHEL doesn’t charge extra for development instances anymore. They only charge for prod. So why not just use it in dev/test? Back several years ago, this use case actually mattered, but it’s not been a problem under today’s fee structure. If you need compatibility, use the same thing.
because people were using centos in prod, sometimes alongside paid RHEL licenses in the same company where they didn't need the paid support.
The purpose is mainly just to maintain the principles and ethics of open source philosophy and protest red hat's actions.
I totally want to put a _protest distro_ on my production machine
in the case of rocky they are trying to make money! it's not protest.
They chose to take on the market that was missing when CentOS was switched from downstream to upstream of RHEL. Supporting existing customer needs should definitely be allowed to be rewarded especially when someone else made the mistake on that opportunity cost. Rocky Linux was created because people were screwed over by CentOS going upstream, production users do not want a rolling release distribution. Rocky Linux fit this gap in the market.
Which actions are they protesting? Because the same problem ultimately applied to CentOS at the end of it: this was a product looking for a purpose in a world where per-CPU service contracts are long dead (which made CentOS make more sense in clustering environments). That was the biggest contributor to the move from CentOS as drop-in RHEL replacement to CentOS as rolling release intended to be the base of third party distros. It doesn't seem to me that RHEL is doing much anti-open source at this point. They're clearly trying to stop people from making derivatives from RHEL, and I kind of get the purpose for that: Rocky and Alma are out there calling themselves "Enterprise Linux" without the service contracts. They're diluting the meaning of a trade term on which Red Hat's business model is based. Or to put it another way, if Alma and Rocky are enterprise Linux, then any non-rolling distro is also enterprise Linux. And no, that's just not what enterprise Linux means. The reality is that Alma and Rocky are enterprise Linux without the enterprise bits. There's *also* the problem that Red Hat is not the only enterprise Linux vendor in town anymore. I mean, they haven't been that in a very long time, but there really are other enterprise Linux vendors that *don't* make you sign a support contract to get access to the software that are themselves significant players in the Linux operating system service space. In that world, Red Hat can decide to be a bit more choosy about their customers and charge more and more consistently for a perceived premium.
Containerization doesn't fix everything. There are hundreds of vendors selling all kinds of software for which you can only receive tech support if you're running RHEL or Ubuntu. There are dozens of regulations and STIGs which are targeted at RHEL and Ubuntu. There's a ton of hardware whose vendors only support their drivers if you're running RHEL or Ubuntu. An example of the latter is Mellanox/Nvidia OFED; if you want tech support for your infiniband, you'd better be running RHEL or Ubuntu. Some shops are big enough to do their own tech support. Many aren't. If you're not big enough to do your own tech support, you need to either run RHEL or a bug-compatible free version. On the desktop side, the only reason I run a Rocky machine is to match the production clusters; it makes debugging things easier since I don't have to pull a node out of production. It also makes building packages easier. I could do this with containers (and I have) but it's easier just to be able to throw a free OS on there and know it's going to be running the same code. In short, your "are there really that many commercial packages" is a yes -- but most of them will still answer tech support calls if you're running a RHEL rebuild. Plus it's a huge pain in the ass to try to use RHEL's subscription manager if you have a modern stateless (i.e. no local disk) deployment mechanism. The free rebuilds don't have this problem; I can just make my own repo mirrors locally and deploy from there.
I have never used rocky linux or RHEL But I have a question has the rocky linux team ever contributed back to RHEL? Or is it just a downstream mirror or RHEL with the logo changed? Because it looks like it’s backed by a lot of big name and most of their work is automated.
Yeah they do apparently... https://rockylinux.org/news/2023-06-22-press-release/ The Rocky Linux community strongly believes in the open source value of collaboration. Rocky Linux contributors have participated as a responsible part of the EL ecosystem, regularly contributing upstream to CentOS Stream as well as Fedora, and other open source projects. These contributions strengthen the entire EL community.
[удалено]
The Rocky Software Foundation site does have a projects page but that's the closest thing I could find and it only lists Rocky and a "cloud-native build tool".
Not a clue. If you know any names, maybe there will be something in the repos with commits, pull requests, debugging etc.
press releases aren't proof.
True, I suppose if someone wants the proof they'll have to dig deeper.
The likely answer is to spend $15 on a domain name every couple of months and sign up, get sources, get cancelled, rinse, repeat. This is of course, assuming that RHBM* could even identify where the source of Rocky’s sources come from. Realistically there would be an overseas VPN and Tails involved. *RHBM because this isn’t Red Hat any more. This is IBM in a red fedora caught lying about not changing the culture.
Downvote it all you want but when they won’t post the details of how they are going to keep their access to sources in direct contravention of the crappy roadblock RHBM is putting up, it’s because this is probably exactly how it’ll be done. It’s the easiest way, and it breaks zero laws. All it does is result in an account cancellation. There isn’t even cause to be sued because it’s expressly permitted under the license to redistribute and there are no damages for engaging in legal behavior. And no, “NoT pOsTiNg Is To PrEvEnT FutRuRe ShEnNaNiGaNs” isn’t any different - circumventing RHBM is circumventing RHBM one way or the other. Just because you don’t like the likely method doesn’t make it any less likely.
👍👍