[Gnu-arch-users] on RH, part 1

[Tom Lord]

I seem to have (understandably) given some people that I only like to 
rail indignently against RH -- that I don't recognize the value of
their contributions, the challenges of their business model, the
realities of capitalism, or the quality of their hackers.   There is a
sense that I am trying to apply an ethical analysis in a context where
it is inappropriate to do so.

I'd like to put that perception to rest and I've tried to do so by
collecting my thoughts in two parts.   Part 1 is a review of what I
think are the most serious ethical issues with RH's business model --
presented from what I hope is a balanced perspective.   Part 2 are
some thoughts _towards_ a better business model for RH et al.

-t

            Some Problems with RH's Current Business Model
            ----------------------------------------------

Let's start by looking at RHN and how it relates to the RH distro
products (WS, ES, AS).

For background, RHN (the "Red Hat Network") is:

   [....] an easy-to-use systems management platform for your Linux
   infrastructure. [....]

   * What does it do?

   Red Hat Network provides administrators with the tools to
   efficiently manage the systems on their network. [....]
   administrators can add enhanced capabilities for system updates,
   management, and provisioning of their entire infrastructure.

                -- http://www.redhat.com/software/rhn/


The various flavors of enterprise linux (WS, ES, AS) are, of course,
distributions.  Red Hat distinguishes them this way

    [....] It's sold by annual subscription, runs on seven system
    architectures, and is certified by top enterprise software and
    hardware vendors. It's backed by a Red Hat Network subscription
    [....]

                -- http://www.redhat.com/software/rhel/

So we have something here that's pretty simple, conceptually:

  ~ a release-managed distro, tested on various platforms, and
    officially supported by some ISVs of non-free software

  ~ for which the preferred form of management is to use 
    RHN

What's the catch?  There's a two-fold catch:

1) RHN is comprised of non-free software.

  The RHN software is protected by trade-secret laws.  Customers are
  provided with a right to install the RHN software on a limited
  number of machines; strictly limited in the number of copies they
  may make; are not permitted to make modifications; are not permitted
  to "reverse engineer" the software; are required to destroy copies
  in their possession at the end of the agreement.   Even when this
  software is installed on customer machines, RH asserts that those
  copies are the property of RH -- that, all appearences to the
  contrary, the software has not (for legal purposes) been distributed
  to the users.

  User's are restricted in their _use_ of RHN software.  In
  particular, they can not configure it to control more systems than
  they have paid RH for the right to manage.   RH reserves the right
  to inspect a customers site and records to ensure compliance.
  (See http://www.redhat.com/licenses/rhel_us_3.html?country=United+States&;) 

  There's a coherent business model reason for these legal
  restrictions, of course.  Absent them, it would be easy for
  customers to buy a single system subscription to Enterprise, obtain
  a copy of the RHN software, and control many machines from that
  single subscription.  (Not that it's all _that_ hard for a customer
  to do that anyway -- which is one of the problems I'll be exploring
  later.)  So long as such a customer limited his support requests to
  a scale appropriate to his single-subscription entitlements, he'd
  obtain a great deal of the value of a many-system subscription for
  the price of a single-system subscription.  With the savings, such a
  customer could likely buy all the support he needs from a third
  party and still come out ahead.

  At the same time, those of us who like the ideal of free software
  ought to notice that RHN is very far from free.  The aim of RHN is
  to have a distribution which, though it is comprised (apart from RHN
  software) of free software, is packaged in a form that makes users
  dependent on an extremely non-free tool.  While users are
  theoretically free to modify, copy, and redistribute the platform
  (apart from RHN itself), the form and legal structure of RHN
  strongly discourages them from doing so: it asks users to trade
  benefits they might otherwise receive from free software for access
  to the Red Hat Network.

  This divergence between the core ethical principles of free software
  and the RHN business model should raise a red flag for people,
  whether they giving prioritiy to ethics ("business is no excuse for
  non-free software") or giving priority to business pragmatics
  ("businesses based on non-free software are distinctly vulnerable to
  competitive attack").

  (There are people working on working around this problem.  One
  example can be found at http://www.nrh-up2date.org/ although I 
  wonder if its creation didn't involve a violation of the law:
  http://www.nrh-up2date.org/nrh-up2date.html)


2) The distributions, hence their certifications by ISVs, are not
   shared by the community.

  Red Hat courts non-free ISVs and seeks semi-exclusive certifications
  for a distribution which they produce privately.  While they more or
  less conform to the requirements of making source available, and
  even make it available to non-customers, they do not do so in an
  upstanding manner (see http://whiteboxlinux.org and
  http://whiteboxlinux.org/news.html) or in a form that ISVs
  recognize (the ISVs don't certify "a system built from such and such
  sources", as one might expect of a free software OS -- they certify
  whatever is supplied to paying customers of RH.)

  Here again, there is a coherent business strategy.   Semi-exclusive 
  ISV certification has value to customers relying on software from
  the certifying ISVs.   For example, a customer who already relies on
  Oracle but who wants now to move to commodity hardware and lower
  their platform costs is driven to Red Hat.

  But, again, there is a violation of ethical and pragmatic
  principles.  For many projects (the kernel, apache, GCC, Gnome,
  etc.) Red Hat is happy -- eager even -- to cooperate fully with the
  community.  They author and submit changes in the usual way.  In
  some cases, they contribute to helping maintain the projects as
  public projects to which anyone may contribute.  Red Hat doesn't
  insist on private control of these projects.  They recognize the
  gain that comes from running the projects in public.  But for the
  distributions themselves -- although there _are_ public distribution
  projects -- RH turns its back on the community.  Rather than sharing
  work and obtaining the efficiencies of free software processes --
  they make the gambit of doing work privately and in a form where
  nobody but them will get the chief benefits.

  That's not an ethical violation of the same sort as the non-freeness
  of the RHN software.  It's a behavior that is entirely permitted --
  indeed _protected_ -- by free software licenses.   There are even 
  areas of technology (say, a computer-chess competition) where such
  behavior would be expected as "part of the game".

  But it is ethically odd, at least, that in this one area of making
  and proving the quality of distributions -- an area in which there
  is demonstrable gain (Debian) from cooperation -- they turn their
  back on the community.   They _could_ have invested to help the
  larger community become more efficient at this task and put the
  matter behind all of us -- gone on to spend their labor resources on
  other tasks.   But they didn't: they elected instead to reinforce
  and exploit an inefficiency in the larger community. 

  And, once again, even if business pragmatics are your primary
  concern rather than theoretical ethics, the split here between what
  would be an unproblematic relation with the larger community and
  what they actually do should give pause: if there is a more
  efficient and more cooperative way for the larger community to
  produce the same result that RH produces privately, won't the market
  eventually find this optimization?

  Projects like http://whiteboxlinux.org, Debian, and UserLinux 
  suggest that the barrier RH has erected around their distribution
  will, inevitably fall.   The Fedora project may even indicate
  recognition of that by RH.


Examining these two elements of their business, RHN and Enterprise, we
see that the RH strategy towards customers is a pincer strategy:
customers are encouraged to continue to rely on non-free applications
from third-party ISVs.  That's one arm of the pincer.  In order to run
those applications, they must use a supported RH distribution,
deployed using the RHN software that excludes the customer from many
of the benefits of software freedom.  That's the other arm of the
pincer.  It's hard to reconcile that, in my opinion, with part of RH's
stated mission:

    That's why open source is inevitable. It returns control to the
    customer. The code is open and you can see it, change it, learn
    from it. Bugs are more quickly found and fixed. And when customers
    don't like how one vendor is serving them, they can choose another
    without overhauling their infrastructure. That means: No more
    arbitrary pricing. No more technology lock-in. No more monopolies.

                -- http://www.redhat.com/about/mission/opensource.html

And the RH strategy towards the free software community is
exploitative -- a kind of "Maxwell's Daemon" approach.  They are happy
to support community efforts (e.g., Gnome, GCC, the Linux Kernel)
which enhance their pincer strategy while, simultaneously, turning
their back on, competing against, and even rendering illegal free
software projects that undermine their pincer strategy (e.g., Debian
vs. Fedora, RHN vs. NRH.)


    The fundamental act of friendship among programmers is the sharing
    of programs; marketing arrangements now typically used essentially
    forbid programmers to treat others as friends. The purchaser of
    software must choose between friendship and obeying the
    law. Naturally, many decide that friendship is more important.

                        -- RMS, The Gnu Manifesto 


-t