It’s been an exciting week for people who care about Linux distributions, FOSS licensing, FOSS distribution, FOSS business models, and the future of open source in general. Red Hat’s announcement that CentOS Stream will be the sole repo for public RHEL-related source code releases has generated a lot of chatter and exposed a lot of misconceptions about what the GPL requires and doesn’t.

Sadly for you, dear reader, I have a lot of thoughts on this topic and plan to tackle them in stages here on the blog. Going to start with some really common misconceptions / questions and answers as I understand them. Note that I am not a lawyer, and I no longer work at Red Hat. If you see something inaccurate, please feel free to comment and I’ll make any warranted corrections.

Doesn’t Red Hat have to release RHEL source code publicly?

No. The GPL requires distributors to provide source code to those entities it has provided the GPL’ed software to, but no one else is entitled to those changes, not even the original authors.

It also says that the recipient receives all the rights under the GPL that the distributor has, and the distributor can’t impose additional restrictions. So I can’t receive GPL’ed software, make changes, and then distribute those under a new license with additional restrictions. If I get and distribute GPLv2 software, I have to pass it on as GPLv2 software. (Or a later version of the GPL like GPLv3 if the original had the provision to choose a later version. But that’s a tangent here that’s not relevant…)

But isn’t Red Hat imposing a restriction on distribution with its subscription agreement?

I don’t believe so, no.

If I have a RHEL subscription and receive RHEL 8.5, for instance, I’m entitled to those sources. But as I understand the subscription agreement(s) from Red Hat, it has the option of terminating my subscription if I choose to distribute those sources in a way that Red Hat decides is outside its subscription agreement.

That might seem like a restriction of my rights, but it isn’t. I entered into an agreement with Red Hat to do business with them, which includes receiving GPL’ed software. If I sever that agreement, let’s say via non-payment, then I still have rights to distribute that GPL’ed software. Red Hat can’t take those rights away once they have conveyed them to me.

But Red Hat doesn’t have to keep distributing new software to me if I stop paying. And they don’t have to keep doing business with me if I start compiling that source code and shipping it as JZB Linux. Red Hat can’t claw back the (GPL’ed) sources from RHEL 8.5, but it can absolutely refuse to distribute RHEL 8.6 or later versions to me.

This is all part of IBM’s evil plan

Yes and no, but largely no in my opinion.

First of all, I don’t think that this is evil. It might be bad strategy and/or communication, but I don’t think this is evil for a number of reasons that I will cover in a future post.

Yes, this is ultimately on IBM. That is, IBM owns Red Hat now and it’s responsible for whatever Red Hat does for good or ill, because they choose the people who run Red Hat. Presumably if they are taking notice of the way CentOS has been changed since 2019, they’ve had ample time to weigh in with Red Hat leadership.

But I don’t believe there’s a master battle plan at IBM headquarters that dictates what Red Hat does or doesn’t do with CentOS and RHEL sources or RHEL development overall. I find it interesting that so many people simultaneously credit IBM with having a multi-decade plan to undermine open source, but suggest that IBM is hopeless at strategy.

My tenure at Red Hat overlapped with the IBM purchase and subsequent takeover of Red Hat. My sense is that IBM communicates with Red Hat’s leadership and has goals for Red Hat’s sales, and has ways it wants to collaborate between IBM and Red Hat offerings. But I don’t believe that IBM leadership is directly telling Red Hat what to do with CentOS.

Rather, I think that Red Hat’s leadership is looking at their sales goals and the market at large and trying to keep RHEL sales healthy and keep RHEL from being commoditized or sidelined.

Red Hat is betraying the community

Again, no. I know this will be an unpopular opinion, but I don’t believe this is so – assuming this is the end state of changes to CentOS and distribution of RHEL sources.

A lot of folks want a perfect RHEL clone that’s binary / bug-for-bug compatible and downloadable without any subscription friction. To that I say… it’s nice to want things, but if you’re not a customer and you’re not even willing to sign up for a no-cost subscription, you’re not entitled to it. You’re just not.

Red Hat is producing CentOS Stream and releasing sources, for free, to anyone, that have all the features and enhancements going into RHEL. Remember that they’re still releasing far more than they’re actually obligated to release. Some of RHEL’s software is not GPL’ed and requires no source from Red Hat at all. Some of RHEL is owned by Red Hat and they could hold that back, but don’t.

If you want to run something like RHEL, you can run Stream and have a fine Linux distribution. Competitors to Red Hat could do the work of testing Stream releases and re-brand them as their own, and get a huge amount of development and testing work for free.

Here’s what you don’t get, the one thing that Red Hat is effectively holding back now: The ability to easily recompile sources and claim bug-for-bug compatibility with RHEL, and the ability to say they are RHEL sources.

When a project compiles the sources from Stream there’s some uncertainty about whether it exactly matches the RHEL release. For most scenarios you don’t need certainty. You just need a distro that feels like RHEL and that can run a workload.

If you need certainty, it’s probably for business reasons. You need to be able to tell a vendor “I’m running this on RHEL 8.5.1” or whatever. The vendor needs to be able to test against specific releases. And, if you need those things, you should pay for them or at least sign up for the no-cost subscription that Red Hat provides for development purposes. If you’re unwilling to do those things (or unable) then you’re going to have to settle for almost-as-good.

True, it also hits community projects and developers who’ve been doing The Lord’s Work in writing free and open source goodies for RHEL. I don’t blame those folks for being annoyed (or worse) and for dropping RHEL support. This is a risk that Red Hat took. (That falls under a strategy discussion and that’ll come later…)

The unnamed players in this drama

But I wouldn’t assume Red Hat was ignorant of that risk, nor do I think “the community” was in Red Hat’s crosshairs here. Red Hat is in a really hard position here that doesn’t get enough consideration. They have the most popular paid Linux distribution with an enormous impact on the operating system market. Red Hat is also, even as part of IBM, still the underdog. Remember that Red Hat is in “coopitition” with companies like Microsoft, Amazon, Google, Oracle, VMware, and many more.

This post is already getting longish, so I’m going to save the strategy and rationale thoughts for another post. Suffice to say that I don’t think Red Hat has any interest in preventing small organizations and individuals or community developers from accessing RHEL or a RHEL clone.

Red Hat’s leadership is smart enough to know that it benefits from a certain amount of unpaid use, and it isn’t going to extract money from all users and use cases. Red Hat isn’t the RIAA here, they aren’t trying to shake down individuals or businesses/organizations with a few dozen employees. They may be caught in the crossfire, however, and the repercussions from that are going to be difficult to predict or control.

More to come, stay tuned.