Regarding the Red Hat kerfuffle, and the Destination Linux coverage: a lot of stuff was said that I disagree with, but is debatable (like the “parasites” language, that I really didn’t like, or how similar this “closing” is to other Linux vendors’ business models), but here’s the two main issues that you glossed over (“oh, it’s not a big deal”) or completely ignored:

1. The GPL requires that if you distribute GPL code, you “must license it on the same terms to all 3rd parties”, which means if pay Red Hat and get access to the GPL source code of software disturbed in RHEL, the license allows me to compile it, bundle it and redistribute it without any limitation except the GPL - but the Red Hat customer licence agreement says the opposite: the agreement I must agree to, to get access to the GPL source, says that I must not distribute the software I get from RHEL, and puts all sorts of limitations that contradict the actual software copyright license - that Red Hat agreed to when they started distributing it in RHEL. Most of software in RHEL isn’t made by Red Hat and Red Hat are now breaching the terms under which RHEL was created.

2. There’s a lot of value - for Red Hat - in various people in the world being able to test, deploy, and support applications on RHEL compatible systems: all kind of third party software developers make software that is available and supported on RHEL installations. These developers used to be able to test their products easily to be RHEL compatible, and in return their customers would buy RHEL licences for using the products on. Now it is much harder, as CentOS stream isn’t compatible with RHEL and the tinkering that Ryan suggested developers can do can never result in 100% assured compatibility. The 16 seats dev licence is a joke - you have to install licenses, you can’t really use automated provisioning (you need an uber expensive “cloud license” for that) and if you need more than 16 seats (as common in many kubernetes setups) - then you can’t even use that. Here’s one such developer explaining why he is giving up on offering RHEL support to his customers: Huge Open Source Drama - YouTube

Is Red Hat no longer “open source”? No - there’s still a lot of good open source work done in Red Hat, but RHEL is no longer open source: it does not allow it’s users to copy, modify and distribute the source.

I feel most of the coverage in the episode was a long the lines of “Red Hat had been so good to us, let’s just trust whatever they say and never criticise them”, which is disappointing because I really expected better from the Destination Linux crew.

Sometimes decisions in FOSS communities are difficult to understand, but I have appreciated a variety of voices who are shedding light on the ramifications of Red Hat’s decision

I found DL’s hosts @MichaelTunnell , @dasgeek and @jill_linuxgirl made a good point that Red Hat does not have an obligation to run public servers that make available RHEL source code. Red Hat does have the obligation, which they are doing, to run servers that make RHEL source code available to RHEL customers.

I would love to hear license lawyers discuss point #1 made by @guss77. How the GPL and RHEL license interact is beyond my current understanding.

Thank you, @guss77, for making point #2. This is a point that I have heard those who work in the enterprise space or develop applications for enterprise companies make. Having a “binary compatible” distribution available to develop, test, and certify compatibility with helps the Red Hat ecosystem as a whole. This enables developers to develop enterprise applications that enterprises can then run on RHEL servers knowing that they have support for their whole stack which would be a win for enterprise customers, application developers, and Red Hat making money from RHEL licensed servers in enterprise companies.

I thought I heard one of the DL hosts make the comment that Red Hat is simply doing what other open source companies are doing like Canonical with Ubuntu Pro, and Suse. But I am not sure this is true. When Canonical releases an LTS version of Ubuntu for at least 5 years a developer would be able to download a free version of Ubuntu LTS and this would be “binary compatible” with enterprises that are running the same Ubuntu LTS version. Ubuntu Pro adds an additional 5 years of support for certain packages ensuring that CVE patches are maintained. I don’t know if Canonical releases those CVE patches freely, so after 5 years you may loose the ability to have a “binary compatible” distribution to develop against for free. I tried to find documentation about Opensuse Leap which Suse says is derived from Suse Enterprise Linux. So I’m unsure if Opensuse Leap is “binary compatible” with Suse Enterprise Linux always, for a time period, or not at all.

One final point that I have heard made is that Red Hat has forgotten the benefit in open source of building on the shoulders of others. Red Hat makes a lot of money by taking packages with hours of work and labor like Apache, the Linux kernel, and the whole GNU stack adding their own special sauce to turn it into a enterprise grade distribution of Linux, but now they are not allowing others to stand upon their shoulders and build on their work. Perhaps a counter point to that one is that Red Hat does allow the open source community to build upon their work and their support of distributions like Centos Stream and Fedora. But if we would shift and look at the Ubuntu ecosystem. Canonical takes the work and labor of the Apache, the Linux Kernal, the GNU stack, and the Debian stack and releases an Ubuntu LTS often used by enterprises, and projects like Linux Mint, Pop!_OS, and Elementary stand on the shoulders of Canonical’s work.

In reality, Red Hat’s decision will not impact my use of FOSS. I’m still thankful to Red Hat for their support of Fedora, one of my favorite distributions, and one that I give my time to help out and improve. I’m thankful to the Red Hat employees who have done so much to further the Fedora distribution.

Perhaps the DL crew could consider that yes, their point that Red Hat “can” do this is true, but there might be more nuanced reasons whether Red Hat “should” do this and how it might impact their wonderful ecosystem that surrounds a great product built on and with FOSS. Also, @guss77 had a point worth considering that the “binary compatible” distributions don’t deserve the label “parasites” but were perhaps fulfilling a legitimate ecosystem need for application developers who want to build apps that will run on RHEL licensed systems upon release with as few bugs as possible.

Thanks DL hosts for bringing your thoughts to the table.