Why Free Software\'s long run TCO must be lower

By   |  March 17, 2003


This paper was kindly contributed by Brendan Scott. It is published here in full and unedited. The views expressed are those of the author an not necessarily of Tectonic.co.za and it staff

Why Free Software\’s Long Run
TCO must be lower

Brendan Scott

15 July 2002

Brendan is a lawyer specialising in IT and telecommunications
law.

Brendan\’s email address is brendanscott@optusnet.com.au.

The original article was posted at
http://www.members.optushome.com.au/brendanscott/papers/freesoftwaretco150702.html

Updated on 16 July
2002.

Abstract

This paper argues that the long run total
cost of operations (TCO) for a suite of proprietary software must
necessarily be greater than that for an equivalent suite of free software,
with the TCO benefits maximised in the case of the GPL and GPL-like free
software. The total cost of operation of a suite of free software is the
price determined by a competitive market for a bundle of goods and services
associated with that suite. Because the source code is open and not subject
to limitations on development or distribution, the market for services
relating to that code will be perfectly competitive. A rational vendor
will use a proprietary route for a program only where releasing that program
in that way will allow them to increase their profit above that which would
be returned to them by the operation of a competitive market. This result
should be hardly surprising, given that the express objective of copyright
law is to mandate a market failure and permit software creators to extract
above market rents as an incentive for the creation of that software.

Customers attempting to evaluate a free software
v proprietary solution can confine their investigation to an evaluation
of the ability of the packages to meet the customer\’s needs, and may presume
that the long run TCO will favor the free software package. Further, because
the licensing costs are additional dead weight costs, a customer ought
to also prefer a free software solution with functionality shortfalls where
those shortfalls can be overcome for less than the licensing cost for the
proprietary solution.

    1. Definitions

    Within this paper we make use of two key terms – free software and proprietary
    software. The \”free\” in the term free software is the \”free as in \’speech\’
    not the free as in \’beer\’\”1
    (although the \”free beer\” meaning is often also relevant). As we will see,
    another non-beer meaning of \”free\” in this context is \”\’free\’ as in \’market\’
    not free as in \”beer\’\”. There are two key definitions in this area – a
    relatively loose one of free software (available from http://www.gnu.org/philosophy/free-sw.html)
    developed by the Free Software Foundation definition and another of the
    similar (but more comprehensively set out) concept of open source developed
    by the Open Source Initiative www.opensource.org/ (available from
    www.opensource.org/docs/definition.html). The key characteristics of these
    definitions are that that software is freely distributable, that the source
    code must accompany the distributions and that everyone is permitted to
    modify and distribute modifications of that code on the terms of that license.
    Free software licenses do not require distribution of the modified code.
    However if it is distributed, the source code must accompany it. The final
    characteristic is the requirement as to the license which must be used
    if modifications are distributed. In the bare Open Source Initiative definition,
    the license must allow modifications to be distributed on the basis
    of the original license, but does not require it. Contrast this
    with the GNU GPL (the main free software license endorsed by the Free Software
    Foundation) which requires that if redistribution occurs, that redistribution
    must be on the terms of the GPL. As we will see later, the GPL gives stronger
    total cost of operations results than other free software licenses because
    of its requirement to impose the GPL for any modifications which are distributed.
    We therefore draw a distinction between \”GPL free software\” (that is, free
    software, such as, but not only, the GPL which impose free software licensing
    requirements on distributions) and non-GPL free software.

    A definition of proprietary software is harder to arrive
    at. Indeed, it is better to identify by reference to the level of control
    over the source code for the software which is asserted by its author.
    In effect, proprietary software is software which is not free software.
    The conclusions in this paper rely on the assumption that there is sufficient
    market power held by the person controlling the software so as to be able
    to extract above market rents. As a general rule this power is founded
    on the legislative monopoly of copyright. There may be instances where
    that power is exercisable through other means (such as patents, lack of
    interoperability and network externalities). However, for convenience in
    this paper we will assume that copyright is its source.

    The fact that no license fee is charged for a given application
    - as is often the case with internet desktop browsers for example, does
    not, by itself, make it free software. This is because there is no access
    provided to the source code. As the customer has no access to the source
    code, it would still be proprietary software. Indeed, even where the software
    is provided for free in conjunction with access to the source code for
    that software, the software is proprietary software if access to the source
    code is provided subject to restrictions on the ability to modify or distribute
    that code. For example, software under Microsoft\’s \”Shared Source\” program
    nevertheless remains proprietary software.

    2. TCO vs TCnO?

    TCO is often referred to as the total cost of \”ownership\”
    rather than of operations, as used in this paper. It has traditionally
    been used as a means of measuring the impact of certain strategies on a
    business. A canonical example is that of deciding whether to buy a cheap
    printer which requires expensive proprietary consumables. While the cost
    of acquiring the printer can be significantly lower than that of acquiring
    a competing printer, its cost to use may in fact be much higher because
    of the need to pay higher prices for consumables going forward. In order
    to address this difficulty a manager can cost a given printer by taking
    the buy price of the printer and adding the total cost to make all of the
    prints it is expected to make during its lifetime. Other factors may also
    be added, such as the cost of its maintenance or an apportionment of the
    salaries for people employed to administer the printer over its lifetime.
    Thus managers can arrive at a single figure which better reflects the real
    cost of a printer\’s acquisition than its mere buy price. This gives managers
    an objective basis on which to make comparisons of different printers against
    a common metric and thus aids decisions about printer purchasing.

    Now, while ownership is a concept making perfect sense
    in the context of printers it is rather more problematic in relation to
    software. In relation to neither free software nor proprietary software
    does a user acquire \”ownership\” per se of the software in question. That
    said, the term \”ownership\” does describe the rights of a user of free software
    relatively well – the main right of \”ownership\” that a free software user
    does not enjoy is the right to exclude others from the use of the software
    and to prevent modification to or distribution of that software.

    On the other hand, user \”ownership\” of software as a concept
    is anathema to proprietary software, the fundamental assumptions of which
    revolve around ownership of the software by the vendor. It is therefore
    odd to discuss the total cost of \”ownership\” in relation to, for example,
    a copy of the Windows 95 operating system because users have no such ownership.
    The user will, at best, have some form of (often extremely restrictive)
    license. Indeed, some might argue that a significant (and often uncosted)
    component of the cost of \”ownership\” of proprietary software is that users
    don\’t own it at all.

    Ironically, the additional expenses incurred in relation
    to proprietary software are actually costs which arise from a purchaser\’s
    failure to own the software in question. As we will see, they are largely
    costs of non-ownership. Main among those costs of non-ownership
    are the monopoly rents that non ownership allows vendors to extract over
    and above the price that would be determined by the market. Free software
    vendors may object that the adoption of an existing acronym (TCO) which
    obscures the existence of these costs of non-ownership implicitly aids
    proprietary software vendors. However, for the purposes of convenience,
    we retain the acronym TCO in this paper. We use it to mean the total cost
    of acquiring and operating a given suite of software over its lifetime,
    rather than of \”owning\” that suite.

    3. The Business Model for Proprietary
    Software

    The cornerstone of proprietary software is the grant of
    monopolies by the legislature to private individuals. These monopolies,
    most commonly effected through copyright legislation, take rights (notably
    the right to copy) away from citizens generally and vest them in the monopoly
    holder for a given work.

    Originally, the reason for this was to ensure that the
    State in Stuart and Tudor England could censor the publications of all
    private individuals (it is no coincidence that free software principles
    are strongly related to free speech principles). The State granted a monopoly
    right over printing to the Stationers\’ Company in return for the Stationer\’s
    Company acting as the State\’s censors. This had the side effect of creating
    vastly profitable publishing enterprises for the printers who administered
    this censorship. With the Glorious Revolution in England in the late 1600s,
    the State sought to reconcile the various political bodies within England
    at the time and, as part of that reconciliation (indeed, one of parliament\’s
    conditions for permitting William and Mary to ascend the throne) was a
    relaxation of the laws in relation to censorship. Around this time saw
    the emergence of a different justification for the granting of these private
    monopolies (the beneficiaries in practice of these monopolies remained
    unchanged). This new theory was expressed in the economic concepts of incentives
    and protection from competition.

    The theory is, effectively, this: that the act of printing
    costs nothing, or next to nothing, however the act of creating a literary
    work requires substantial effort. If other printers (at the time it was
    printers from Scotland threatening to compete with English printers as
    a result of political union in the early 1700s) are able to print and distribute
    copies of a work without restriction, then they will be able to undercut
    a printer who invests their time and money in creating a market for that
    work. This would mean that there is no incentive to make such an investment.
    Ultimately, it would mean a decline in the production of literary works.
    In other words, the unregulated operation of the market will render the
    printing business non-viable. This is undesirable, therefore the printing
    business ought to be protected and the most appropriate form of protection
    is the grant of private monopolies to prevent this form of free riding.
    Thus the State has a role in protecting printers from competition. This
    allows them to extract rents above what the operation of a free market
    would return to them. This has the socially desirable goal of promoting
    the printing business and, through it, gives an incentive to \”learned men\”
    to create \”useful works\” (to borrow the wording from the Statute of
    Anne 1709
    , the first copyright statute).

    This theory has remained largely unchanged since the early
    1700s. When implemented in the copyright clause in the Constitution it
    was modified to say that the right vests in authors, rather than printers,
    although the fact that these rights can be sold has led, in practice, to
    their being held and exercised by printers and publishers (the software
    industry is no exception in this regard, with most copyright in commercially
    marketed software vested in companies rather than individuals). However,
    the copyright clause still clearly states that copyright is only a means
    to an end. The object expressed in the Constitution is that the monopolies
    are granted for the \”progress\” of \”science\” and the \”useful arts\”.

    In practice, the copyright legislation creates a framework
    to permit the conversion of services (computer programming) into products
    (the software created from that programming). The theory is that this conversion
    encourages investment in such programming by allowing the investment to
    be amortized over the sale of each copy of the ultimate product. Arguably,
    in the absence of such legislation, the creator of a work would need to
    recoup their investment and make a profit during their lead time to market
    before others begin distributing copies of their work at much lower prices
    (others can sell at lower prices as they are not carrying the cost of development,
    only of distribution).

    To summarize, therefore:

    (a) A creator of software is unlikely
    to bother to develop their programs if they are not protected from free
    competition in the market.

    (b) The State protects potential
    creators from competition as a means of encouraging the production of software.

    (c) The State grants this protection
    through taking rights away from the balance of the population and vesting
    them in the author of the program by way of monopoly.

    (d) The State, in doing so, is
    attempting to balance the interests of authors against the interests of
    consumers and achieve socially desirable goals (in this case, increased
    production of software).

    In short, the State regulates the market and legislatively
    mandates the failure of the market in order to promote the creation of
    software.

    4. The Free Software Business Model

    If proprietary software is an example of mandated market
    failure, free software is the market\’s response to that failure. In some
    respects the free software movement can be regarded as the market self
    correcting for the market failure mandated by Congress. The free software
    business model leverages off two key characteristics of software – that
    it is both non-rival (use by A does not inhibit use by B) and durable (in
    theory software does not wear out) – to ensure its creation through the
    aggregation of a number of individual small contributions. To quote another
    analogy in this area – each person contributes a brick, but ultimately
    each person receives a house in return. As software is nonrival it is possible
    for each person to take the full benefit of the whole. Further, as it is
    durable, substantial value can be aggregated from minor contributions over
    a long period. It is as if everyone receives a full house when they have
    only contributed a brick.

    Early free software modes did not include obligations
    in respect of the redistribution of modified code. This led to some of
    the software produced under this model being incorporated into commercial
    products. Contributors contributed their brick, but didn\’t get a house
    back. As the development model for free software is an incremental and
    community oriented one, this incorporation into commercial products acted
    as a disincentive to participation. Contributors contribute their brick
    in the expectation that, in the long term, a mansion will be returned to
    them (as the result of aggregation of individual contributions). If contributors
    expect to be required to reacquire modifications of their own code they
    are helping to create a mansion for someone else. They effectively make
    an investment (denominated in code) but receive no return on that investment.
    The requirement that modified code be returned as free software is therefore
    an important incentive in the creation of free software. That said, what
    is the most appropriate approach to free software is a philosophically
    contentious one and subject to much debate within the free software community.

    In the proprietary model, the incentive to create software
    arises from creators seeking to act as vendors of code. It is very much
    a vendor centric model. Free software on the other hand is a customer centric
    model. In the free software model, the assumption is made that necessity
    forces customers to create code for themselves (that is, development of
    free software is driven by the use value of the software). Free software
    provides a resource to assist that creation on the condition that any software
    which results from the use of that resource which is also distributed must
    be contributed back to the resource for others to use. The incentive to
    create code is different for different players in the market – a hardware
    vendor might promote the creation of free software code in order to bundle
    software with their hardware, thereby increasing the value of their hardware
    (known as \”widget frosting\”). End users create code in order to fulfill
    their own needs. An independent programmer might code to create a market
    for consulting or maintenance services. To extend the analogy introduced
    earlier, that there is a house returned does not mean that everyone who
    contributed to it did so to live in that house.

    One of the argued benefits of the proprietary software
    mode is that it allows \”big bang\” developments to occur. It may be that
    there is a market for mature software with specific functionality, but
    no market for immature software. Without a plan no one will contribute
    bricks. In this environment incremental development championed by the free
    software paradigm may not be appropriate as there is no critical mass to
    kick start the development. So how does free software arise?

    Experience shows that free software is primarily seeded
    through two pathways – which we will refer to in this paper as \”strict
    free software seeding\” and \”repurposing\”. Under strict free software seeding
    a program emerges in an organic manner from nothing other the support of
    the customer community. Many individual programmers each have an \”itch
    to scratch\” and their communal scratching produces a valuable result. The
    Linux kernel, the gcc compiler, the GIMP (image manipulation – a free version
    of Photoshop), and Apache (the most popular web server in the world) and
    text formatting programs like TeX are examples. However, there are significant
    free software applications, including Open Office (an office suite), and
    Netscape/Mozilla (browser/email client) which have been seeded from a different
    pathway. These programs are the remnants of commercial ventures which have
    been beaten in the marketplace, were repurposed by their makers as free
    software then adopted and perfected by the application of the free software
    method.

    Their creators, sensing their inability to successfully
    take the software to market, released the kernel of each of these projects
    as free software. While these owners are entitled to claim some level of
    altruism, their actions are a standard marketplace response to competitive
    threats. In particular, identify those product lines where your competitor
    is extracting the most premium and spoil that market2.
    For example, by releasing cheap products into that market to make it impossible
    for anyone to profit in those areas. This permits the competitor to convert
    a previous market for value added products from which they could not make
    profit into a market for commodity products from which no one can extract
    profit (\”if I can\’t have it, then nobody can\”), thereby shifting the basis
    of competition to a different market (and one less favorable to the current
    incumbent). This increases their competitiveness while decreasing that
    of the market incumbent. Thus, Sun and IBM, who otherwise have no prospect
    of gaining market share on in desktop systems or applications have become
    significant contributors to initiatives such as Java and GNU/Linux, thereby
    opening up markets for themselves in service, support, training and consultancy
    which were previously closed to them. This behavior is exactly what is
    expected of a rational economic actor. While there are elements of it in
    non-software markets, its progress in the area of software has been more
    marked because software is non-rival and durable as mentioned above. It
    has minimal transport and holding costs, and minimal deconstruction costs
    to extract valuable elements. The long term play for a free software contributor
    is effective code ownership (except, as we noted above, for the right to
    exclude others). Free software also invokes the market to solve difficult
    problems relating to the efficiency of resource allocation. Inefficient
    development resources – that is programs for which there is insufficient
    demand – are bred out of the code base by lack of support from the user
    community. Indeed such projects are likely to die in vitro. This
    is in contrast with proprietary software which will continue to be funded
    until the venture capital backing it has been consumed. Conversely, successful
    software is self selected – code will not mature if there are no users
    willing to adopt and support it. If there exists a mature free software
    program performing certain functions it is almost a necessary consequence
    that there is a market for that software.

    5. Components of TCO to be considered

    A July 2001 MITRE Corporation report3
    lists the cost elements to be considered when considering a software business
    case. Table 5 of that report lists those elements as:

    A Direct Costs

    1. Software and Hardware

    1.1 Software


    (a) Purchase price


    (b) Upgrades and additions


    (c) Intellectual property/licensing fees

    1.2 Hardware


    (a) Purchase price


    (b) Upgrades and additions

    2. Support Costs

    2.1 Internal


    (a) Installation and set-up


    (b) Maintenance


    (c) Troubleshooting


    (d) Support tools (e.g., books, publications)

    2.2 External


    (a) Installation and set-up


    (b) Maintenance


    (c) Troubleshooting

    3. Staffing Costs

    3.1 Project
    management

    3.2 Systems
    engineering/development

    3.3 Systems
    administration


    (a) Vendor management

    3.4 Other administration


    (a) Purchasing


    (b) Other

    3.5 Training

    4. De-installation and Disposal

    B. Indirect Costs

    1. Support Costs

    1.1 Peer support

    1.2 Casual
    learning

    1.3 Formal
    training

    1.4 Application
    development

    1.5 Futz factor

    2. Downtime

    To this list there are also other indirect costs arising
    from the use of proprietary software which are related to administration
    of licensing requirements. These include the tracking of software usage
    (costs of creating and administering procedures and of acquiring software)
    and, in some cases, conducting software audits. This list does not appear
    to anticipate switching costs where a business is moving from one system
    to another (although these can be accounted for indirectly through headings
    such as \”installation and set up\” or \”training\”).

    6. Analysis of Markets

    To the extent that there is demand for any of these elements,
    a market will emerge to satisfy that demand. This is true of both free
    software and proprietary software. The long term price in the market will
    be determined by a number of factors, revolving around the degree to which
    competition is available in that market. In any given market each means
    of excluding competition available to the seller of free software is also
    available to the seller of proprietary software. In addition the seller
    of proprietary software has additional exclusions that they can apply -
    in particular the exercise of their State sanctioned monopoly over distribution
    and modification. The lowest cost to customers will arise where competition
    is maximized. Therefore as additional exclusionary mechanisms are used
    by the seller of proprietary software in relation to one of these markets
    so the cost to customers to make acquisitions in that market will rise.
    If the seller was not able to extract these above market rents by relying
    on these exclusionary mechanisms, the seller would not release the software
    as proprietary software.

    The long run price in any of these given markets, (in
    the absence of cross subsidy), can therefore be broken into two components
    - the competitive market price for those services plus an additional monopoly
    premium that can be extracted. In the case of free software the competition
    in each market is at its highest, so the long run monopoly premium is zero.
    Because the long run monopoly premium in the case of proprietary software
    must be greater than zero, in any of these markets the long run TCO of
    proprietary software must be greater than that of equivalent free software.
    This result should hardly be surprising. It is, after all, the express
    purpose of the copyright legislation.

6.1 Transient Effects

The discussion above has deliberately confined
itself to long run costs. It is easy to construct short run examples where
this TCO result is reversed. For example, many contemporary analyses of
business case costs take a snapshot approach. That is, they take empirical
observations as to the state of any one of these markets and aggregate
calculated costs which result from those observations. While this information
is of value to managers needing to make short term decisions it is inadequate
for strategic planning purposes, which may need to anticipate a lifetime
for a technology platform in excess of five or seven years. For example,
as at the date of this paper, operating systems such as Windows and the
Macintosh OS have been mature systems for several years and, in that time,
a number of ancillary services have emerged to complement each of them.
Their free software equivalent, Linux, has not enjoyed the same period
of maturity and has therefore not had the same period of time to refine
efficiencies in business processes supporting each of these markets. It
should not be surprising therefore to expect free software markets to produce
higher costs for a given category based on current circumstances using
this form of analysis if a sufficiently short enough evaluation window
is manufactured for the purposes of the study.

6.2 Monopolies in particular
submarkets

The argument can be applied equally where the anti-competitive
effect of release of code as proprietary software is limited to only a
few of the mentioned submarkets. In those submarkets where it is unable
to affect competition in the market, the price set will be the same as

the free software market price for that component. Of course, in relation
to the balance, the aggregate price for those components must exceed that
of the free software market for those components.

However, in the long term, when the costs across
each of these separate submarkets are aggregated, the cost of free software

in an open market must be less than that of equivalent proprietary software.
While proprietary software may loss leader in some submarkets in order
to leverage greater returns in others, overall this leverage must be profitable
for the company selling proprietary software – if it wasn\’t the vendor
would not engage in the practice. A vendor will not rely on the copyright
path to ensure returns below that which could be returned to them by the
market. Release of code as proprietary software will only occur where such
a release can increase the vendor\’s returns in aggregate.

6.3 Examples of monopoly
premiums

These increased returns express themselves in
rents through a number of pathways. For example, the monopoly over modifications
to software protects a vendor from competition in relation to both their
time to implement modifications and their cost to implement those modifications.
It may also use this monopoly to leverage into ancillary submarkets such
as training, documentation or maintenance. Thus an operating system monopoly
could be used to leverage into specific submarkets for applications running
on that operating system, especially where the operating system (whether
by design or oversight) is or becomes incompatible with competitors\’ applications
in that submarket.

Further, each of these costs can be compounded
by the exclusionary effect of proprietary software. Thus, because proprietary
software does not allow reuse of source by other programs, the skills that
individuals gain through developing or supporting proprietary software
are less portable. This lack of portability leads to a greater training
premium when developing or supporting other software, again pushing up
development and support costs. It also leads to replication of effort.
Thus where a programmer developing free software has seen a module to perform
a specified function before, they can locate the existing version of that
module and incorporate it into their current development. However, in the
proprietary software world they must recreate that module from scratch
- technically not relying on their knowledge of the existing module (to
avoid it being a derivative work) – greatly increasing the development
costs through repeated reinvention. File formats are a good example of
this phenomenon. As vendors of proprietary software are unable to use code
for other proprietary software\’s file formats, they are practically required
to create their own custom versions (some argue that proprietary formats
are also used as an anti-competitive tool) or reverse engineer the proprietary
format. This translates directly into increased prices to the customer
(they must not only pay for the added function provided by the third party
provider in relation to files in that format, but also for their reverse
engineering costs involved in accessing the format). This in turn increases
the minimum to play for any would be entrant into the market, increasing
barriers to entry and consequently reducing competition.

6.4 Cross subsidies from
external markets

This analysis is not strictly valid where one
or more of the mentioned submarkets is subject to subsidies from an external
market. That is, a market other than one of the mentioned submarkets. This
means that customers in that market are paying more in order that customers
in the subsidized market can pay less. However, given that we are concerned
with long run costs, it is open to question how long such a subsidy can
continue in the face of competition in that external market. Further, large
customers, such as government, are more likely to be acquiring in that
external market so would not be quarantined from the increased costs.

6.5 Reliance on Functional
equivalence

The key assumption in this analysis is that the free software
suite is functionally equivalent to the proprietary suite and that there
is sufficient demand for that suite (although we suspect in practice that
this is implied by the first). Functional equivalence in this context does
not mean that the functional characteristics of both suites are the same.
Rather, it means that each of the suites can meet the functional requirements
of the customer. Thus, two suites might meet the customer\’s requirements,
and one might have additional functionality, but it is additional functionality
which is irrelevant to the customer. This surplus functionality is not
taken into account by this analysis. As we noted above free software is
self selecting, so the existence of a market for that software might be
implied from the existence of a free software equivalent.

6.6 Indirect costs

The analysis above assumes that for each of the cost components, money
is the driver for the development of the market. However, in the case of
some of the indirect costs listed, this is not the case. For example, peer
support is something which is decoupled from pricing mechanisms in the
other markets, even though it may have an effect on the cost base4.
There is no reason to suspect that these indirect costs will favor one
method or another in the long term. Intuitively one would expect that the
greater openness permitted by free software will reduce costs in the peer
support category. There is also the counterintuitive result that, in the
short term, lack of applications running on a particular free software
platform can actually yield cost benefits through futz factor savings.
As diversionary applications are simply not available, time lost using
them is equally reduced.

Switching costs seem to be a class of cost which is immune to a market
analysis. Effectively an organization which has an existing proprietary
solution must write off the time investment in that software when moving
to a free software equivalent. It is not clear the extent to which this
is a real cost in the general case. For example, there is no reason a
priori
why free software can not provide a seamless transition path
from equivalent proprietary software. However, experience to date indicates
that these costs are non trivial. Nor is it clear that that investment
would not have to be written off in any event. With each new release of
software, users are required to retrain.

7. The Unreasonable Effectiveness
of the GPL in TCO.

7.1 Strong and weak results

A deeper analysis reveals that the argument in relation to
markets is at its strongest where development forks or versions in the
code must themselves remain free software. If a fork is permitted to go
proprietary, then that fork will lead to a higher TCO along the lines of
the argument above. Except to the extent a fork actually increases the
number of consumers for the suite it must cannibalize some of the existing
free software consumers, reducing demand. As demand decreases free software
suppliers may leave the market, reducing competition and consequently increasing
prices. In the extreme case a proprietary software vendor may engage in
predatory pricing (for example by providing free support or maintenance
services) to destroy the markets supporting the free software forks with
a view to cornering those markets and subsequently extracting monopoly
rents. In any case, where proprietary forks are permitted, the TCO result
will be suboptimal5.
Conversely proprietary suites which have free software forks will have
a lower TCO than purely proprietary ones because customers can leverage
off the more efficient markets of the free software forks.

As this paper is concerned with long run TCO, the result in
relation to licenses which do not require the use of a free software license
in the event of distribution of modifications must be taken with some degree
of caution. The GNU GPL is a well known example of a free software license
which requires the use of the GPL when (and if) redistributing modifications
to GPLed free software. On the analysis above there is actually a spectrum
of results:

(a)
Proprietary software provides the worst option (from the point of view
of long run TCO) because it minimizes competition, consequently maximizing
long run TCO. Again, we note that this result is primarily due to the fact
that the legislative monopoly granted over software is specifically designed
to increase the return of the vendors of proprietary software in order
to create an incentive for the creation of that software. In short, the
legislature distorts the market for the purpose of protecting the proprietary
software industry.

(b) Non-GPL free software which permits proprietary
forking may or may not result in lower TCO in the long run. Whether it
does or does not depends on the net effect of proprietary forking on demand
in the relevant submarkets. At one end of the scale no proprietary forking
in fact occurs and the result is the same as for GPLed free software. At
the other end of the scale a proprietary fork can cannibalize the entirety
of each market for the suite, resulting in a long run TCO equal to proprietary
software (subject perhaps to a discount for the period in which it remains
free software). It is conceivable that the long run TCO may actually be
as high for non-GPL free software as for the most expensive proprietary
software (in the event that a proprietary software vendor follows predatory
pricing with price gouging subsequent to the diminution of competition).
The likely outcome is something in the middle, with proprietary forks reducing
demand somewhat but not entirely. We refer to this as the \”weak TCO result\”.

(c)
GPL free software maximizes demand in markets by excluding market capture
by proprietary forks. These licenses therefore maximize competition in
the long run, and consequently result in the lowest TCO in the long run.
We refer to this as the \”strong TCO result\”.

7.2 Dangers of source code
\”sharing\”

Source code sharing arrangements where the source
code for proprietary software is made available but not on a free software
basis, are dangerous for users because of the viral nature of proprietary
software. What makes proprietary software so dangerous in this regard is
the privileged place accorded to it by copyright law. In the absence of
an agreement to the contrary, the monopoly rights in modifications carried
out by users after access to the source code will vest by default in the
vendor of the proprietary software, even where the terms of access to the
code are silent. Thus, the viral nature of proprietary software poses
a threat to the intellectual property of any organisation that has access
to shared source unless explicit (and often expensive) steps are taken.
This exclusion by stealth can be contrasted with, for example, the GPL,
in which the terms of use and redistribution are not only explicitly stated,
but that explicit statement must accompany each copy of the source code.

As this default monopoly vesting is hidden in
the copyright law and not necessarily explicitly made clear to users, the
unwary user could find access to shared source to be a poison pill. They
may end up in the position of creating modifications for free for a vendor
without taking the benefit of the work of other users performing similar
fixes. Indeed, they may not technically be permitted to use even their
own fixes. As such, the potential for damage that such access allows cannot
be understated.

This viral nature of proprietary software means
that, in order to safely access the source code to such software, a user
will require management oversight and nontrivial monitoring of that access.
Independent of the software provider\’s views on the confidentiality of
their source code, a user must either have (a) an agreement, preferably
in writing, which clearly and unambiguously permits that user (and, as
appropriate, their employees, agents and contractors) to make modifications
and to distribute those modifications; or (b) strict accessibility controls
in place to prevent access to or use of that source.

    8. Strategic implications for purchasers.

The lessons that potential purchasers should
take from this paper are:

      (a) The short term costs of proprietary systems may be lower than those
      of free software systems. However, free software systems hold the advantage
      over the long term;

      (b) while free software effectively provides code ownership,
      the main costs of adopting a proprietary software solution are actually
      costs of non-ownership;

      (c) These TCO advantages are both most pronounced and
      more certain for GPL free software licenses, which mandate free software
      license terms for the distribution of code modifications. Non-GPL free
      software poses a significant risk of proprietary forking in the future
      and therefore yields only a weak TCO result, although one likely to be
      better than that for proprietary software.

      (d) Source code sharing arrangements are no substitute
      for the code ownership provided by free software. The viral nature of proprietary
      software means that such sharing arrangements pose potentially serious
      risks to a user if not strictly managed.

      (e) Making purchasing decisions on a 1, 2 or even 3 year window will
      have the effect of locking a purchaser into higher total cost of operations
      over the longer term. Purchasers must \”bite the bullet\” if they want to
      maximize real long term savings and access them sooner. This will be particularly
      pronounced where major purchasers, such as government, delay entry into
      the free software market thereby inhibiting the development of ancillary
      markets for the support of free software;

      (f) Strategic decisions in relation to the choice between free software
      and proprietary software should come down to one of evaluation of fit to
      functional requirements, with long run total cost of operations presumed
      to favor the free software. Fit to functional requirements can include
      such things as network externalities. As between free software variants
      GPL free software should be preferred to minimize long run TCO.

      (g) Where there appears to be an ongoing market for the free software
      in question, the organization should consider whether any shortfall in
      functionality can be made good at a price equal to or less than the licensing
      costs of the equivalent proprietary suite. That said, without demand a
      free software solution is unlikely to have reached sufficient maturity
      to present as a viable alternative. Its mere presence can of itself be
      indicative of the existence of an ongoing market.

We note that these conclusions are independent of the fact
or amount of any license fees charged in relation to the proprietary software.
Of course, where these costs are substantial they will make a further contribution
to the TCO of the suite. Also, free software advocates argue that the lifecycle
of free software programs is much longer than of their proprietary equivalents.
If this is true, the need to replace a proprietary system more often will
also increase the TCO for the proprietary suite.

I welcome comments on and criticisms of this paper. I would like
to thank Karl O. Pinc for his comments on earlier drafts of this paper.

1Attributed
to Richard Stallman.

2
Some of the examples given in this paragraph are of the \”commodization
of complements\”. That is a business attempts to reduce the status of goods
and services which are complementary to its own to that of commodity. In
so doing they are able to increase the demand for their own goods or services.
3
Kenwood, C., A Business Case Study of Open Source Software, June
2001, www.mitre.org/support/papers/tech_papers_01/kenwood_software/index.shtml
4
Individuals who are able to resolve issues through peer support do not
place a strain on support resources. It is open to debate whether peer
support is a real cost saving if, for example, resources are actually being
drawn from other functions within the organisation – in this case a peer
support saving is simultaneously a futz factor cost.
5
At the risk of laboring the point, the theory behind such an increase is
that the higher TCO results from increased returns to software vendors
as an incentive for them to create software which would not otherwise be
created.

Comments

Comments are closed