The following is taken verbatim from Brendan Scott's original article (archive) under his DecencyWare™ License.
Lock in Software
by Brendan Scott
Introduction
In July last year the author wrote a paper which argued that the total cost of ownership of free software would, in the long run, always be lower than that of equivalent software created under different models. One of the problems we grappled with when writing that paper was how to name those different models. At the time we adopted a term which appeared to be used widely, that of “proprietary software”. We now believe our (and others') use of that term is not only inaccurate, but plain wrong and ought to be changed. In this paper we set out reasons and propose an alternative, more appropriate, term - “lock in software”. Other terms, including hostageware, are identified, but not adopted.
The State of Play
In the free software debate there appear to be three terms which set demarcation boundaries within the software pantheon. Those terms are “free software”, “open source software” and “proprietary software”. Of each of these the terms both “free software” and “open source software” have clear, defined meanings. However the term “proprietary software” seems to be defined by exclusion – it is commonly used to apply to software which isn't free and isn't open source. The concept of property stands on hallowed ground in most western political systems. By implication the terminology as currently used allows vendors threatened by market competition from free software to cloud the issues by painting their competitors as somehow being anti-property, and therefore evil.
“Proprietary software” does not exist ...
The primary reason that the use of “proprietary software” is inappropriate is that it is inaccurate. There is no property in software, and there never was (the Supreme Court reference, for those of you who are interested, is Wheaton v Peters 33 US 591 (1834), which held that there is no such thing as copyright in US common law). What there has been is a concerted effort by a number of vested interests over the past 20 years to characterise software production as uniquely in need of (non monetary) subsidies from government. The key means of achieving this has been the use of a rhetoric of property. Property is a concept which is well understood. A property analogy, if adopted and taken to its logical conclusion, means not only that such interests do not need to properly justify their call for subsidies, they can argue an entitlement to such subsidies as of right. In this respect they have been remarkably successful over the past 20 years, gaining non monetary subsidies and legislative largess other industries only dream of.
And even if it did
As we have just discussed, we do not concede in this paper that there is property in software. We believe the term “proprietary software” is an oxymoron. However, for the sake of the argument we will assume that it is meaningful to speak in terms of property or ownership in software deriving from the copyright monopoly. Even if we concede ownership it does not give rise to a meaningful distinction between free software and its non free counterparts. What it does do is create a distinction between software over which legislative rights are asserted and other (ie public domain) software. However there is no direct connection between free software and public domain software. Some free software is in the public domain, some public domain software is also free software.
What should be clear is that if software is subject to a license then any ownership in that software exists independent of the manner of licensing. In this respect (non public domain) free software is every bit as “proprietary” as software which is not free (and not in the public domain). It is “owned” by someone who licenses it on the terms of a free software license. To illustrate the point, let us take an example where property actually does exist - if I own a hammer that hammer remains my property if I license my neighbor to use that hammer. The terms of the license do not affect my property in the hammer. No one would say the hammer is more my property because I choose to license my neighbor for a fee, or if I license it to them on the basis that they (for example) don't use it on their kitchen or with any other tools not supplied by me (or on any manner of other anticompetitive terms). In the software world there seems to be the assumption that if someone profits out of the grant of a license then the software is more entitled to the use of the term “proprietary”. In the hammer example no one would contemplate calling my hammer a “proprietary hammer” simply because I choose to license its use for a fee or subject to restrictive terms. The only time the hammer would not be my property is when I renounced my ownership in it (the software equivalent would be putting the software into the public domain), not when I asserted my ownership, but permitted others to make use of the hammer (which is the case in all software licenses).
The same is, or ought to be, true for software. When a software package is created a person is vested by the legislature with a wide range of monopolies in relation to that package. These privileges vest regardless of whether or not any licenses are granted over that package and regardless of the terms of any such license subsequently granted. If a software package can be called proprietary prior to the grant of its first license it remains proprietary after that grant and irrespective of the terms of the license. Licensed free software is every bit as “proprietary” as licensed non free software in this respect. Licensed free software still has a specific person or persons in whom monopoly privileges vest in exactly the same way as does licensed software which is not free software. Indeed, licensed free software such as GPLed software would not be possible without that “property” (because the license terms would not be able to be enforced, being a license the GPL relies explicitly on monopolies granted by the copyright law). Unless and until such the rights over the software are renounced – that is, it is released into the public domain – it is every bit as “proprietary” as licensed software which is not free software. The complement of “proprietary” software is not “free software”. The complement of “proprietary” software is public domain software – software over which no one asserts any rights to control other people's use of the software.
In our view the key characteristic of software ought to be the terms on which it is licensed and the principal aims of those terms. Thus, to adopt the property analogy, GPL software is proprietary software licensed in a way aimed to maximize the freedom of its licensees. The fact that it maximises those freedoms does not make it any less “proprietary” software. Similarly all free software and open source software which is subject to license conditions is “proprietary” in this sense”. However, the balance of software is not “proprietary software”. Rather it is proprietary software licensed on terms more restrictive than free software.
What is the defining purpose of those licensing terms? While one of those purposes is often to make money as a result of the license this is not a purpose alien to free software, where one purpose may be to derive money from maintenance sold at the same time as the license grant. Nor is money making always an objective of software licensed on non-free software license terms – many vendors give away software which is not free software as updates or complements to their existing products. The defining characteristic of licenses which are not free software licenses is that they attempt to foreclose competition to a greater or lessor degree. Licensors of software which is licensed other than as free software do so in order to maintain control over not only the use and the further development of that software, but also over who is permitted to provide ancillary goods and services in relation to that software. Where a person chooses to license software on a basis other than as free software they do so with a dominant purpose of locking the end user into them (or their resellers, distributors and agents) for all their needs in relation to that software for the entirety of the effective life of that software.
We believe it is this characteristic which properly distinguishes free software from software licensed on other bases. It is for this reason we argue that the most appropriate term for software which is not licensed as free software is “lock in software” because it succinctly describes part of the quid pro quo of agreeing to the license terms. Further, lock in software can be given a sensible, if somewhat fuzzy definition – it is software the license terms of which tend to lock the user in to a vendor or otherwise create a legal dependency by the user on a vendor.
The analysis above also suggests other terms: hostageware, because the customer is held hostage to the vendor, anti-trust ware, because, in the absence of specific legislative exceptions these license terms would likely be illegal trusts; anti competitive ware or monopolyware because at their heart the purpose of the licensing terms is to promote or preserve a monopoly over the software. For one reason or another, we consider these alternatives to be inappropriate. No doubt the community will settle on an appropriate alternative to the incorrect “proprietary software” in time.
Free software proponents also use the term “non free software” and may argue this is a more appropriate, or more accurate term. In a similar vein open source proponents may argue for “closed source”. While we believe the terms “non free software” and “closed source” are both accurate and technically correct, the “non-free”/closed terminology fails to convey the key characteristic of non free software to decision makers who are unfamiliar with the free software philosophy and the reasons why software freedom is an issue, let alone an important one. It is on this basis that we believe lock in software is the better term to use, especially in material directed to a generalist audience.
We also note that the important element here is that the license terms create the lock in. If a user is beholden to a vendor for other reasons (such as that vendor's expertise or knowledge of that user's organisation) that lock in is not relevant for the purposes of determining whether software licensed by that vendor is lock in software.
Conclusion
In the first instance the term proprietary software is inaccurate to apply to software. The rhetoric of property is simply a political device (admittedly used to great effect) by rent seekers seeking government subsidies. However, even if used to mean that the legislative monopoly of copyright granted over software is some form of property then free software is equally as proprietary as any other software which is not in the public domain. The only non “proprietary software” would be software which has passed into the public domain. The main characteristic which distinguishes licensed software into software which is free software and software which is not free softwae is the whether or not the license terms seek to lock the user or customer in to a vendor. For this reason we believe the term “lock in software” should be used in preference to the term “proprietary software” when referring to licensed software which is not free software (and not in the public domain). It conveys more meaning to decision makers not conversant with free software's philosophy than does the terms “non free” and “closed source” software. Finally the use of “lock in software” in preference to “proprietary software” prevents its critics misrepresenting free software and its proponents as somehow anti property.
About the author
Brendan is a lawyer in Sydney specialising in communications and information technology law. As at March 2003, Brendan's home page is www.members.optusnet.com.au/brendanscott.
Note: I would like to thank David Wheeler for identifying and commenting on errors in an earlier draft of this paper.