[clug] RedHat OpenSource And Proprietary

[Craig Small]

Bit late to the piece but here is my take. The relationship between Red Hat
and Open Source is mixed, but I definitely believe the mix when you all add
it up, is a net positive.

There used to be some kernel modules that RHEL had that concerned some
people would cause some sort of "lock in", I've not heard of these in
recent memory so they may have been some historical problem.

Pretty much any package you get for Red Hat you can get elsewhere and
generally they are the same thing. Red Hat like all other distributions
have their own patches. Some of these make it into the upstream and some do
not. SuSE often does the same thing but often the delta for both is
upstream not accepting the patches (whether that makes the Red Hat flavour
of packages better or worse actually depends on the specific package and
patch and possibly even your use-case) though they seem to forget to send
them sometimes and I do believe it's a real accident.

Red Hat has been great for getting Open Source out into places that perhaps
would have never considered it. The whole "pay someone to yell at if it
breaks" scenario that departments and enterprises love. It might sound
trite but it is a real barrier for some places that they have solved.

For bug fixing, this is also a mixed scenario. All distributions triage
bugs and fix some themselves and send patches upstream. I find with my
packages that the Red Hat guys will often look into the bug and give a fix
(again, some good some bad). The biggest problem with Red Hat and bugs is
their bug tracker has a lot of hidden bugs. So if you report a bug to Red
Hat, you're probably not always going to get the upstream guys to be able
to look at it. This is a continual frustration with me. Contrast that with
Debian and it's Social Contract #3 and it's open BTS which shows pretty
much everything. That being said, Red Hat have people that may be able to
fix it anyhow.

On the packages I look after, Red Hat are definitely a major contributor. I
have to exclude Debian out of that list, because its kind of a fridge door
problem (the packages I, a Debian developer, look after always have Debian
contribution). SuSE would come next with their updates and then its "the
rest". If "individual contributor" was a vendor, then it's #1 with Red Hat
#2 and SuSE #3.

Operating Red Hat, the problem often comes around to people not realizing
there is an operational support cost. This to me is not Red Hat's fault,
its their operating model so its not exactly a hidden surprise but for
those places where they do the set and forget type setup (the ones probably
running a Windows XP somewhere everyone has used and forgotten about) this
can be a shock when things stop updating.

 - Craig

On Mon, Dec 12, 2016 at 9:00 PM George at Clug <Clug at goproject.info> wrote:

>     Paul,
>
> Thank you for an excellent explanation of Red Hat.
>
>
> George.
>
>
>
> At Monday, 12-12-2016 on 01:54 Paul Wayper wrote:
>
>
> 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
> http://gpl-violations.org.
>
> > 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,
>
> Paul
>
> --
> linux mailing list
> linux at lists.samba.org
> https://lists.samba.org/mailman/listinfo/linux
>
>
> --
> linux mailing list
> linux at lists.samba.org
> https://lists.samba.org/mailman/listinfo/linux
>
-- 
Craig Small (@smallsees)   http://dropbear.xyz/     csmall at : enc.com.au
Debian GNU/Linux           http://www.debian.org/   csmall at : debian.org
GPG fingerprint:        5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5