Red Hat CEO: Go Ahead, Copy Our Software

Home » CentOS » Red Hat CEO: Go Ahead, Copy Our Software
CentOS 57 Comments

Title says is all. Nice to know RH understands and accepts the relationship between CentOS and RHEL.

Although it is complex. After all, if too many choose CentOS, there may no longer be a CentOS. However, I don’t think I would refer to CentOS as a “parasite” as the author Matt Asay does. More appropriate to call it symbiotic.

Is the relationship a 50/50 affair? Not sure.

Complicating matters even more is Oracle Unmistakable Linux.

57 thoughts on - Red Hat CEO: Go Ahead, Copy Our Software

  • Robert Arkiletian wrote:

    Yeah, and the author *really* doesn’t understand, and didn’t bother to try, to do their research.

    Arguably one critical area that CentOS hasn’t helped Red Hat is with developers. While developers want the latest and greatest technology, Red Hat’s bread-and-butter audience over the years has been operations departments, which want stable and predictable software. (Read: boring.)
    CentOS, by cloning RHEL’s slow-and-steady approach to Linux development, is ill-suited to attracting developers.
    — end excerpt –

  • How about the real history, where Red Hat took a bunch of software developed by others, published the barely-working stuff with horrible bugs (read the changelogs if you disagree….), then accepted contributed debugging, fixes and improvements from the users until it was good enough to charge for, then they cut off access even to the people who had helped make it usable. And CentOS helps fix that problem.

  • I have no problems with RedHat and have used CentOS steadily for quite some time now. Even though it’s at home on my personal machines, I have been aching for my company to adopt an open source alternative to the five or six Windows 2008 servers that are currently in place…and I’ve made progess! So MUCH progress that in another month I’m to have a
    “sit-down” with the higher-ups from Accounting…IT…and “Corporate” to determine if my suggestion warrants merit, and if so….how to go about implementing it….when I finally do get my chance “on the mike” so to speak?…I’ll be recommending both Red Hat AND CentOS… they’re basically the same thing…and the things I won’t be able to troubleshoot myself…I’ll have the RedHat Tech Support handle. Either way I see it as a win-win situation. The author might have flubbed a few things…as others have stated, CentOS…isn’t a “parasite” to RedHat….but more a “sibling”. And RedHat really DOESN’T own any of the source code it sells! but hey…everyone makes mistakes!……LoL! I
    will say this: I have used Windows since the Win ’95 era, and even though they have come a long way, I have not enjoyed using my computers as much as when I installed Linux, and not just CentOS….but Fedora…Ubuntu….openSuSE……Debian….etc. I wish there was a way to “return’ the favor to al lthe developers and contributors to the Open Source movement….!


    EGO II

  • What about bait and switch?

    Remove the stuff contributed by others and what would still work at all?

    I guess I’d rather have seen the contributed work go to a distribution that didn’t develop a community with a free version and then after accepting their work, take the free version away. CentOS still gives the same effect, so why didn’t they just continue to allow redistribution?

  • What about the fact that you’ve been beating this same horse for many years now and it’s a little tired at this point?

    If you’re so disgruntled with Red Hat, and from the many years of beaten horse posts it’s clearly evident that you are, why do you continue to use their components? CentOS originates with Red Hat no matter how you care to look at it.


  • They are the ones that changed their position. Mine hasn’t and won’t. And I can’t see a reason why it should.

    If you are so happy with Red Hat, why even consider CentOS?

  • Exactly, explain where the GPL distinguishes between what restrictions you can add to binaries vs source components.

    So, what about redistribution of copies?

    I could use debian, but then I’d have to learn to type apt-get instead of rpm. I’d prefer to continue using the commands that Red Hat baited us with.

  • So, if you have a license that says “the distribution of the whole must be on the terms of this License,” and ” You may not impose any further restrictions on the recipients’ exercise of the rights granted herein”, it really means that you can add something that adds restrictions.

    I have my reason. You don’t have to like it.

  • For me Redhat and CentOS have their place, together in the same environment:

    RedHat –> Production Systems, with paid-for support, something goes wrong then I have some commercial comeback to get it fixed. High change control environment.

    CentOS –> QA, Development and Test Systems, and sometimes, non-critical infrastructure, community support, more roll-your-own fixes and workarounds. Less change control.

  • You can also purchase production support for CentOS through OpenLogic. Roll your own bug fixes aren’t necessarily bad, especially when you are able to send them upstream so they benefit everyone.

  • While I agree that CentOS will always have support while it is community driven, and has an upstream – without RedHat, no CentOS… the truth of the matter (when it comes to $$$):

    CEO’s and CTO’s like to hear that their critical software is supported by a company with a $10bn market cap. That is their indicator that they’re not relying on some fly by night, dead-end technology. They also like to hear that our non-essential infrastructure is run on software that is ‘free’ and mirrors the company they run their critical software on. I’m sure companies like OpenLogic do a good job, but it is difficult to convince upper management that these companies are still going to be around in 5-10 years time.

  • It wouldn’t be impossible to continue CentOS without RedHat, the community would be capable of pushing it forward. That’s not to say that RedHat isn’t doing a great job, but if they were to stop the CentOS project could and probably would go on IMHO.

    CEOs and CTOs like to hear that their critical applications are properly supported and that the call is answered and the issue resolved within their SLA when support is utilized. Having a $10b market cap doesn’t mean you will get quality support, look at Oracle Enterprise Linux. I had tickets open for over 6 months when the company I worked for used their
    “enterprise” distro.

    It probably wouldn’t be a difficult sell when you show the cost difference, also depending on the skill level of the engineers in-house of course. I
    didn’t mean to say that OpenLogic fits in all scenarios, but it should be evaluated as an option like any other vendor when the decision is being made.

  • RedHat Linux is largely a community distribution, it is a collection of upstream community sources with RedHat developers and engineers assigned as package maintainers. Their product is support and not software.

    I think we all know that rebuilding SRPMS and development are different worlds but that doesn’t mean that the community wouldn’t come together to continue moving it forward. I know I’d try to help… The biggest challenge would be in developing the next major iteration but for a product already deep into its cycle like CentOS 6 it wouldn’t be very difficult at all.

    It may shed a number of CentOS users on the front end, but a large number of them would come back.

  • So which section of the GPL is it that exempts binaries from being considered derived works with the same requiremnets?

    Breaking compatibility would go against everything I like about Linux and it’s not like the alternatives are perfect either. But regardless of how much you care about my opinion, can you seriously say that you like the fact that the community of free users that helped take the Red Hat product from something that barely worked up to the fairly robust and usable 7.x version has been split into a set that favors stability using CentOS where there is really no way to contribute improvements and the wild and crazy fedora set that doesn’t care about stability or maintaining compatible interfaces across versions. With the fedora set driving new development…

  • I think that Red Hat understands the benefit that they get from CentOS, as expressed by Mr, Whitehurst’s statement:

    “CentOS is one of the reasons that the RHEL ecosystem is the default. It helps to give us an ubiquity that RHEL might otherwise not have if we forced everyone to pay to use Linux. So, in a micro sense we lose some revenue, but in a broader sense, CentOS plays a very valuable role in helping to make Red Hat the de facto Linux.”

    Its obvious the benefit that CentOS gets from Red Hat (without those sources, publicly released, CentOS would be extremely hard … almost impossible). SUSE does not release their enterprise sources and there is no SLES clone because of it.

    We do want people to use CentOS for everything they feel comfortable using it for (obviously), but we also would recommend that people use Red Hat Enterprise Linux for things where they want a service level agreements or the specific certifications (Like Common Criteria EAL, etc.) that Red Hat has spent tons of money and effort to get. We would also recommend the Red Hat training and certification program for people who want to get career training that is applicable to CentOS.

    The bottom line … Robert is correct, the relationship is certainly symbiotic and not parasitic. Red Hat (the company) needs to make money, and software that is built on the same code base is available for free as well. It is a win-win … which is exactly what the GPL provides for.

  • I agree completely, but the way that they’ve handled the devtoolset just seems a bit odd. It’s definitely a VERY nice to have an updated toolchain available, but why is a separate product? It is available for install with CentOS ( )
    but the issue is that there’s no clear way to use the compilers in the devtoolset with the EPEL and that’s VERY unfortunate in my opinion.

  • Exactly my point. Everything is about derived works. So binaries cannot be exempt from the requirement that the work as a whole can only be distributed under a license that permits free redistribution and that additional restrictions cannot be added. If you want to refute that, please quote the section stating what you think permits it.

  • Red Hat is clearly aware that they would never have become a popular distribution in the first place without their own freely redistributable release. My question is why they now think it is better to not provide that directly – and get the brand recognition, community input, and potential support customers using the exact code as they will as paying customers. Why push them to work-alikes with different branding where many users won’t even understand the relationship, with the obvious danger that another brand may compete for paid support?

  • Spot on. “They understand the symbiotic relationship.”
    Thank you for quoting that, Johnny.

    If anything the journalist deserves the heat and criticism for trying to make clones look/sound bad. After all, bad news sells better than good news, right? [No need to answer.]

    I’ve long had a personal lab based on Fedora, Debian, and CentOS (though my install base has other creatures as well). If I didn’t have CentOS, I might run Fedora (it’s not too bad on stability for non-critical applications) — BUT I’d have more of a Debian install base if CentOS wasn’t around.

    *Everyone* that’s chimed in has valid points, but they aren’t worth arguing about. Probably the only way to make change (if necessary) is for RH employees to back any proposals for change.

    As Dave pointed out there have been some oddities in what is released (in availability and even the quickness of some updates), but overall I don’t think it’s anything to get upset about. I suppose that’s because I know I
    have options … kinda goes along with OpenOffice vs LibreOffice, etc.

    Look at the bright side!
    [We have CentOS, we have options.]

    Have a great weekend everyone.

  • You CAN distribute both the Source and the Binaries under the GPL. You CAN’T do that and be in accordance with the Terms of Service for RHN. So, you get to decide what you want to do. RHN is the customer portal that gives you access to help, updates, support, etc.

    It is in accordance with the GPL and SUSE has the same kind of policies for SLES.

  • Les, binaries aren’t derived works. They’re machine-generated translations.

    A derived work would be a change in the source code; binaries are direct machine-readable translations of unmodified source code.

    And the GPL covers just the programs on the distribution that are, well, covered by the GPL at the source level. Mere aggregation doesn’t mean the whole iso is under the GPL, only the binaries that are compiled from GPL source are. The copyright for the collection may prohibit distribution of the collection (in its aggregated form), but you might be able to distribute those individual binaries that are built from GPL
    sources; but you would violate your subscription agreement (a separate legal agreement and not part of the copyright license) if you did so.
    After all, the licensor of the GPL-covered program is in many cases not Red Hat; the subscription agreement is a contract with Red Hat and Red Hat alone.

    The GPL is all about source code availability, not binary availability.
    To wit, see this section in the GPL FAQ:

    And even applies, as ITAR would represent a ‘restriction’ on distribution, no?

    But again the GPL coverage doesn’t extend to the aggregation in ISO
    form, only to the individual programs on the ISO.

    Nothing in the GPL says that if you distribute the source to the public you must distribute binaries to the public; all it says is that if you distribute binaries you must distribute or include a written offer to distribute the source to the people to whom you have distributed binaries. This is how SuSE (to use Johnny’s example cross-thread) gets away with not having public distribution of the sources for SLES (if you find the publicly available sources for SLES with updates please let me know, and OpenSuSE is not the same thing).

  • If you are asking for an opinion, I actually agree that they (Red Hat)
    should also give it away for free. However, nothing requires them to do so. Since they didn’t, CentOS was created and fills that niche.

    Again, they need to make money and because of that, they decided not to distribute the binaries for free. That is a valid business decision. Its not the only decision that could be made and it might not be the correct one, but its the one they made.

    While the code base the RPMs are built from is the same, but the built binary software is NOT exactly the same. Red Hat can argue that therefore CentOS (or Scientific Linux, or Oracle Linux) is similar but not the same and if you want the real software .. OR .. if you want SLA
    support, then you should buy access from RHN. AND, they can also say, if you don’t want to buy anything and that is your final decision, there is something that is similar you can use and if you ever need support then you can move to RHEL. As their CEO said, SUSE can not do that.

  • Really? Are none of the trademark-restricted additions packaged into GPLed items? Or is redistributing the trademark OK as long as nothing is changed? If you could obtain a copy and didn’t care about RNH, could you ship straight RH binaries instead of rebuilding?

    It is all sort of a technicality anyway without an update source. Given the vulnerabilities that are always shipped, it would be somewhat insane to run the code at all without a reliable source of updates. Which I thank CentOS for providing…

  • Johnny Hughes wrote:

    Hmm. In my opinion, Red Hat is doing the right thing. I
    learned long ago that customers fall into a quadrant of being high profit or low profit and low maintenance or high maintenance. It’s always a good decision to drop the low profit and high maintenance customers.

    By doing this, Red Hat keeps a good reputation since it can avoid dealing with users who are most likely to have a bad experience due to unrealistic expectations.

    I’m just glad that they do provide the source code and that the folks behind CentOS do everything that they do!


  • The redhat-logos, redhat-release, and redhat-release-notes (if it exists)
    packages contain the trademarks that need to be changed at a minimum. I
    can’t speak for CentOS but at Fuduntu we just replaced Fedora or RedHat with Fuduntu in the spec, or any patches whenever we came across it in addition to those three.

  • Well, certainly there is nothing wrong with their decision and there are pros and cons to both approaches. I am also very happy they provide public sources.

  • There are a couple of packages that you have to modify to “distribute”
    as they are not GPL.

    I was talking about in general terms and specifically about GPL items. Each program has it’s own restrictions and license.

    This is why we rebuild each and every program and redistribute those, then we only need to meet the trademark requirement. (and not the portal requirement or the RHEL EULA).

    My point was, there are two things at play if you distribute the original content (either Binary or Source) and that is the copyright of each individual program and the license for access to the upstream services. You agree to both, not just the copyright. Others have also said this.

    Here are the 3 things in play:



    Use of portals/content (RHN):

    Of course, this list is not a compliance discussion area for upstream
    … talk to your attorney if you have any questions :)

  • You’re free to grep through the license fields in the RPM database to find out, for those packages which contain trademarks. I’m not going to do it for you.

    If you only wanted a single shot at redistribution, and you didn’t care about RHN, then you still can only redistribute binaries that have licenses that specifically permit binary redistribution, and only individual packages at that, since the ISO, as a collection, is a separate work (it’s an ‘aggregation of works’ (an anthology, if you will)) for copyright purposes and could be under a completely different distribution-not-allowed license. There are some licenses out there that could be argued to only cover the source and not the binary translation (GPL does specifically cover the object code and executable forms, IIRC).

  • What about permitting redistribution? And if losing your RHN support as a consequence isn’t a restriction that the “You may not impose any further restrictions on the recipients’ exercise of the rights granted herein.” covers, then what kind of restriction could that clause possibly mean?


    While it’s not been tested in a court of law, and I am not a lawyer, it seems to me that if I were to redistribute a Red Hat binary RPM of a GPL
    package that I might not have anything to worry about. But I reserve the right to be wrong, and this is not legal advice, and I’m not willing to be a test case, either.

    However, again, the aggregate work of the installable ISO is not under the GPL, and so you would want to check with your own counsel as to the advisability of redistributing the installable ISO. As the GPL states clearly: “In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. “

  • Please quote the section that you think exempts binaries. I’m not really a fan of the way the GPL prohibits many potential best-of-breed combinations of components, but I did read it…

  • The GPL works by taking away the rights it grants if you violate the specified terms. Not adding further restrictions is one of those terms. How is that not a “further restriction”? Or if it isn’t, what would be?

  • The word “herein” in the GPL snippet above is significant. The GPL does not allow further restrictions of “the rights granted herein” — i.e. the rights granted by the GPL. Since RHN access (and other benefits of a Red Hat subscription) are not granted by the GPL, restrictions of
    *those* benefits are not relevant to this provision of the GPL.

    You’re obviously free to disagree with this interpretation of the GPL, but I know of no case law which supports such a position.

  • I’m talking about the consequences Red Hat applies if you were to exercise the right that the GPL says you have to redistribute copies. If the threat of such consequences aren’t a restriction, what would be?

    I realize that Red Hat does, in fact do more than required in other areas so this is just a philosophical point, but I don’t see how their treatment of binaries meshes with the letter of the GPL.

    I also realize that since CentOS and other derivative distros rely on the ‘more than required’ parts (non-GPL’d parts, source in easily reusable form, etc.), it could all go away on a whim, just like the freely redistributable binaries did, so even if you are happy with today’s scenario, there’s no reason to expect it to last.

  • Sorry, but that quote does not appear in any copy of the GPL that I
    can find. And it’s not true, either. Everything it says is about
    ‘works as a whole’ and anything that can be considered a copy or derivative work under copyright law.

  • The only leverage RedHat has to prevent people from redistributing RHEL
    binary media are the trademarks contained within the three packages I
    mentioned previously. They are included on the installation media
    (obviously). GPL does not apply to trademarks (only copyright), so even though those three packages are technically GPL, they can’t be redistributed under RedHat’s trademark guidelines. The srpms can’t even be redistributed except by RedHat (they are available on their public FTP

    RedHat’s trademarks are the only reason why you can’t take the RedHat ISO
    and distribute it to whomever you want. You can however take any of the packages minus the three packages containing trademarks and distribute them in binary format, there is no real benefit to doing that though when you can simply build the rpms from source.

  • And that is exactly the point. They are not considered differently in terms of restrictions you can apply or adding to ‘works as a whole’ in copyright terms. If the distribution of any part of a work is only permitted by the GPL and you don’t follow the GPL terms (say, by adding restrictions of your own), you would not be permitted to distribute at all.

  • Apparently not…

    No. It applies to everything copied/derived from/translated from
    (etc.) anything where any part is covered by GPL. Including binaries.

    Yes, and without it, nothing gives you the right to distribute programs where any part is covered.

    Yes, I am only talking about the components where copyright law would consider it a copy or derivative of GPL code. And I didn’t say otherwise.

    They are irrelevant to the discussion of how binaries are equally covered by the ‘no additional restrictions’ section. The only place where source is different is that if you distribute binaries you are required to also provide matching sources. There is no mention of any exceptions to the requirement to permit redistribution for any covered work in any form.

  • Not exactly. The aggregate collection, just because it contains GPL-licensed software, is not necessarily under the GPL as a whole, and the ISO itself is copyrighted.

    Further, out of the 2108 packages I have installed on one of my RHEL6
    systems, 678 of them are not GPL-covered.

    And then there’s:

    [root@www ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.4 (Santiago)
    [root@www ~]# rpm -q –queryformat “%{NAME}-%{VERSION}-%{RELEASE}
    %{LICENSE}\n” redhat-logos redhat-logos-60.0.14-1.el6 Copyright 1999-2010 Red Hat, Inc. All rights reserved.
    [root@www ~]#

    In other words, if you distribute an ISO, and that ISO contains the source code or binary code of redhat-logos, that’s a copyright violation as no one but the copyright owner, Red Hat, Inc., has the right to distribute it. So you can’t distribute that ISO due to both a copyright violation and a trademark violation.

    Now, GPL does specifically cover binaries; that’s the whole of section
    2. The last paragraph of section 2 I’ve already quoted, and that makes clear that RHEL the distribution, which is an aggregation of programs, some covered by GPL, some not, is not all covered by GPL just because it includes some GPL-covered programs.

    The case of redistributing an ISO containing the binary or source RPM of redhat-logos is clear; it’s not freely redistributable.

    The cases of GPL-covered binary RPM’s being redistributed has not been tested in court to the best of my knowledge. And I don’t plan to become the test case.

    Of course, I am not a lawyer, and I reserve the right to be wrong. But it’s clear that Red Hat has cleared their policies, contracts, licenses, and agreements with their own lawyers, and those lawyers know a great deal more about that than any of us (with at least the one notable exception of Russ) does. One of those lawyers is now the primary editor on…… I met him (Mark W.) in Asheville, and he’s a nice guy, and he really is the expert on these things.

  • Well look at that, TIL about the redhat logos package. Even if they couldn’t copyright the ISO itself (though I think you are probably right that they can), since it contains a non-GPL logos package that’s also protected under trademark law it’s effectively illegal to redistribute on multiple fronts.

  • I can’t believe I never thought about it (to wonder why there wasn’t any SLES clone)…

    Shouldn’t they release the source for the GPL packages? I thought there was no way around it (and therefore that’s why Red Hat had to do it).

  • a number of embedded consumer boxes just release tarballs of the stock distribution software, without any of their modifications, drivers, or build configuration. try and find sources for, say, a WD TV Live, and you’ll find a tarball of distribution tarballs of the linux kernel, ulibc, and various other such things, all dead stock.

  • 1. They only have to release Sources to the people who they have given
    (sold) their software. They do not have to release them to the general public.

    2. Red Hat goes above and beyond this requirement, not because they have to but because they want to.

  • Which, if true, is to say that one may not rebuild GPL source on systems whose architecture and/or cpu instruction set are propriety. Binaries are not open by definition. They are built for one specific environment by one specific compiler and one or both both of those may not be covered by a GPL of some sort. How then can such a binary be considered a derived work under the GPL?

    The GPLs that I have read are concerned with the source and only the source. From that source you may build the software without consideration of the nature of the build tools and therefore the results (binaries) I believe are not, and meaningfully cannot be, covered by the GPL.

  • If they offer free version themselves, they they would have to publish sources and binaries for free version at the same time as for paid-for version, which would further lower their profits. Reasoning is that some people do not care about support, but expect fast security releases. So if Red Hat offered free version, they would not have incentive to pay for fast release.

    If Red Hat tried to release packages even few days later then for paid-for version, they would be obvious bad guys in peoples eyes, greedy, etc.

    By offering only source code, they make sure they are faster then those recompiling their source packages, so they are obvious good guys that provide for their customers, but at the same time they are obvious choice for all businesses. And I and majority of others are fine with that.

  • Everytime I see a discussion like this on the list I feel an urge to switch either to debian or ubuntu lts.

  • I don’t see how you’d reach that conclusion. There are no restrictions on how you can use code covered by the GPL, only on how you can distribute it – that is, only the things copyright law would prohibit if you don’t follow the license terms.