Live data from Hacker News

Red Hat cutting back RHEL source availability

lwn.net

211–220 of 339 posts

Re: Red Hat cutting back RHEL source availability

#211

Earlier quoted context omitted.

I think you mean anti-copyleft. Free Software and Open Source are essentially the same, despite the philosophical differences. The issue here is against the copyleft (GPL and AGPL).

>>Free Software and Open Source are essentially the same, No ... no they are not >>despite the philosophical differences. And those differences are HUGE and make them incompatible

> no they are not

Yes they are, according to people who use both terms. All “free software” licenses are also “open source” licenses and vice versa.

Re: Red Hat cutting back RHEL source availability

#212
post #163

Earlier quoted context omitted.

There's a huge difference between Rocky/Alma, and Oracle. Oracle actually tries to steal RHEL business. They offer support, which I think is ludicrous when they don't even build the product. Alma/Rocky aren't to my knowledge offering any support (and if they plan to, they shouldn't). Are customers cross-shopping RHEL with Alma? You either want support, and buy RHEL, or you don't, and you use something else (Alma/Rock…

Rocky does offer support, but your comment about Oracle still stands. I believe Rocky works with Red Hat.

Rocky can offer support on helping you install it. But they can't offer real support. They can't fix bugs or do any real work on RHEL beyond requesting that Red Hat accept a fix. If Red Hat declines, Rocky can't even ship their own fix.

Re: Red Hat cutting back RHEL source availability

#213

Earlier quoted context omitted.

Well, go and check: https://www.gnu.org/licenses/license-list.html Then see how many of those are OSI approved licences (thus open source).

Free implies open source. Open source does not imply free.

Name an open source license that you don’t consider free software, then. Note that “source available” (Business Software License, etc.) is not the same thing as “open source”.

Re: Red Hat cutting back RHEL source availability

#214

Earlier quoted context omitted.

Yeah... had it not been for CentOS, I would've never touched anything in the RHEL-side of things after I discovered Ubuntu in the 10/12 era. Because CentOS existed, I made sure most of my open source work would run just as well on all RHEL derivatives as it does on Debian. If Rocky didn't exist, I would quickly drop all my RHEL support because operating thousands of test machines and containers based on UBI and havin…

I'd have to check if it is still the case but RHEL has provided free developer licenses for RHEL for years (decades?). EDIT: checked and it still exist and allow usage of up to 16 physical or virtual nodes for development " to develop software (including open source software), perform prototyping or quality assurance testing and/or for demonstration purposes.

And those conditions are exactly what the OP meant by a licensing game.

Re: Red Hat cutting back RHEL source availability

#215
post #83

Earlier quoted context omitted.

> 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 open source. There's a duality here. Yes, by the nature of the distribution, GPL, and licensing general, Red Hat cannot stop or prevent a customer from distributing RHEL packages and software to third parties. However, Red Hat reserves the right to terminate any existing subscr…

> Red Hat cannot stop or prevent a customer from distributing RHEL packages and software to third parties. However, Red Hat reserves the right to terminate any existing subscriptions a customer may have as a result of their package distributing. IANAL, but not so sure about that. From GPLv3: > You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example…

I don't think it is a further restriction on the rights you have. Those rights extend to the code you have, they are only terminating the business relationship going forward.

Not a lawyer, so maybe someone else more knowledgeable about the space will expand on this.

I imagine that RH/IBM has had lawyers look into this before the policy was announced.

Re: Red Hat cutting back RHEL source availability

#216

Earlier quoted context omitted.

> I wish this encourages companies to look for more alternatives to RHEL and its clones. The issue is that there is no alternative. I'm not aware of any distro with its base and all its packages working seamlessly with SELinux enabled. Setting up SELinux in any other distro is, in my experience, an uphill battle. You need to become an SELinux expert to do so. > The worst part about the packaging work is, the tools us…

I have run SELinux on Fedora without too many issues. Of course, Fedora being rather closely related to RHEL that shouldn't be too surprising.

Fedora is to RHEL what Debian Sid is to Debian stable.

Yes, it's not that simple, and there are some customization done. But Fedora is the playground for the next RHEL. I woudn't consider Fedora "an alternative" according to what the top-poster was describing.

Re: Red Hat cutting back RHEL source availability

#217

The problem is that RHEL is too expensive for people who don't need support. IBM is getting greedy and screwing up its pipeline. Our dedicated servers are about $100/month for pretty serious hardware (2 x 8-core CPUs, 64 GB RAM, 2 x 8TB HDD, 30TB transfer). Paying $349/year is a significant percentage of that. It is worse for smaller servers, and ludicrous for small virtual machines in the cloud. I would not mind thr…

Red Hat's model is to only ship what they know they can support. For the rest there's EPEL which is community managed. Canonical's model is to ship the kitchen sink and wing it in case a customer wants support on something that is in a sorry state. Different customers, different requirements.

Thats not true with Ubuntu Pro, which includes support for way more packages than RHEL, 10 thousand to be exact, and is much cheaper with more features like included kernel Livepatching.

Re: Red Hat cutting back RHEL source availability

#218

I wish this encourages companies to look for more alternatives to RHEL and its clones. There are certainly cases where the stability of RHEL makes sense. But too often teams use them when they need latest versions of software, resulting in pointless packaging work. The worst part about the packaging work is, the tools used to create RPM packages is showing its age. RPM macros, the language for describing packages, is…

> I wish this encourages companies to look for more alternatives to RHEL and its clones. The issue is that there is no alternative. I'm not aware of any distro with its base and all its packages working seamlessly with SELinux enabled. Setting up SELinux in any other distro is, in my experience, an uphill battle. You need to become an SELinux expert to do so. > The worst part about the packaging work is, the tools us…

>The issue is that there is no alternative. I'm not aware of any distro with its base and all its packages working seamlessly with SELinux enabled.

Why is this a dealbreaker ? Ubuntu has apparmor which is similar. Maybe selinux is stricter/granular etc., but that's not a business level differentiator. Your company won't fail or succeed because of selinux.

Re: Red Hat cutting back RHEL source availability

#219

I wish this encourages companies to look for more alternatives to RHEL and its clones. There are certainly cases where the stability of RHEL makes sense. But too often teams use them when they need latest versions of software, resulting in pointless packaging work. The worst part about the packaging work is, the tools used to create RPM packages is showing its age. RPM macros, the language for describing packages, is…

The “correct” way to build reproducible RPMS is to use the ‘mock’ system, which addresses the concerns about inconsistent build environments.

Re: Red Hat cutting back RHEL source availability

#220

Earlier quoted context omitted.

Red Hat's model is to only ship what they know they can support. For the rest there's EPEL which is community managed. Canonical's model is to ship the kitchen sink and wing it in case a customer wants support on something that is in a sorry state. Different customers, different requirements.

Thats not true with Ubuntu Pro, which includes support for way more packages than RHEL, 10 thousand to be exact, and is much cheaper with more features like included kernel Livepatching.

I was referring exactly to Ubuntu Pro. They can support more packages for cheaper exactly because Red Hat won't ever have the same YOLO approach to support that Canonical has.
Post reply on HN