Official response: "This is a real threat to open source", Red Hat executives personally wrote an article to express their feelings

On June 21, Red Hat released "Further Promoting the Evolution of CentOS Stream" 1 on its official website , which sparked a wave of intense discussions, including many criticisms.

I wrote a special article "In-depth Interpretation: Red Hat's new regulations betray open source and provoke public outrage? 2 , an interpretation of its spirit and influence, published on the official account of "Wei Sir Shuo" .

On June 26, the official response came. Red Hat's official website published "Red Hat's Commitment to Open Source: Response to Changes to git.centos.org" 3 , the author is Mike McGrath (hereinafter referred to as Mike) , and he is also working on It is the author of the article published on June 21. He is the vice president of core platform engineering of Red Hat. He is called Red Hat's "executive" on the Internet, but it is not true.

Looking at it, in general, he said the following meanings:

  • Some people have bad words and don't do us justice.

  • We work hard, we value open source, and what valuable work we do.

  • We know open source very well, we know open source licenses very well, and I'm shocked that many veterans in the industry don't understand this.

  • There's no point in cloning us, do something worthwhile.

  • Cloning is a real threat to open source companies, and open source may return to the past.

From my first feeling, he has some things that are right, and some things that I think are not right.

The layout of this article: first the translation, then the original text, with my comment (blue font) inserted in the middle.

I feel compelled to state that all my comments are directed solely at Mike McGrath and his words. Not aimed at Red Hat  (although Mike implied that he represents Red Hat, I think some of his remarks do not represent it) , let alone Red Hat employees, thank you for your professional skills and hard work; especially not at people I know who work in Red Hat My friends , it is you who let me feel the high quality of Red Hat employees. If my comment makes you uncomfortable, please ignore, please ignore, and please understand.

Start now:


Title: Red Hat's Commitment to Open Source: Responding to git.centos.org Changes

Title: Red Hat’s commitment to open source: A response to the git.centos.org changes

By Mike McGrath

I spent a lot of time this weekend walking and thinking about the industry's reaction to my last blog post. We are called "evil". Some people say that I am an executive arranged by IBM, saying that we are going to turn Red Hat into closed-source software. These comments are relatively "friendly" (author's note: it means there are more malicious of) . So let's clarify.

I spent a lot of time walking this weekend thinking about the reaction from our industry to my last blog post. We’ve been called evil; I was called an IBM exec who was installed to turn Red Hat closed source — and that’s only the “nice” stuff. So let’s clear things up. 

My name is Mike McGrath and I'm Red Hat's Vice President of Core Platform Engineering. I've been working here for 16 years, and before that I was a volunteer on the Fedora Project. Open source and all the ideas it encompasses are very important to me. Over the past week, I've seen a lot of unkind and untrue things said about the hard-working Red Hat folks who, like me, value open source very much.

My name is Mike McGrath, and I’m the Vice President of Core Platforms Engineering at Red Hat. I’ve been here for 16 years, and before I started working here, I was a volunteer in the Fedora Project. Open source and all that phrase entails are very important to me. Over the past week, I’ve seen many people say many unkind and untrue things about hard-working Red Hatters who, like me, value this work to its core.

Despite the rhetoric, we still make the fruits of our labor readily available to non-customers. Red Hat will always use an open source development model. When we find bugs or write new features, we contribute code upstream. This benefits everyone in the community, not just Red Hat and its customers.

Despite what’s currently being said about Red Hat, we make our hard work readily accessible to non-customers. Red Hat uses and will always use an open source development model. When we find a bug or write a feature, we contribute our code upstream. This benefits everyone in the community, not just Red Hat and our customers. 

We don't simply recompile upstream packages. At Red Hat, thousands of people spend their time writing code that adds features, fixes bugs, integrates disparate software packages, and then makes them work over time—and that's exactly what our customers and partners say. needs.

We don’t simply take upstream packages and rebuild them. At Red Hat, thousands of people spend their time writing code to enable new features, fixing bugs, integrating different packages and then supporting that work for a long time - something that our customers and partners need. 

We spend a lot of time, including overtime, to apply a patch to an old version of the operating system that has been 5, 10, or even longer (Note: This work is called backport, which can be translated as "reverse porting") ; at any one time we are supporting 3-4 major releases, patching and backporting all of them. In addition, when patching RHEL issues, we don't just apply the fixes to RHEL, we implement the "upstream first" (upstream first) philosophy, we will provide the fixes first to Fedora, CentOS Stream or the kernel project itself, Then backport will be done. What a daunting task it is to maintain and support an operating system for 10 years—and how valuable it is.

This is about the hours and late nights we spend backporting a patch to code that is now 5 to 10 years old or older; at any given time, we are supporting 3-4 major release streams, while applying patches and backports to all. Additionally, when we develop fixes for issues in RHEL, we don't just apply them to RHEL - they are applied upstream first, to projects like Fedora, CentOS Stream or the kernel project itself, and we then backport them. Maintaining and supporting an operating system for 10 years is a Herculean task - there‘s enormous value in the work we do.

We will always provide our code upstream and abide by the open source licenses used by our products, which includes the GPL. When I say we abide by various open source licenses in our code, I mean it. I'm appalled and disappointed by the amount of mistakes many people make with open source software and the GPL in particular. **Especially some industry observers, even veterans who I think should know a lot about open source licenses, can make mistakes. The open source license and intellectual property stuff is important to let Red Hat know where to come from, what to stick to, and how to grow.

We will always send our code upstream and abide by the open source licenses our products use, which includes the GPL. When I say we abide by the various open source licenses that apply to our code, I mean it. I was shocked and disappointed about how many people got so much wrong about open source software and the GPL in particular —especially, industry watchers and even veterans who I think should know better. The details — including open source licenses and rights — matter, and these are things Red Hat has helped to not only form but also preserve and evolve. 

I think there are two kinds of people who are angry about our latest downstream source policy: those who don't want to pay for RHEL, they don't want to pay for our time, energy and resources; and those who want to repackage it, and those who benefit from it. Their need for RHEL code is hypocritical.

I feel that much of the anger from our recent decision around the downstream sources comes from either those who do not want to pay for the time, effort and resources going into RHEL or those who want to repackage it for their own profit. This demand for RHEL code is disingenuous. 


Wei sir comments:

Seeing this, I disagree. Why do you say that these two types of people are hypocritical? It's just that people don't want to pay, it's just that people want to repackage to get benefits?

I think this Mike doesn't understand open source as much as he said, at least he doesn't understand the spirit of open source. An important spirit of open source (here refers to open source in a broad sense, including free software) is to give people freedom, not to force or force others to do something. Even if the GPL forces developers to open source code, it is to give freedom to the most people. All open source licenses allow others to distribute them for free, and they all allow others to use open source for profit. Why do you think that those who want to obtain software for free and profit from it are hypocrites?

Of course, you have spent a lot of energy, invested a lot of resources, and spent a lot of time doing this, but whoever is engaged in open source has not spent a lot of time and energy? Isn't Linus? Isn't Stallman? Did any of them say that not paying is hypocrisy? Does anyone say that people who want to monetize their software are hypocrites?

Where is the sentiment! If you want to make money, there is no problem. I support you to make money, and I even support you to use open source to make money. But those who say that those who want to get software for free are hypocritical, then you are wrong. Their free acquisition is legal and compliant free acquisition!

If someone says that disingenuous should not be translated into hypocrisy, then you can try "disingenuous", "disingenuous", "insincere", "dishonest", "cunning", the meanings are similar.

Continue the original text below:


We have to pay the people who do this work as passionate contributors who put in the hours and nights and who believe in the value of open source. Simply repackaging the code these people produce and reselling it intact without adding any value makes the production of open source software unsustainable. This includes critical backport work, future features and technologies being developed upstream. If these jobs are not sustainable, it will stop, which does no one any good.

We have to pay the people to do that work — those passionate contributors grinding through those long hours and nights who believe in open source values. Simply repackaging the code that these individuals produce and reselling it as is, with no value added, makes the production of this open source software unsustainable. That includes critical backporting work and future features and technologies under development upstream. If that work becomes unsustainable, it will stop, and that's not good for anyone.


Wei sir comments:

Seeing this, I can't help but think of what Nadia, the author of "Working in Public" said:

"Producers are constantly fighting an uphill battle to force consumers to pay by threatening, blocking, begging, blaming and shaming consumers."

Producers constantly fight an uphill battle to threaten, lock down, beg, blame, and shame consumers into paying for content.

What a familiar drama.

Again, it’s okay to ask for money, I agree, but it is necessary to allow someone who legally does not like to give money.

It's okay to try to persuade others to give money, but how similar is this passage to what Bill Gates said many years ago?

People are just condemning those who pirated. That's good, let's start attacking the legitimate crowd.

On February 3, 1976, Bill Gates wrote an open letter to computer enthusiasts complaining that the unauthorized use of Altair BASIC was so common that the newly formed Microsoft Corporation had little return. This letter is quite famous and is seen as the real beginning of the commercial licensing of software for revenue.

Continue the original text:


I would like to point out that recompilers (author's note: English rebuilder, translated here as recompilers, actually clone makers) are different from those who make real changes. For example, the latter may be operating The system adds new architectures or compile options. (We fully support you in extending the functionality of Linux, not imitating it).

I want to specifically mention the rebuilders, different from distributions that might, for example, add a new architecture or compile flag (we fully support you in expanding Linux capabilities rather than imitating them). 

There was a time, not that long ago, when Red Hat considered the work done by recompilers like CentOS to be very valuable. We pushed the SRPM packages to git.centos.org in a neat way, made them easy to recompile, and we even de-branded them. But recently, we've decided that downstream recompilation doesn't make much sense.

There was a time, not too long ago, that Red Hat found value in the work done by rebuilders like CentOS. We pushed our SRPMs out to git.centos.org in a neat package that made them easy to rebuild; we even de-branded it for them. More recently, we have determined that there isn’t value in having a downstream rebuilder. 


Wei sir comments:

I have to say that Mike expressed his true thoughts very frankly.

As some people have sharply pointed out a few days ago, Red Hat used to think that the clone version (such as CentOS) was good and could help itself, but now it feels that the clone version is not helpful and worthless.


The generally accepted point of view is that these free clones can generate RHEL experts like a funnel, and eventually convert into sales (author's note: a small number of experts and sales will be generated from a large number of users using a funnel) , but But in fact, it's not. I had hoped we lived in such a world, but this is not the case. Instead, we found a group of users, many of whom belong to large or very large IT organizations, who wanted the stability, lifecycle, and hardware ecosystem of RHEL without actually supporting the maintainers, engineers, and writers who created RHEL And people in multiple roles who have also decided not to use one of the many other Linux distributions.

The generally accepted position that these free rebuilds are just funnels churning out RHEL experts and turning into sales just isn’t reality. I wish we lived in that world, but it’s not how it actually plays out. Instead, we’ve found a group of users, many of whom belong to large or very large IT organizations, that want the stability, lifecycle and hardware ecosystem of RHEL without having to actually support the maintainers, engineers, writers, and many more roles that create it. These users also have decided not to use one of the many other Linux distributions.


Wei sir said:

It was a familiar voice again: "The things we worked so hard to make are used by big factories, and big factories still make money with this. It's so unfair."

In the past two years, there were many complaints of this kind. Later, they changed the license one after another, such as using BSL and SSPL (these two are not recognized as open source licenses), because they have copyright.

Red Hat should not be easy to change. Unless it adds proprietary software to RHEL.


In a healthy open source ecosystem, competition and innovation go hand in hand. Red Hat, SUSE, Canonical, AWS, and Microsoft have all created Linux distributions with corresponding branding and ecosystem development. These variants all utilize and contribute to the Linux source code, but none claim to be "fully compatible" with other distributions.

In a healthy open source ecosystem, competition and innovation go hand-in-hand. Red Hat, SUSE, Canonical, AWS and Microsoft all create Linux distributions with associated branding and ecosystem development efforts. These variants all utilize and contribute Linux source code, but none claim to be “fully compatible” with the others.

最终,我们没有发现 RHEL 克隆版的价值,我们也没有义务让克隆工作更容易;这是我们的决定。Having said that, let me talk about CentOS Stream. People have a lot of misunderstandings about it. I admit that this is a change from a long-standing tradition that we have moved beyond, and this change can cause some confusion. This confusion manifests itself in accusations of closed source and alleged GPL violations. CentOS Stream has binary deliverables and source code repositories. The gitlab source code for CentOS Stream, where we build the RHEL distribution, is open to all. Calling RHEL "closed source" is patently untrue and inaccurate. CentOS Stream is developed faster than RHEL, so it may not be on HEAD, but the code is there. If you can't find it, please let us know - it's a bug.

Ultimately, we do not find value in a RHEL rebuild and we are not under any obligation to make things easier for rebuilders; this is our call to make. That brings me to CentOS Stream, of which there is immense confusion. I acknowledge that this is a change in a longstanding tradition where we went above and beyond, and change like this can cause some confusion. That confusion manifested as accusations about us going closed-source and about alleged GPL violations. There is CentOS Stream the binary deliverable, and CentOS Stream the source repository. The CentOS Stream gitlab source is where we build RHEL releases, in the open for all to see. To call RHEL “closed source” is categorically untrue and inaccurate. CentOS Stream moves faster than RHEL, so it might not be on HEAD, but the code is there. If you can’t find it, it’s a bug – please let us know.


Wei sir said:

The sentence " We have not found the value of RHEL clones, and we have no obligation to make cloning work easier ", is exactly the same as I speculated in the last article, and it is exactly the same as the first feeling of many people.

I support your decision, you didn't close the source, and you didn't violate the GPL, this is what I have to say.

Objectively speaking, what he said about the CentOS Stream code is correct. The RHEL code is indeed on CentOS Stream, and there is no private product on RHEL. It's just that the code on CentOS Stream is slightly newer.

I talked to an authoritative senior expert who works at Red Hat and he said:

" When RHEL was developing, there was a code tree, and the trunk of this code tree was CentOS Stream. The development rule of RHEL is that all quality assurance tests must be passed before patches will be added to this trunk. These patches are all backported Patch, bug fix, etc. These patches are basically the work done by Red Hat to maintain the stable operation of the long life cycle. When the patch is added to this trunk, we consider it stable and no longer test it. So The trunk is the state of all patches before they are released, which is the complete set. The minor version of RHEL is to pull the code from this trunk at a fixed point in time (about every six months) and package it for release.”

"If there is an inconsistency (author's note: say RHEL and CentOS Stream), it is the time difference, those patches that are inconsistent because of the time difference (author's note: for example, the small version of RHEL started at 9:00 am yesterday, and it was released at 9:00 this morning, then The new patches added to CentOS Stream from 9:00 yesterday to 9:00 today are the differences between RHEL and CentOS Stream), (author's note: these newly added patches) will be added to RHEL sooner or later, not that some patches are guinea pigs version, it will never be added.”

"I know that some people may worry about whether these patches are tricky, but these patches are treated equally without special markings. Moreover, the submission record of each patch can be seen by the public, and it is clear at a glance whether there are tricks."

The general meaning is: the source code on CentOS Stream will eventually enter RHEL, without any omission, it is only a matter of time. RHEL is compiled and built from the CentOS Stream code trunk. It's just that CentOS Stream is a rolling release, and RHEL has regular large and small versions.

Seeing this, people who understand should understand that it is feasible to clone RHEL from CentOS Stream, but it is not welcomed.

Continue the original text:


We also offer a free developer subscription, providing free RHEL to open source infrastructure. The Developer Subscription provides developers with free RHEL and allows free use on up to 16 systems. This can be used by individuals for their own work, and by RHEL customers for the work of their employees. RHEL for Open Infrastructure is designed to allow open source projects (whether or not they have any affiliation with Red Hat) to use RHEL for free to build their infrastructure and meet their development needs.

We also provide no-cost Red Hat Developer subscriptions and Red Hat Enterprise Linux (RHEL) for Open Source Infrastructure. The developer subscription provides no-cost RHEL to developers and enables usage for up to 16 systems, again, at no-cost. This can be used by individuals for their own work and by RHEL customers for the work of their employees. RHEL for Open Source Infrastructure is intended to give open source projects (whether or not they’re affiliated with Red Hat in any way) access to no-cost RHEL for their infrastructure and development needs.

Finally, I want to say to all open source companies, whether your code is already open source, or you are considering moving to an open source model. By any measure, Red Hat has "made it", and I wish many open source companies were as successful as we have been. You can decide for yourself whether downstream cloning is valuable to you, making cloning easier or less difficult is your decision.

Finally, I’d like to address every open source company out there, whether your code is open today or you’re considering moving to an open source model. By any measure, Red Hat has “made it” and I hope many open source companies can succeed as we have. You can decide for yourself whether downstream rebuilds are valuable for you and it’s your call to make it easy, or not. 

Simply recompiling code with no added value and no changes is a real threat to any open source company. This is a real threat to open source, and it has the potential to turn open source back into a hobby and hacker activity.

Simply rebuilding code, without adding value or changing it in any way, represents a real threat to open source companies everywhere. This is a real threat to open source, and one that has the potential to revert open source back into a hobbyist- and hackers-only activity.


Wei sir comments:

It has to be said that these words carry a lot of weight.

But one part is wrong.

Does cloning really have no value or add any value? Wrong , the value of cloning is that programmers who can't afford or don't want to buy the commercial version have a choice not to buy it, so that the founders of free software and open source software can see that people can freely and freely Use open source and free software instead of having to pay for commercial software.

Red Hat has done a good job, developers can use free RHEL, and allow free use on up to 16 systems, but developers do not like any restrictions.

I don't like big companies using RHEL clones for free to make money, but this is the reality. You can choose not to let big companies use them, if you have a good way.

Clone "could turn open source back into a hobby and hacking" is the most intimidating thing to say, will it?

Thinking about it carefully, is it really necessary to fulfill what Gates said in 1976?

Gates said in an open letter to computer enthusiasts: "To me, the biggest problem in computer enthusiast circles today is the lack of good software, related books and application software. . . . everything you are doing is preventing People write good software . . . . Who will do professional software development and get nothing. How can an amateur spend 3 man-years of effort writing software, fixing software, writing manuals and giving them away for free Use. In fact, only we invest heavily in making software for PCs. We have written 6800BASIC, written 8080APL and 6800APL, but now there is little incentive for us to provide these software to you. To put it bluntly, what you do is Theft. …”

Perhaps, open source software really needs to change the license (if not changed, it is the dilemma that Red Hat is facing now) , change the OSD (open source definition) , so that it can develop healthily? ? ?

Can the software industry develop better only if it is more commercialized?

I don't have time to analyze these today, maybe later.

Continue the original text:


We don't want that to happen and I know our community members, customers and partners don't want it either. Innovation happens upstream, and standing on the shoulders of others is the essence of open source. Let's continue to drive innovation, support each other, and move forward.

We don’t want that and I know our community members, customers and partners don’t want that. Innovation happens in the upstream. Building on the shoulders of others is what open source is about. Let’s continue to drive innovation, support one another and keep moving forward.

Mike's original text ends. 


Wei sir said:

Some people may think that I am a die-hard fan of open source, but I am not.

The Internet has a famous saying: "Information wants to be free". (Information Wants to be Free)

I said: As long as it can be commercialized, the software wants to charge. (Software Wants to be Paid)

I have never opposed the commercialization of open source software, as long as possible, we should try to collect money.

If you can't collect money yet, or don't care about money, open source first.

If you can still make money while keeping open source, that is your skill, thumbs up for you.

If keeping open source is not conducive to collecting money for a software that can completely collect money, then consider using a new license.

If it is software written by you, the new version of your software can be completely replaced by a commercial license.

Even if you used to release under the GPL license.

Author: Wei Jianfan


  1. https://www.redhat.com/en/blog/furthering-evolution-centos-stream 

  2. https://mp.weixin.qq.com/s/pZzgfguO234pG_b6jFoCRw 

  3. https://www.redhat.com/en/blog/red-hats-commitment-open-source-response-gitcentosorg-changes 

Guess you like

Origin blog.csdn.net/vigor2323/article/details/131447689