McGrath: Red Hat’s commitment to open source
McGrath: Red Hat’s commitment to open source
Posted Jun 27, 2023 1:40 UTC (Tue) by pabs (subscriber, #43278)In reply to: McGrath: Red Hat’s commitment to open source by sadoon
Parent article: McGrath: Red Hat’s commitment to open source
https://drewdevault.com/2021/01/20/FOSS-is-to-surrender-y...
RedHat itself started out as just a clone of other people's source, the RHEL clones too will do extra QA, report bugs upstream, send patches etc. This is inevitable because it is how the culture of open source works; share everything, contribute back. Also because not contributing back means more work in the long run rebasing patches etc.
Posted Jun 27, 2023 4:52 UTC (Tue)
by geofft (subscriber, #59789)
[Link] (24 responses)
The broader FOSS ecosystem doesn't really benefit from this. I don't think I've ever seen an upstream developer say "Oh you ran into this on Fedora, but can you reproduce it on Red Hat or a Red Hat rebuild?" It wouldn't be useful to the broader ecosystem if they said that, because how could you expect to use that software on Debian or Arch or anything? How could that software participate in the FOSS community as a whole instead of just Red Hat and its clones?
The broader FOSS ecosystem absolutely does benefit from Red Hat sending patches and bug reports upstream, and as a backstop for when Red Hat doesn't engage upstream, the broader ecosystem absolutely does benefit from Red Hat's patches and customizations being published to the world. Which are the things that Red Hat is committing to doing. If they find a bug in OpenLDAP and they patch it for their customers, that patch - and its commit message, and the discussion on the merge request, and a whole lot of other things that aren't in the SRPM! - is on GitLab.com for anyone else to pick up. The only thing they're no longer committing to is saying whether that patch was applied in openldap-2.6-20.el9.x86_64.rpm or openldap-2.6-21.el9.x86_64.rpm. That piece of information is wholly irrelevant to the culture of open source; you don't need it unless you're specifically trying not to have any patches of your own. It's only interesting if your interest in Red Hat publishing sources, and being open source at all, stops once you have an equivalent binary.
(Or, admittedly, unless you're Software Freedom Conservancy trying to verify that in fact they did push all the patches to GitLab that they claimed they were going to. That's a valid use case and I hope that gets resolved. I'm concerned by comments on the question I asked yesterday https://lwn.net/Articles/936138/ about how there are private branches, because that means it's easy to forget to push things publicly. Even a commitment to automation would be meaningful.)
All of Drew's examples there are about people adding value to your work in some way - incorporating it into their own work, becoming an expert and consulting/teaching/writing about the software, packaging it nicely, etc. Every single one of these use cases could be accomplished just as well with CentOS Stream as with Red Hat, if not better. If I wanted to, say, repackage 389-ds and run a little LDAP company, I would actively not want to be bound to Red Hat's release cycle and their discretion of what bugs are important! I would want to see their decisions about what patches go into stable releases and potentially make my own depending on what issues my customers are having. I wouldn't object if the base I'm working from is a little bit newer than Red Hat's commercial product; in fact I would find that useful.
The only use case where unthinking replication of Red Hat's decisions and renunciation of the ability to make your own decisions are valuable is when your product's value is entirely in it being the same as Red Hat's product but cheaper. It's true that Red Hat is also surrendering their ability to prevent this by redistributing FOSS, but it is telling that this isn't a use case where you can write a convincing story about how it's a good thing for the world.
(And, in turn, the money that Red Hat charges goes to fund their ability to continue participating in the ecosystem. If you look at e.g. the development stats article right below this one https://lwn.net/Articles/929582/ , a lot of the major contributors are hardware vendors who want to sell you their hardware, or companies like Google or Facebook that have their own internal use cases and their own agendas. The argument being made in the article is that a world where Red Hat's business model is not commercially viable is actually worse for FOSS than a world where Red Hat survives by doing things that just barely comply with the GPL.)
Posted Jun 27, 2023 7:28 UTC (Tue)
by taladar (subscriber, #68407)
[Link] (18 responses)
It is bad enough, frankly, that 10 year support distros like RHEL often force us to make software work with current and 10+ year old software at the same time at all.
Posted Jun 27, 2023 9:51 UTC (Tue)
by tuna (guest, #44480)
[Link]
You are not forced to write software for certain platforms. You might have a marketing incentive to write software for certain platforms, but no one is forcing you to write software.
Posted Jun 27, 2023 12:37 UTC (Tue)
by pizza (subscriber, #46)
[Link] (13 responses)
No; developer use of the clones is a very tiny minority of their user base.
I'd put money down that over 95% of the deployments of the clones are from folks that want a "LTS" linux distribution they don't have to pay for, deploying anywhere from snowflake production systems to hundreds of servers (and/or workstations running Very Expen$ive Software) to tens of thousands (or more) of cattle compute nodes.
(and for the record, I've done or worked at companies that do all of these. The latter even had a handful of RHEL licenses they used for "official" support if their compute clusters ran into problems and it was reproducible on genuine RHEL).
Posted Jun 27, 2023 18:52 UTC (Tue)
by wtarreau (subscriber, #51152)
[Link] (12 responses)
I really think Red Hat should propose a free version themselves that can be upgraded to a supported one without having to reinstall anything. Just download the ISO for free like you do with Ubuntu, and if one day you decide that your server has become sensitive enough to warrant paying, just do it. At least there would be *their* distro in field for all users, free and paid. The problem they're facing now is that for absurd reasons of pricing (or even the perceived difficulty of reselling when you only expected to deliver service to a customer), they end up forcing their potential future customers to deploy a competing solution instead of theirs. And *this* is hard to upgrade later, as the customer certainly doesn't want to touch their running system when it becomes critical.
They'd basically just need an motd reminding the registration link so that those logging in via SSH to inspect something are greeted with "Experiencing some trouble? Need some help? May be it's time to subscribe. ->link". It would completely fix the consultant problem above: nothing is sold, it's only installed and the customer may decide later to pay.
Posted Jun 28, 2023 14:28 UTC (Wed)
by ewan (guest, #5533)
[Link] (10 responses)
That's *exactly* what Red Hat Linux was.
Posted Jun 28, 2023 15:25 UTC (Wed)
by zdzichu (subscriber, #17118)
[Link] (9 responses)
Posted Jul 4, 2023 6:19 UTC (Tue)
by ceplm (subscriber, #41334)
[Link] (8 responses)
Posted Jul 4, 2023 8:20 UTC (Tue)
by anselm (subscriber, #2796)
[Link] (7 responses)
According to Red Hat, “the no-cost Red Hat Developer Subscription for Individuals may be used for demos, prototyping, QA, small production uses, and cloud access” (emphasis mine).
Posted Jul 5, 2023 7:47 UTC (Wed)
by ceplm (subscriber, #41334)
[Link] (6 responses)
Posted Jul 5, 2023 7:49 UTC (Wed)
by anselm (subscriber, #2796)
[Link]
No, I wouldn't. I prefer Debian.
Posted Jul 6, 2023 17:20 UTC (Thu)
by cortana (subscriber, #24596)
[Link] (4 responses)
> “Individual Production Use” means any use other than for Individual Development Use including, but not limited to, using the Software (a) in a production environment, (b) with live data and/or applications and/or (c) for backup instances.
Posted Jul 13, 2023 16:24 UTC (Thu)
by ceplm (subscriber, #41334)
[Link] (2 responses)
> “Individual Production Use” means any use other than for Individual Development Use including, but not limited to, using the Software (a) in a production environment, (b) with live data and/or applications and/or (c) for backup instances.
So, Red Hat can sue you any time if you just use packages of their repositories (without any of your own development) in the production environment? Meaning, this is so confusing and ambiguous, that I would immediately run to openSUSE or Debian.
Posted Jul 13, 2023 16:44 UTC (Thu)
by pizza (subscriber, #46)
[Link]
...Debian and OpenSUSE are not equivalent to, or substitutes for, RHEL (or even CentOS Stream), especially where the support window is concerned.
(Unless of course you never actually needed RHEL to begin with, and/or were just using one of its rebuilds because you didn't have to pay anything for it)
Seriously, please, there are a lot of options, but don't delude yourself into thinking that the grass is necessarily greener everywhere else -- Each of those options represents a different culture, warts, and compromises.
Posted Jul 13, 2023 19:27 UTC (Thu)
by kleptog (subscriber, #1183)
[Link]
And suing? Really? Yes, in theory RedHat can sue anybody, but as an individual the law really limits what they can do to cancelling your subscription. They're not going to sue you unless you happen to be a million dollar business pretending to be an individual developer, because then consumer rights won't protect you.
It feels like some people here want to find a reason to hate RedHat. I don't use RedHat, never have, but I don't think they're evil or anything.
Posted Jul 25, 2023 14:21 UTC (Tue)
by MattJD (subscriber, #91390)
[Link]
> The Individual Developer Subscriptions allow you (as an individual, natural person) to use certain Red Hat Subscription Services in connection with Red Hat Software for Individual Development Use and for Individual Production Use subject to these Program Terms at no cost.
I don't know why they are making a distinction, but they explicitly allow both uses.
Posted Jul 3, 2023 16:46 UTC (Mon)
by jccleaver (guest, #127418)
[Link]
Seen this plenty of times as well. The primary issue is that RHEL is pricing as if they're selling a fully proprietary solution instead of selling support services. For some companies' business models, an OS license is a trivial addition. In many revenue cases it can even be passed directly on to the client/customer as a distinct line item! For farm and compute node customers, many of whom have plenty of Linux Systems Engineers on staff, this is not a justifiable cost.
RHEL should have provided reasonable site licenses, or sold individual support instances, or allowed CentOS users to receive support if they donated to the CentOS Foundation to help with finances for centos infrastructure... *something* . This is especially the case when they adopted CentOS as an *internal* project solution, thereby killing off the other group -- Scientific Linux -- and thus reliability diversity in the EL ecosystem. This almost counts as an "embrace, extend, extinguish" for rebuilds, and probably would if CentOS were having problems with project and donation management at the time.
This wasn't fair play by Red Hat, even if it complies with the letter of the various OSS licenses. It's a turnabout that it's still difficult to see the justification for, given that the relationship between RHEL and things like WBEL goes back almost 20 years, and CentOS has been part of RH officially for quite a while. Rocky didn't steal revenue from RHEL because NASA wasn't going to pay for support it didn't need. At that point, Rocky is offering consultant services, since they're not doing anything about upstream bugs other than... report them to upstream. That's the entire point of a rebuild.
EL-rebuilds value is in removing community support costs from RHELs bottom line, while upstreaming the collective experience and bug reports as necessary. THAT is the value, and RH needs to look beyond per-CPU OS licensing, or free as in beer replacement.
Posted Jun 27, 2023 12:43 UTC (Tue)
by anselm (subscriber, #2796)
[Link]
Red Hat is already going out of its way by providing free RHEL developer licenses to support this.
These people get actual RHEL for free already. How much farther do they want Red Hat to bend over backwards on their behalf? Would they like an engineer from Red Hat to come to their site, for free, to install RHEL for them? Perhaps write their code for them while they're drinking beer by the pool? This is entitlement, pure and simple.
Anyway, why would you even futz around with some RHEL clone in the first place? The main reason to deal with RHEL at all is that you have paying customers who run RHEL, and who would prefer you to test your software on genuine RHEL and not just some clone, even if the clone purports to be just the same as RHEL – but who is prepared to guarantee that? The clone maker? You?
Posted Jun 27, 2023 20:55 UTC (Tue)
by amacater (subscriber, #790)
[Link] (1 responses)
Full disclosure: I currently have a free RHEL developer subscription. I use it to try small things for people, set up machines and VMs to gain expertise for myself. I *can't* force anyone to pay for Red Hat so I sometimes prototype on RHEL and use Rocky. I've a distro mirror next door - I built it on RHEL because I need to show it to RHEL-native sysadmins. Because I can't force the RHEL natives to take out another RHEL subscription, I took the scripts and remade it on Rocky.
Self support on the free tier makes it *really hard* to file a bug for RHEL. Two show stopper bugs took forever to be raised. I could demonstrate that they only occurred with RHEL signing certificates / Red Hat subscription manager. The response made me less enamoured of RHEL. I'd quite like to raise a bug that RHEL 9 doesn't run on my HP Microserver but no-one will listen so the Microserver now runs on Rocky 8.
But RHEL developers |= RHEL system architects and customer supporters |= RHEL senior management. Former RHEL |= current RHEL and current RHEL == IBM.
If the problem really is Oracle Linux (and not Rocky/Alma) can we just get some popcorn
Posted Jul 6, 2023 17:24 UTC (Thu)
by cortana (subscriber, #24596)
[Link]
Hm. I've filed a few bugs in Bugzilla and some have been fixed, others I've corresponded with developers and are not, I think, in a state where they'll rot forever.
subscription-manager is always a pain to deal with though even when it's working. And it's so s...l...o...w...!
Posted Jul 2, 2023 11:06 UTC (Sun)
by sadoon (subscriber, #155365)
[Link] (4 responses)
The Venn diagram of FOSS enthusiasts and anti-corporate hipsters is a little less than a circle. It's unfortunate but I understand why it is and I agree with their view most of the time. Most big corporations are evil by default, but that's more of an incentive to support a corporation that's doing genuinely good things for the community as a whole, even if you don't agree with some of their decisions; they've enabled your freedom, and (good) software is hard work that doesn't come from unicorn farts (hobbyist work).
If no one supports RH with money, they'll find another way to make profit and I'll bet that it won't be something to help FOSS.
Posted Jul 2, 2023 15:41 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (3 responses)
Most big corps are evil BY LAW. In order to comply with the law, companies find it difficult to be compassionate, and are forced into psychopathic behaviour.
Don't blame the company, blame the environment they live in. (Think eg the US DoD spending $100/hammer, so they can prove they aren't being ripped off ...)
Posted Jul 2, 2023 16:04 UTC (Sun)
by pizza (subscriber, #46)
[Link] (2 responses)
Not quite. Corporations (of all types) must act *in their shareholders' interest* Typically, this means means maximizing (short term!) financial returns. which inevitably seems to lead to sociopathic evil-ness. However, if the shareholders make it clear they prioritize other things, that's perfectly fine in the eyes of the law!
Generally speaking, corporations that don't keep their shareholders happy tend to find their senior management removed and replaced with ones that promise to do whatever the shareholders want -- which, unfortunately, tends to be "maximum short term financial return. No-so-coincidentally, that's also easy to measure, so of course it becomes an (the?) important metric.
Posted Jul 3, 2023 12:21 UTC (Mon)
by kleptog (subscriber, #1183)
[Link] (1 responses)
Even that's not strictly true. They must first abide by the goals set out in the Articles of Association that created the business. If the shareholders don't like that, they can be changed, but that may be a much higher bar than a simple majority.
That's how you get social businesses, whose goal at incorporation may be e.g. "ensure affordable housing for people in area X" or even "provide safe drinking water for the people in area X". Handing out large dividends would run counter to that goal. Mostly these kinds of organisation are associations or cooperatives, but sometimes an LLC is chosen.
(Articles of Association are supposed to be on the public record, but can be surprisingly difficult to locate if you don't know where to look.)
Posted Jul 3, 2023 14:04 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
I wish that described the situation here in the UK ... they went from mismanaged nationalised industries to - reasonably decent - privately owned companies, to subsidiaries of profit-mad international conglomerates.
They also have the big problem that - like an awful lot of public infrastructure - the government loves dumping responsibilities on them, then taking away their ability to pay for those responsibilities. Then the government gets all upset when everything goes pear-shaped.
Cheers,
Posted Jun 28, 2023 8:50 UTC (Wed)
by jzb (editor, #7867)
[Link]
Did it? And for how long?
As I understand it, the first Red Hat Linux release was based on SLS. Not a clone, a fork with additional work added. And, I think, SLS had actually ceased distribution by then. It’s a far cry from a fair comparison.
If the discussion was about Red Hat trying to prevent a project or company from building something novel off RHEL sources instead of just xeroxing whole RHEL releases, it’d be very different.
McGrath: Red Hat’s commitment to open source
McGrath: Red Hat’s commitment to open source
McGrath: Red Hat’s commitment to open source
McGrath: Red Hat’s commitment to open source
McGrath: Red Hat’s commitment to open source
McGrath: Red Hat’s commitment to open source
McGrath: Red Hat’s commitment to open source
McGrath: Red Hat’s commitment to open source
McGrath: Red Hat’s commitment to open source
Officially it is the development version only for development.
McGrath: Red Hat’s commitment to open source
McGrath: Red Hat’s commitment to open source
McGrath: Red Hat’s commitment to open source
McGrath: Red Hat’s commitment to open source
McGrath: Red Hat’s commitment to open source
McGrath: Red Hat’s commitment to open source
McGrath: Red Hat’s commitment to open source
McGrath: Red Hat’s commitment to open source
McGrath: Red Hat’s commitment to open source
RHEL clones are mainly useful to build and test software meant for RHEL. As such they make supporting RHEL easier for people who do not have a big investment in RHEL, adding value to the RedHat ecosystem.
And no, many people do not want to deal with some sort of license, even a free one, to support that use case.
McGrath: Red Hat’s commitment to open source
Red Hat (was) a large company with differences of opinion - hating one RHEL person for what they may or may not say in a press release is perhaps not useful.
and watch as IBM take on Oracle? Both have licence compliance mavens but IBM has over a century's worth of attack dog lawyers and a significantly longer corporate memory.
McGrath: Red Hat’s commitment to open source
McGrath: Red Hat’s commitment to open source
McGrath: Red Hat’s commitment to open source
Cheers,
Wol
McGrath: Red Hat’s commitment to open source
McGrath: Red Hat’s commitment to open source
McGrath: Red Hat’s commitment to open source
Wol
McGrath: Red Hat’s commitment to open source