Live data from Hacker News

Red Hat cutting back RHEL source availability

lwn.net

171–180 of 339 posts

Re: Red Hat cutting back RHEL source availability

#171

The comments there are insightful and actually make me think this is the right move: > Since the earliest days of Linux or MySQL, there were companies set up to profit from others’ contributions. Most recently in Linux, for example, Rocky Linux and Alma Linux both promise “bug for bug compatibility” with Red Hat Enterprise Linux (RHEL), while contributing nothing toward Red Hat’s success. Indeed, the natural conclusi…

I don't really agree. RHEL is nothing special. Important for Enterprise and thus free availability is handy for people having an interest in becoming a sysadmin to learn it. Dogfooding work stuff is the only reason I'd consider using it or its derivatives at home. But I don't care even about that and my stuff all runs BSD :P But other distros are much better IMO. There's good reasons that a totally free distro like D…

There is no single criterion by which you can decide which distro is better.

All I know is anecdotes. RHEL 7 and Ubuntu 14.04 came out around the same time. Around May, upstream QEMU started getting bug reports from Canonical developers that you couldn't reset a virtual machine that had been created in 12.04 and migrated to 14.04 due to some firmware incompatibility.

In RHEL we had started testing cross-version migration 6 months in advance.

Re: Red Hat cutting back RHEL source availability

#172
I am so pissed by this move, it is totally against the spirit of free software and GPL. Using additional contracts to subvert the free software licenses. You get to see the software, but you can't share it further. RedHat would not be here if someone behaved like this 25+ years ago.

I would prefer a variant of GPL which strictly forbids this (imo it should already be forbidden, these are clearly additional restrictions). Let's put "GPL v2 or later" to good use...

Re: Red Hat cutting back RHEL source availability

#173
post #16
post #6

If Red Hat chooses not to perform their duties under the GPL, then any holder of copyright can require Red Hat to remove the owner's source packages from the commercial distribution. Red Hat could minimally perform this duty by providing the source only to those who download the binary releases. As there are several avenues for free downloads (developer, 16 free licenses for small business, etc.), the source will be…

>Red Hat could minimally perform this duty by providing the source only to those who download the binary releases. As there are several avenues for free downloads (developer, 16 free licenses for small business, etc.), the source will be available by that route. If you read the original announcement, this is exactly the case "For Red Hat customers and partners, source code will remain available via the Red Hat Custom…

Rocky and Alma will just use CentOS Stream distgit sources on GitLab, just like Facebook does for their internal rebuild.

Re: Red Hat cutting back RHEL source availability

#174
post #124

Earlier quoted context omitted.

"Large" wasn't a very big standard at the time. Linux's multiprocessor support was ...lackluster at best... prior to IBM contributing all the Sequent (Dynix) derived multiprocessing stuff. Hyperthreading/Multicore started to get "normal" even in consumer systems only a couple years later, so that injection was pretty critical. Likewise, a lot of Linux's development inertia and cultural acceptance came from being a ch…

>Linux's multiprocessor support was ...lackluster at best... prior to IBM contributing all the Sequent (Dynix) derived multiprocessing stuff. Hyperthreading/Multicore started to get "normal" even in consumer systems only a couple years later, so that injection was pretty critical. It was certainly needed over time but capabilities from things like RCU out of Sequent weren't that important in the 2000 timeframe. And a…

And who can forget "peace, love, Linux" ;)

https://www.zdnet.com/article/ibm-gets-100000-fine-for-peace...

Re: Red Hat cutting back RHEL source availability

#175

The comments there are insightful and actually make me think this is the right move: > Since the earliest days of Linux or MySQL, there were companies set up to profit from others’ contributions. Most recently in Linux, for example, Rocky Linux and Alma Linux both promise “bug for bug compatibility” with Red Hat Enterprise Linux (RHEL), while contributing nothing toward Red Hat’s success. Indeed, the natural conclusi…

This is only true it RHEL was self contained OS Project with no Upstream sources itself... That is not the case, RHEL is not possible with out the wider ecosystem, and to say Rocky Linux is a "dirtbag" for repacking RHEL, would be like saying RedHat is a "dirtbag" for packaging any number of free software projects they consume into their product. It completely antithetical the free software movement for which Linux i…

I don't dislike your sentiment and don't see Rocky Linux as dirtbags, but I think it is important for GPL that you have to[1] provide source only if you provide binaries (IANAL, lawyers correct me). So you should be able to have a business where you sell software and the people who buy receive the GPL'd source code (that they can then modify and share). You don't have to develop in public, or use version control programs: participate in the whole "GitHub culture".

GPL tries to guarantee an environment for user freedom (not developer convenience, like permissive licenses). It has builtin protection against someone closing the source. It doesn't protect against some company pulling an Internet Explorer on you (i.e. providing a free equivalent) with your own code, because this doesn't directly concern user freedoms. You don't have to be actively helping them though.

I think ultimately free-of-charge mirrors should exist, but I see good potentials in companies discovering business merits of GPL, and hopefully AGPL. We need more vigor for those, after getting lucky once with Linux. We cannot rely on good will of corporations (only enforced law works on them), so any sign of luring them into copyleft somehow is a good thing. This would be a long road, but who knows what could happen in the current "AI" chaos and regulation scares.

[1] Of course only have to assuming that you are not the original author and you're building on someone else's code received under GPL.

Re: Red Hat cutting back RHEL source availability

#176
post #23

I don't get what's the big deal--essentially the only thing being lost is a pointer to commit that marks the difference between RHEL X.Y and X.Y+1..?

RHEL X.Y isn't a simple snapshot of CentOS Stream X at a specific point. It is a fork of CentOS Stream, with cherry-picks and so on. The specific details of what patches made it into RHEL and when and how to create reproducible builds are now only being provided to customers. In the past, customers have been able to redistribute the RHEL repos freely. I assume that will remain the case as long as CentOS Stream is ope…

> Actually, it wouldn't surprise me if IBM put some content in the RHEL repo that is under restrictive licenses that couldn't be redistributed just to complicate things, but all the important parts will remain open source, due to close ties to CentOS Stream and Fedora.

I'm not so sure. They're obligated to release the GPL'd code, which of course covers Linux itself, but they're under no such obligation for the non-GPL'd software they include.

They could license their RHEL-specific backport patches for non-GPL'd software such that they could not be redistributed, and if that code gets merged into CentOS Stream it could just be dual licensed from that port forward (so Stream could stay open but RHEL would be locked down).

Re: Red Hat cutting back RHEL source availability

#177

Earlier quoted context omitted.

I know there move to CentOS Stream cost them my business, Since that announcement 2 years ago I have replaced all Licensed RHEL servers with Ubuntu Servers...

Which is an odd choice when comparing RH and Canonical. The former has been almost religious about living to the open source ideals, going so far as open sourcing products they purchase, and making sure new products they create have opensource upstreams. I don't think the same can be said of Canonical which seems at every turn to in need of $ so they try desperate ploys to monetize new projects they work on by develo…

> The former has been almost religious about living to the open source ideals, going so far as open sourcing products they purchase, and making sure new products they create have opensource upstreams.

We are having this conversation on an article about them doing their best to avoid sharing their source code in order to kill their downstreams.

Re: Red Hat cutting back RHEL source availability

#178
post #12

Earlier quoted context omitted.

IBM is stuck in a cycle of constant re-invention, because they somehow manage to always re-invent themselves in ways that are even worse and more complicated for customers, which they try to fix by re-inventing themselves again. Even if they initially planned on leaving Red Hat alone, every re-invention is a chance for some executive to make the decision to squeeze a little tighter on existing customers. So the quest…

Yet they're still way older than most tech companies. I'd wager they will outlive 99.99% of those unicorn startups yet.

Immortality is a curse, not a blessing.

Re: Red Hat cutting back RHEL source availability

#179
post #3

I don’t understand what game IBM is playing with Red Hat. I was under the impression they were profitable prior to the acquisition so I’m not sure why they’re squeezing so hard and ruining the great brand and good will Red Hat had built up.

> I don’t understand what game IBM is playing with Red Hat. And this is yet another part of the reason why I don't understand the big push for RedHat specific tooling. Podman comes up a lot. But, just like with everything RHEL it seems as though RedHat / IBM wants to be the Apple of Linux. I'm not a fan of that. I also don't believe IBM is a good steward of OSS based on how I've seen them try to sell it in the enterp…

> I don't understand the big push for RedHat specific tooling

I'd wager it is driven by RH simply being "least worst" of the options which can be relied on to stick around long enough for enterprise users.

Canonical are doing their best to screw the pooch with snap and similar nonsense, leaving the only other option being cobbling together a collection of tools from fly-by-night small projects - which might go full unicorn-wannabe and adopt an open-core SaaS model any second.

Re: Red Hat cutting back RHEL source availability

#180
post #21

Earlier quoted context omitted.

I'd argue that IBM's contributions in that timeframe were more about about validating it from a large business perspective than about technical contributions (that tended to focus on large system performance which wasn't actually that important for Linux taking off).

Yes, certifying DB2 for Linux (back in 1998, https://slashdot.org/index2.pl?fhfilter=db2+linux , scroll to bottom) was an absolutely earth-shattering event that announced that Linux had arrived. I think that event (and of course Oracle and Sybase a few months prior) really sounded the death knell for big-iron UNIX. But in 1999, IBM ported Linux to run on System 390 ( https://slashdot.org/index2.pl?fhfilter=mainframe+…

>Linux didn't have efficient+mature SMP even into the early aughts, although a few companies had built some massive SMP boxes

Including IBM. (Forget when they did their big stackable X-series server.) A lot of the tech eventually became applicable to even super-mainstream dual-socket servers but I wonder how much money was largely wasted on building and trying to sell larger scale-up boxes.

But, yeah, IBM was one of the big investors in OSDL (and their own Linux Technology Center) which had a lot of scale-up focus which made a lot of the legal claims of another 3-letter company pretty much misaligned with the timeline.

Post reply on HN