I don't think we can simply forget that RH are the ones who made CentOS an internal project, promised to grow and support it, kill it off, and then call folks who are upset about the bait and switch "freeloaders". That seems rather dishonest, considering it is the polar opposite of what they initially promised to do.
You writing "in before" doesn't make it less true. We don't call free-clone users "freeloaders".
At the very best, "freeloader" is a term used by someone internally, but I've never ever heard it used in over 10 years in the company.
Full disclosure: Red Hat employee, not writing in the name of the company, views my own and all that. I'm also pretty pissed about CentOS dying, and like many Red Hatters, have voiced my concerns internally. I also happen to think that a lot of the online criticism is unfair, incorrect, and sometimes done in bad faith. So I'm trying to be accurate. As far as I know, nobody in Red Hat calls or even thinks of CentOS/Rocky/Alma/Oracle/... clones as "freeloaders".
That sounds unlikely. Have you been taken in by the name squatting of "centos stream" sounding like centos while being a totally different thing? That was basically the point of IBM choosing that name after extinguishing centos.
Centos was a de-branded redhat built by a community effort that behaved the same as RHEL, so you could use it to develop&test software for deployment on RHEL.
Centos stream is an unstable upstream that RHEL is partially derived from, run by IBM. It could have been "fedora", but that wouldn't have the same obfuscation properties. Presumably IBM don't really need two unstable upstream distributions and will drop one of them at some point.
There are a couple of new community redhat builds, none called centos.
It's not a "totally different thing". It's different, yes, but not that different.
The name "Community ENTerprise OS" is still perfectly accurate. The release model is a little different from CentOS and RHEL, but you still get LTS support comparable to every other LTS distro, you are still guaranteed no ABI changes, etc. RHEL is built from CentOS Stream, so nothing can go into CentOS Stream that wouldn't go into RHEL.
>RHEL is built from CentOS Stream, so nothing can go into CentOS Stream that wouldn't go into RHEL.
This isn't strictly true. The main problem with CentOS Stream is that embargoed security updates don't go into Stream until after they ship in RHEL. This means that if the developer responsible for the patch forgets to commit it to Stream, it can take weeks or even months until somebody at Red Hat notices and the patch goes out to Stream users. As one example, a couple months ago basic packages like httpd and php were 4 and 5 months behind RHEL, respectively.
Yeah, Stream is okay if you don't require bug-for-bug compatibility with RHEL and just want a familiar, relatively stable, rpm-based distro. I would say its role corresponds loosely to Debian testing, whereas Fedora is more like sid.
In reality, though, I've been advising clients to treat Stream as nothing more than a stopgap solution until they can migrate to something Debian-based. We've been burned once by the untimely EOL of CentOS 8, and the continuing drama just doesn't instill confidence in the future of any free-as-in-beer distro related to Red Hat.
> RH is a for profit company. If something they do is a money sink it would be stupid to keep it going.
It was their choice to take on the "money sink" in the first place. Failing to plan ahead and deliver on your promises is bad business and damages your reputation in the community as well.
> If you perhaps dislike for-profit companies
Now you're just jumping to wild conclusions, all because I think RH is pants on head stupid (from both a community and business perspective) for shutting down CentOS and going back on their past promises. Essentially, Red Hat is taking a sizeable business risk by shutting down their inbound funnel's flywheel to capture as much value as possible in the short term. This screams of short-term thinking. We will see if their gamble pays off.
> you are only entitled to the source if you are a user of said software
Sure. But you are entitled to have certain freedoms with that software. These freedoms include running as many instances you'd like for whatever purpose, and giving away copies of that software for other people to use. So the constructive result of these freedoms is that the cost of software is anchored around the cost of distribution, rather than an arbitrary cost set by the developer.
Now personally, I think it would be fantastic if someone were able to come up with some sensible pay-to-use libre license that still retained most of the freedom. The libre community is desperately missing straightforward funding like the proprietary software ecosystem. But it would be necessary to reduce freedom to do that, and it's not particularly clear how to best do that specifically. Any concept of "license instance" to charge based on results in assumptions about how the software is run, that basically undermines the ability to run it on a new type of thing. If the license is per core, then about "serverless"? Or let's say someone forks the software and makes substantive changes - does the original maintainer get to stick around charging rent despite not continuing development?
But what Redhat is doing here really isn't really a full on attempt at that. Given the works are still GPL and whatnot, I don't think they'll end up making any more than a speed bump for a new community bug-for-bug compatible distribution to gain popularity the way CentOS did.
And heck, it still remains to be seen whether threatening to terminate an orthogonal contract for exercising one's rights under the GPL ends up constituting an "additional restriction". If that was instead a monetary penalty for breach of contract, we would certainly say it does.
> Where does it say in the GPL, that you would be entitled to perpetual updates for every copy?
I never said that it did?
I'm saying that "unlimited free shit" [0] is seemingly a direct side effect of software freedom, as the FSF has defined software freedom.
I actually then went on to say that it would indeed be interesting to see a slightly less libre license that didn't anchor the use-instance price to within an epsilon of the distribution cost. So I don't really know what you're trying to argue with here.
[0] actually: widespread use of libre licensed software that has been distributed to others at arm's length
"you are only entitled to the source if you are a user of said software."
Correct but incomplete. One of the rights you automatically get is the right to share said source code. RedHat is making this forbidden with a contract.
IMO this is the only thing Red Hat is doing wrong
(That and changing the end of support date for Centos 8 after they had already committed to a longer timeframe. But this is a different topic.)
This is not difficult to understand at all. There's actually nothing to understand. It's facts.
How people will respond to it is where you'll have variety. I don't think it's proper to use a license then add an auxiliary thing that goes against the spirit of the thing. This is my opinion.
As long as you keep basing your product on GPLed code of course. You can always write everything yourself, take software with a more permissive license, or don't provide updates to anybody.
>You distribute binaries you have to distribute its source as well.
binaries are distributed only to those on the active contract, if you lose the contract you lose the binaries and thus the source. Of course, if you made a local backup you can still use everything for your own benefits
> if you made a local backup you can still use everything for your own benefits
This is GPL code. You can not only use both the binaries and source "for your own benefits",you can also share both forever with whomever you want. There is no revoking the GPL, nor taking the binaries or source back.
Nobody is taking anything back. If your contract with RH stops you lose access to their servers and cannot download their binaries or their source anymore. You can freely share everything you managed to download.
I don't know if you are trolling or actually think this is a clever argument but its not.
Clearly Red Hats thread of cancelling the support contract is intended to discourage source distribution. The point of the GPL is to ensure source distribution is possible. These two goals are inherently opposed.
This is incorrect. Sharing source, you receive from Red Hat as part of your Subscription, is not limited by our Subscription Agreements and there is no penalty for sharing it. See Section 1.4 here.
This Agreement establishes the rights and obligations associated with Subscription Services and is not intended to limit your rights to software code under the terms of an open source license.
This is interesting. If this is indeed the case then much of the discussion around it could be considered FUD. Why is redhat not addressing it? Why did the false idea get traction in the first place?
I do think Mike McGrath tried to communicate this. It got missed somehow.
Maybe we now got a case of foot (or even two feet) inserted into mouth. It’s highly emotional topic, even internally. I don’t know what the communications strategy is. Not my job. I will say that we’re encouraged internally, “don’t feed the trolls” and to let our various communication teams and leaders to do their jobs.
I just hope others like maddog guide the community back to sane discussions.
Both commenters to my comment used the word "simply". I don't think this is simple at all.
How is it simple for a company who wants support from a vendor to "simply" lose that support even though the license of the code was specifically designed to ensure the very thing.
another way to frame the "entitlement to free stuff" is to consider the real costs of duplicating and copying digital assets: there are essentially negligible (and less than marginal)
though I suppose this is a little difference between 'static' digital assets that we don't expect will change, like digital art, or games, or mp3 and so on... and 'runtime software' which we expect will have to continuously adapt, be improved, and will need to get updated. though this is a fine line.
why should only a few select group get to capture the enormous productivity boon enabled by digital copying? that I ask this question doesn't mean I hate capitalism, I think that there are things it's great at, and things at which capitalism sucks.
digital assets are exactly where capitalism becomes the worst, whereas material assets are exactly where capitalism is at its best.
but how long should we pay for digital assets that have already been created?
to pay for stuff already made is not an economically productive activity. it doesn't create any more value. and this is even worse over digital assets;
also, this is why I was observing a distinction between digital goods which won't change (most media expressions) and software which needs updating
I consider this an open problem; but I have a minority view, as I always get downvoted when stating this position.
as I see this, the current hollywood strike is consequence of failure to acknowledge what I'm saying. and it'll keep getting worse. the problems in academic publishing are also an expression of this things I keep saying. I'm starting to get tired of saying this shit. not only do things not change, but they keep getting worse.
I suppose property over [blank] asserts itself over the digital to the decrement of most and the advantage of few. I see it slipping away... what could have been. what we could have had with the internet as we seem to chose (and I'm dragged along) to a world where everything is a service subscription and a few lucky ones collect rent forever; I guess they already do and always have, but now they will also do it over digital assets. capturing for themselves the technologically provided boons of the digital and internet technology
> but how long should we pay for digital assets that have already been created?
That's a mis-characterization of what's going on here.
Red Hat makes RHEL. Then it (used to) goes *the extra step* of debranding RHEL, removing trademarks, and publishing it to git.centos.org.
Red Hat is not (and cannot) prevent you from getting your hands on digital assets. It just stopped going out of their way to provide you an easy (almost) 1-click way to clone their product for free. You want to create a clone of RHEL? Sure the upstreams are all available, do it.
but you are still not entitled to anyone's source code unless you are a user of the program.
do you want to pay RH's contract and distribute their code for free? well, find someone to host a VPS that will receive petabytes of traffic each month then.
you will soon find out, it's really not that "free"
You are just substituting one for another. Find enough people to chime in a dollar to fund a VPS? Find enough people to form a high bandwidth bittorrent mesh?
Potato potato, good luck serving the global market with a bittorrent version of dnf update
Their CDN bills are paid (or rather sponsored by) Fastly, and they have a mirror network hosted by universities and other third parties. No third party is going to donate resources to RHEL the way they might for Debian, though.
I'll add that those CDN bills are not at all insubstantial. But still peanuts compared to the actual development costs.
I wouldn't say they're exactly hiding behind the FSF. The FSF displays its brand of crazy front and center, like with its statements that not giving out your source code is morally evil but you should charge as much as you can for copies of your software. They fit right in.
This is kind of a weird take unless you're some corporate lacky.
Where does the GPL only refer to users? Isn't anyone supposed to be able to get access? The AGPL does, for certain; it's what I license my work under to ensure it can't be rehosted somewhere and be proprietary'd.
Interestingly, Red Hat appears to be gatekeeping what constitutes a user of their systems in order to offer GPL terms only to those who are users. This requires payment, so it's a way for business to refuse open terms unless paid for.
Why is that okay? They accept patches from community members, what moral right do they have to repackage and then withhold source when asked?
The true freeloaders of libre software have always been commercial efforts. If they couldn't freeload off of GNU, Linux, and BSD, where would we be?
Quite insulting for Red Hat to declare others to be freeloading when they are the ones profiting on the community's work. They wouldn't have a company without free software.
Nobody's entitled to profit. I hope some rights holders sue Red Hat to keep the source shared. They're perfectly free to build their own non-GPL distro on top of Linux, nobody'll stop them, and they won't have to share.
Where does the GPL only refer to users? Isn't anyone supposed to be able to get access?
the GPL always only gave rights to the users of the software, never the general public. only users have the right to get the source code. the users however also have the right to share their copy which is why it is usually pointless to not make the code public in the first place. red hat circumvents that by using a support contract that terminates when users share their copy.
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".
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.
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.
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.
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.
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.
>> 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/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). 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.
Taking away sanitized srpm drops probably does affect those distros who would like to be a downstream of RHEL.
when CentOS started, there were no sanitized srpm either as far as i know. it was part of the CentOS project to sanitize them. the only difference then is that those unsanitized srpms were previously public, and now they no longer are. is that correct?
if that is the case, and any clone project can get access to these srpms by paying for a single license, i don't see what the big deal is. there is nothing red hat hasn't already been doing "worse" ever since RHEL started, with the only possible exception of making srpms no longer public.
again, assuming this is correct, is there really any downside to making those srpms public?
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?
as far as i can tell it is the promise of long term stability and security updates. and the compatibility.
small businesses who can't afford a RHEL license but need that kind of promise without the other support features that red hat offers. or they develop applications that need to be able to run on RHEL. there is a market for that, and the current CentOS stream or any distribution based on it can't make the same promise as a clone.
but time will tell, alternative distributions based on CentOS stream previously didn't exist. there is one now, if i read that right, and it should be able to take some of the market that RHEL clones are in. and maybe eventually also show that their releases have an almost equal level of longterm stability and updates, as well as sufficient RHEL compatibility.
the only drawback of a distribution based on stream is the security updates that don't come until they are in RHEL. but then how long should it take for an RHEL security update to make it into CentOS stream?
>> Where does the GPL only refer to users? Isn't anyone supposed to be able to get access? The AGPL does, for certain;
The AGPL was designed (partly) to overcome this specific limitation in GPL3.
The preamble and license [1] reads;
Preamble
"By contrast, the GNU General Public License is intended to guarantee your freedom to share and change all versions of a program--to make sure it remains free software for all its users.
...
"if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received. You must make sure that they, too, receive or can get the source code.
The license itself is best read by a lawyer, but you'll notice when talking about object code (section 6) the source is "bound" to the object code, and its recipients. There's no requirement to make the source generally available.
Aside- the Linux kernel uses GPL2 which has even fewer requirements than v3. But the concept of supplying code "to the user" is there as well.
So, in context, the recipient is the purchaser of a RH support contract, and they would argue that it should be ONLY the recipients who receive the source?
The primary problem I see here is, a purchaser is receiving source in return for the ability to distribute it, if they want to keep support. Quite a one-sided agreement that seems to dilute the spirit of libre software. You have the freedom still, sure, but choosing to use it ends the contract.
RH are complying with the terms of the license. They equally gave the right to fire customers if they choose. Given that the customer really has no major incentive to distribute the source, its not a terribly hard decision to make.
On the one hand this is a matter of law, and the law is being upheld.
On thd other hand it's a matter of "spirit" and "community" and other non-legal arguments. Which IMO is neither here nor there. There's always someone who wants you yo do things another way; you can't please everyone all the time.
What I don't get is the fuss. If you don't like the red hat policy then pick another distro. There are plenty to choose from.
What do you mean by "fuss"? Left to interpretation, anything not aligning with your view could be classified as fussing.
I don't use RH so it doesn't affect me personally, but they still hold sway in the ecosystem at present and their practices may inspire others to use orthogonal contracts to disincentivize the use of rights granted by the GPL.
We can choose non-RH today, but can you not picture a future where this is practiced by more than just them? When social practices change in influential places, it can have far-reaching consequences that don't appear related at first. If others didn't look to RH for guidance or examples of how to do business on Linux, I'd be much less concerned.
This happens a fair bit I the OSS space. Non-users have very strong opinions on how companies, that have OSS offerings, should behave. Because the software is OSS, customers, or more often not-even-customers, feel the urge to comment.
Clearly this case is not a legal issue. It's a business issue. And the business case being made by RH is that they choose not to do business with folk who distribute their source. That's novel, but not illegal.
Regarding "business on linux", to all intents and purposes it doesn't exist. Apart from RH, The percentage of users who have ever spent a dime on -any- Linux OS or Linux program is a rounding error from 0. Every second week there's a "show HN" on some new startup or scheme to somehow pay OSS developers.
The "business" of OSS, and business if Linux, is an unsolved problem. RH is at least innovating in the space, although very (very) few have been successful using their model.
Your concern for this innovation is noted, but, with respect, only affects users who are not customers. Which suggests you are less concerned with the business of Linux, and more concerned with getting stuff going free. (Which I get; we all like free things.)
If OSS -could- figure out a viable business model though, then that would allow many more OSS projects to exist, suck less, and make better progress. This would be a huge win for users to have the ability to control their own machines.
Thank you for the thorough reply. It took some time to have the opportunity to return the same respect.
Perhaps I'm not 100% in the group you're referring to, since I'm not really looking to get RH code or packages for free, or use any RPM distro. I'm interested in DIYing it with LFS, KISS, or something else suitable for a single maintainer. So, yes to non-customer, but no to wanting their code for free. However, I don't see any problem with criticizing a business decision while not being a customer. How do you shop for services if not by getting a feel for them from the outside? If I were looking for Linux support, I now know that a RH contract would be legally fragile (i.e. easy to breach and cost myself), and require me to surrender freedoms granted to me by the original software license, which is a net reduction in software freedom.
I think I see the point you're getting to with it being the sole choice of customers whether they want to breach contract to exercise the rights of a license; that choice doesn't affect non-customers per se, but it's a sinister loophole that leads people to trade their freedom to share for support. That has social ramifications, especially if done at scale. One business doing it is different from the majority, or even a trend of businesses doing it.
It would indeed be beneficial to find a fair, equitable, and sustainable business model that allows programmers to put food on the table with their technical work (former package maintainer and bug buster, myself), but how will this market differ from proprietary, if there are orthogonal contracts surrounding the works, providing different benefits with counter-incentives to exercising freedoms? Maybe the big contrast is the "exit" button comes with the source to fork oneself with. :P
I think the closest we've come to workable are sponsorships from companies who have an active stake in whatever software (or related stack) that their revenue depends on. It seems fair at first, but there's no enforcement model, nor does it seem feasible or desirable to form one. There's also the side effect of active development tending to focus on corporate concerns, due to the money coming from them. Some people have been successful on crowdsourcing sites like Patreon. Flattr had a neat model (your monthly budget would be split between every project you tipped/subbed that month), but I never looked into financial reports to see how effective it was at getting funds to projects.
If I look at this contract change through the lens of someone less savvy, then I see the value. That type of user isn't interested in even reading the source, so the support holds more value to them than the freedom to share.
So it goes, September is approaching.. :/
Thanks again for sharing your perspective, it's one of the first decent online conversations I've had in a while. Financially sustaining freedom-related software is a long-standing puzzle, and each solution seems lacking in one way or another.
