Why Free Software\'s long run TCO must be lower
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
TCO must be lower
15 July 2002
Brendan is a lawyer specialising in IT and telecommunications
Brendan\’s email address is firstname.lastname@example.org.
The original article was posted at
Updated on 16 July
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
- 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
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
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
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
(a) Purchase price
(b) Upgrades and additions
(c) Intellectual property/licensing fees
(a) Purchase price
(b) Upgrades and additions
2. Support Costs
(a) Installation and set-up
(d) Support tools (e.g., books, publications)
(a) Installation and set-up
3. Staffing Costs
(a) Vendor management
3.4 Other administration
4. De-installation and Disposal
B. Indirect Costs
1. Support Costs
1.1 Peer support
1.5 Futz factor
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
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
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
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
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
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
(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\”.
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
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,
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
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.
to Richard Stallman.
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.
Kenwood, C., A Business Case Study of Open Source Software, June
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.
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