[clug] RedHat OpenSource And Proprietary

Paul Wayper paulway at mabula.net
Sun Dec 11 14:54:46 UTC 2016

On 11/12/16 09:21, George at Clug wrote:
>     I have often wondered where RedHat sits with being FOSS,
> OpenSource, and/or Proprietary

OK, as some people may know I work for Red Hat.  I'm going to answer in a
personal capacity, and since I haven't been working there for long I'm going
to answer in general :-)

> So today I searched the intenet, and did not find a simple answer,
> just lots of rambling.

Looking at the whole ecosystem and marketplace for Free, Open Source Software,
to me there's one basic tenet - you make money from services[1], not the
software.  For the most part that means paid support and/or paid consulting
(e.g. if you want a Red Hat Ceph cluster built, we can do that for you for
money).  Obviously at that point we get bogged down in the messy world of
licenses, entitlements, periods of service and other measures of how much a
customer has to pay for that support or consulting.  So at that point it looks
less 'open', since those things are designed to make sure the service provider
makes money off its clients.

I'd argue (and I think I would have argued this before I started my current
job) that the property of 'openness' is orthogonal to the property of
'customer relationship'.  In other words, the fact that Red Hat has customers
who pay money to have regular updates, timely updates for security problems,
and readily available support, doesn't preclude it also contributing to a
large number of open source projects in many many ways.

[1] Some companies, I observe, sell products based on the GNU/Linux kernel but
build an entire proprietary software stack on top of that and don't release
the source code for any of it.  Some companies sell support for an open source
product but offer no way for customers to contribute bugs or patches.  It's
worth remembering here that nothing in the GNU Public License prevents people
selling access to the software, as long as they also give access to the source
code for free.

And it's also worth remembering that many many companies have packaged
GNU/Linux in some proprietary form, not distributed the source code, got sued,
and ended up having to ... provide the source code.  See

> Can anyone explain to me if Red Hat is OpenSource or Proprietary. And
> how much of the proprietary code it purchases does it then open up to
> the OpenSource community?

>From what I've seen internally and externally Red Hat really tries hard to be
open source.  It tries to use open source products, and it pays for a lot of
developers to work on open source projects.  It's bought several companies in
the past and opened their products up.

> What features/programs are available in Red Hat but not in other Linux
> Distributions because these are proprietary to Red Hat?

What do you mean by 'proprietary' here?

If you mean 'Red Hat's own proprietary code that's not GPL or similar public
license', then there is no such thing.  Everything that Red Hat puts in RHEL
is GPL or similar OSI-approved open source license [2].

Here we steer into complicated legal territory.  As I understand it, the GPL
does not actually require Red Hat to release the source code to everyone -
only the people to whom it distributes its software.  The fact that it does
make all its updates available, via places like
ftp://ftp.redhat.com/pub/redhat/ and in upstream projects, is Red Hat trying
to be a good community player.

If you mean 'things which Red Hat contributes but to which I don't have
access, as I'm not paying for a subscription to Red Hat's products', then see
the point above.  There was a bit of a furore a while ago about Red Hat
contributing its kernel patches in one big lump in its source RPMs, rather
than nicely identified and separated patches.  That's because one of Red Hat's
competitors has a habit of taking Red Hat's work, rebranding it, and claiming
it as its own.  Red Hat still contributes its work upstream, so if you want to
track the GNU/Linux kernel git repository then you can probably pull the
patches apart from there.  The source in the RPMs might not be in the shape
everyone else likes to see it in, but the source code is all there, so Red
Hat's contribution to the GNU/Linux kernel is still GPL compliant.

I guess many people view this as somehow a corruption of the 'principles' of
Open Source.  But as I said above, I think the problem is that there's a
perception that somehow "Free" must also mean "not making any money at all".
I think Red Hat is showing that it's possible to keep to the principles and
make money, but obviously some people disagree on that.

If you mean 'Red Hat is also working on products that are not FOSS that it
uses internally', then there are three answers to that.  One is to look at Red
Hat's long history of buying projects and open sourcing them.  Another is that
this is also (see the legal note above) not a conflict with the GPL.  The
third is that since almost all software companies work on their own code
internally without publishing it to the world, I don't see Red Hat as being in
any way exceptional.  Even amongst companies that make FOSS products this is
not exceptional.

If I've missed your definition of 'proprietary' as it applies to whatever
features you're thinking of in Red Hat's products, then let me know.

> Is there a chance that Red Hat will become a different Linux which
> will not be compatible with other Linux distributions due to being
> more proprietary than OpenSource?

Put simply, I believe not, but I think (to quote Charles Babbage) "I am not
able rightly to apprehend the kind of confusion of ideas that could provoke
such a question."

What do you mean by 'compatible'?  You can't install Debian APT packages on
RHEL (Red Hat Enterprise Linux), so that's incompatible.  But you can install
RPM packages from the EPEL repository that also install on CEntOS (and come
from Fedora), so that's compatible.  Companies (like nVidia, SAP, Microsoft,
AutoCAD and others) make proprietary software that installs via RPM packages
on RHEL, but that doesn't make RHEL proprietary.  As Hal's observed, all the
packages that you get in RHEL are all available as source RPMs from which you
can get the raw source code or compile in your own way, should you choose -
but at that point they cease to be Red Hat's concern.

There's nothing inherent in the code that requires a specific license to run
on Linux.  This is a good thing!  This means you can work on your own projects
without having to declare them FOSS or sign them with some trusted external
company.  The FOSS community cares about what license things are using -
witness the number of distributions that don't package the nVidia proprietary
video drivers because they don't have an open license.

But I think your question is predicated on the idea that Red Hat's many many
products are in any way proprietary, which is (to the best of my knowledge) false.

> What is the history of KVM?  I believe that Red Hat has provided this
> technology to OpenSource (FOSS?). Yesterday using Virt-Manager I tried
> to migrate a VM from CentOS to Debian and also from Debian to CentOS,
> but due to differences in environments I was not able to. This may
> only be differences in folder layouts, but are there larger
> differences?

No idea.  I seem to recall that KVM came from another company that Red Hat
bought and opened, but I don't recall the specifics and can't be bothered
doing the research - that's left as an exercise for the reader :-)

> I realise that drivers for hardware that are provided by the hardware
> manufactures, are mostly not OpenSource and are proprietary, but what
> about Red Hat's proprietary code? Where does this sit?  

What 'proprietary' code is that?

Red Hat Enterprise Linux is not supplied with any proprietary hardware drivers[2].

> Can Red Hat code be 100% compiled from source? (excepting for hardware
> driver specific code).

As Hal said, people already do take all the Red Hat source RPMs, remove all
the Red Hat branding, put their own branding on it (e.g. CEntOS) and publish
it.  So the answer is yes.

[2] Red Hat and other GNU/Linux distributions package some Intel and AMD
processor microcode updates.  Those are proprietary, but since they affect
only the environment of the CPU itself and don't affect the operating system,
FOSS people generally tend to package them as is.  If you don't want them,
don't install them, and your computer will run pretty much the same.  To my
knowledge that's the extent of non-FOSS software in Red Hat's products.  Feel
free to correct me if you can find examples otherwise.

I'm obviously biased here, but what I see is that Red Hat is trying its
hardest to be open and to work with the community of Free Open Source Software
developers and people.  It's never going to be perfect because of the business
vs community tensions I talked about above.  But I think that, like Debian,
like Fedora, like any number of other open source projects, they do the best
they can to contribute to everyone's success.

Hope this helps,


More information about the linux mailing list