Why Free Software's Long Run TCO must be lower

Brendan Scott

15 July 2002

[Papers subdirectory]
Brendan is a lawyer specialising in IT and telecommunications law.
Brendan's email address is brendanscott@optusnet.com.au.
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:
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.