Ethics Inf Technol (2011) 13:185–197 DOI 10.1007/s10676-010-9229-3

ORIGINAL PAPER

A bundle of software rights and duties David M. Douglas

Published online: 5 June 2010  Springer Science+Business Media B.V. 2010

Abstract Like the ownership of physical property, the issues computer software ownership raises can be understood as concerns over how various rights and duties over software are shared between owners and users. The powers of software owners are defined in software licenses, the legal agreements defining what users can and cannot do with a particular program. To help clarify how these licenses permit and restrict users’ actions, here I present a conceptual framework of software rights and duties that is inspired by the terms of various proprietary, open source, and free software licenses. To clarify the relationships defined by these rights and duties, this framework distinguishes between software creators (the original developer), custodians (those who can control its use), and users (those who utilise the software). I define the various rights and duties that can be shared between these parties and how these rights and duties relate to each other. I conclude with a brief example of how this framework can be used by defining the concepts of free software and copyleft in terms of rights and duties. Keywords Duties
Rights
Software licenses
Software ownership
Users
Free software
Copyleft

Introduction Owning physical property is often described as possessing a bundle of rights and duties describing the actions permissible with a particular object by the holder of those D. M. Douglas (&) School of History, Philosophy, Religion and Classics, University of Queensland, St. Lucia, Brisbane, QLD 4072, Australia e-mail: [email protected]

rights and duties.1 Breaking ownership down into distinct rights and duties allows for different conceptions of ownership to be compared and for the costs and benefits of granting or denying owners particular rights and duties to be identified.2 Since the rights and duties are concerned with people’s actions with an object rather than the object itself, there is no major difficulty in describing the ownership of intangibles, such as books, inventions, music, and computer software, as the possession of a bundle of rights and duties as well. The difference between physical and intangible objects mean that the particular rights and duties relevant to intangibles differ from those concerned with physical property. Software itself differs from other intangibles as it can perform work like an invention, but it is also written (and can be readable) like a book. Software use is also governed by legal agreements called software licenses.3 These differences require a unique set of rights and duties to capture all the particular features of software relevant to its ownership. The conceptual framework of rights and duties presented in this paper attempts to capture these features. This allows different software licenses (and conceptions of software ownership more generally) to be described using a common terminology. While this removes some of the technical and legal detail of such licenses, it allows different licenses and conceptions of software ownership to be compared with each other at a more general level. It also allows the particular kinds of action a particular license permits or denies users to be more clearly identified, particularly for those less familiar

1 2 3

Munzer (1990), p. 16. Honore´ (1968), pp. 112–113. Classen (2008), p. 11.

123

186

with the specifics of intellectual property law and legal agreements. This framework of software rights and duties has a number of influences. The first and strongest influence is the terms and conditions placed on software usage by various software licenses. Software licenses describe how the license author believes rights and duties should be distributed between themselves and users, making them an excellent source for identifying which aspects of software are perceived as being relevant to ownership.4 While the rights and duties described in this framework are more generalised than the particular rights and duties described in actual licenses, the specific rights and duties a particular license describes should be straightforward to categorise using this framework. Like any discussion of the rights and duties connected with ownership, this framework is influenced by A.M. Honore´’s description of the standard incidents of ownership and W. N. Hohfeld’s conception of rights and duties.5 Honore´ describes a group of rights and duties that compromises the liberal conception of ownership.6 As Honore´’s discussion is not concerned with intangible property the specific incidents of ownership must be modified to be more applicable to software. For example, Honore´’s conception of ownership is grounded by the right to possess, which allows the owner to exclude others from the owned object.7 For this to apply to software the owner would have to be able to exclude others from it. While this can be achieved by keeping the software on her own computer and not allowing anyone else to use it (making use of her right to possess the computer as her own physical property), software owners normally want others to be able to use their software. It is more accurate to consider possessing software equivalent to accessing it, as access allows one to utilise software in the same way that possession permits the use of physical property. (I elaborate on the right to access in the section on software rights and duties below.) This does not affect the value of Honore´’s work as a model to how software ownership can be examined. As the incidents of ownership describe the uses of property Honore´’s description of ownership rights are still relevant to any discussion of the rights and duties controlling software use. W.H. Hohfeld’s conception of legal rights is useful for classifying the relationship created between two parties by a particular right. Hohfeld describes eight fundamental 4

The practical details of how software licenses work is described in Classen (2008). A number of software licenses are described in depth (with an emphasis on free and open source licenses) in St. Laurent (2004). 5 Honore´ (1968) and Hohfeld (2001), pp. 11–31. 6 Honore´ (1968), p. 112. 7 Ibid., pp. 113–114.

123

D. M. Douglas

legal conceptions: rights (or claim rights), duties, privileges, no-rights, powers, liabilities, immunities, and disabilities.8 Each of these conceptions for one party corresponds to another for the other party. Each conception also has its opposite. If Alice has a claim right for Bob to do X, Bob has a duty to perform X for Alice. As Alice has this claim right she does not have a no-right for Bob to do X, as a no-right is the opposite of a claim right. If Bob has a privilege to do X Carol does not have a claim right for Bob to do X (i.e., Carol has a no-right for Bob to do X). Bob’s privilege to do X means he does not have a duty to do X. If Carol gives Desmond a power to change the legal situation of X then Carol has a liability to accept the changes Desmond makes to her legal relationship to X. Desmond’s power over X means that he does not have a disability to change Carol’s relationship to X (i.e., Desmond is not prevented from changing Carol’s rights to X). Finally, Desmond has an immunity from Eve concerning X if Eve cannot change Desmond’s legal relationship with X (i.e., Eve has a disability to alter Desmond’s relationship with X). Desmond’s immunity also means that he does not have a liability to accept Eve’s changes to his rights over X. These concepts are not affected by software’s intangibility as they describe the rights themselves and the relationship between the parties involved rather than the features of the property itself. For example, suppose I use a particular program that allows me to use a program without paying for it for thirty days, with the proviso that if I still use it after that time I have to pay the developer $50.9 The developer therefore has a claim right for me to pay to $50 which I have a duty to pay if I continue using her program. The same relationship and rights exist if the example is changed to paying for a vacuum cleaner if I want to keep it after testing it in my house for a month. The structure of this paper is as follows. I begin by setting out the initial assumptions grounding this conceptual framework, including what software is for the purposes of this framework and how different pieces of software can be related to each other. I then classify the people associated with software ownership into three groups: creators, custodians, and users. These classifications are used to define a set of software rights and duties and the possible relationships between them. I conclude with a brief example of how this framework can be used by defining the bundle of rights that free software gives its users, and to define the free software movement’s concept of ‘copyleft’, a key feature of the influential GNU General Public License (GPL).10 8

Hohfeld (2001), p. 12. This is the central concept behind shareware. See Cifuentes and Fitzgerald (1997), pp. 457–458. 10 Free Software Foundation (http://www.gnu.org/copyleft/copyleft. html). 9

A bundle of software rights and duties

Initial assumptions For the purposes of this framework software (or a computer program)11 is defined as the instructions computer hardware executes to perform a particular task. Software can exist as source code and object code. Source code is the set of instructions written in a human-readable programming language that comprises the program. Object code is the actual instructions executed by the computer hardware and is not generally intelligible to humans. Source code is converted into object code by a software compiler. Likewise, software decompilers can convert object code back into source code. To be practically useful software must be in a medium computer hardware can use. It is usually distributed as data on some form of digital media that hardware can process, such as the binary data stored on a CD or hard drive. As most forms of digital media used in computers can be written as well as read, software is easy to copy and change. The tools necessary to create and modify source code are also readily available, so anyone with the ability to run software may also have the opportunity to create it, copy it and even modify it. Software also has a minimal distribution cost, as it can be made available on the Internet or copied onto physical media like CDs and DVDs. The ease with which software can be copied makes controlling these actions particularly important to those wishing to control its distribution. For this framework it is necessary to assume that software can be owned—i.e., that there is some legal mechanism that allows one party can control what others can do with a particular piece of software. The state provides this mechanism through intellectual property laws such as copyright, patents and trade secrecy. Copyright protects the actual expression that comprises the software (i.e., the actual source and object code), but does not prevent other developers from creating their own implementations of the software’s features and functions. Copyright allows the owner to prevent others modifying, reusing and distributing her software, unless the ‘fair use’ provisions of copyright law allow users to perform these actions (in order to reverse-engineer the program, for example).12 Patents prevent other developers from implementing the patented functions of a program if the function is unique, nonobvious, and described within the patent application. A software patent prevents other developers from imitating what the patent covers in their own software. Trade secrecy allows the developer to prevent others from using information they keep secret for commercial advantage, such as 11

The terms ‘software’ and ‘program’ can be used interchangeably. Software licenses often attempt to deny users the ability to reverseengineer the software they cover. See Lessig (2002), pp. 185–186.

12

187

the source code if they only distribute the software’s object code.13 These protections allow software owners to define the rights and duties others have over their software, and allow them to enforce these rights and duties through legal action. The state can also limit the rights that can be denied to users and how long the rights and duties may remain in force. Once the copyright or patent on a program expires the software owner loses her control of the rights and duties that rely on those forms of protection. Like all intellectual property, software ownership is ownership of the intangible ‘intellectual object’ that the software represents.14 Copyright law distinguishes between the expression of an idea and the idea itself, and only protects the actual expression.15 This is a type/token distinction, where a type is something unique and abstract and a token is a particular physical instance of something.16 The intellectual object (the ideas) is a type, while the expressions of that idea are tokens of it. This distinction can distinguish between the software as an intellectual object and the physical copies (i.e., the expression of the developer’s ideas) stored on digital media. The intellectual object is the software type while its physical copies are tokens of that software type. The source code and object code of the same program are different tokens of that particular software type. The copy of the Mozilla Firefox web browser I have running on my computer is a token of the type ‘Mozilla Firefox’. If I also had a copy of its source code I would have two different tokens of that software type. Controlling a software token does not mean that the owner of that copy can claim ownership of its related software type. Possessing two tokens of Mozilla Firefox on my computer does not give me ownership of the type ‘Mozilla Firefox’. Software ownership is the ownership of the software type rather than owning individual software tokens. Software users are primarily concerned with the rights and duties over software tokens, while software owners have rights and duties over the software type. The software type has several levels of abstraction that descend towards a description that most closely matches specific software tokens. The most abstract level of the type is the class, which is the broad software category that the program belongs in, such as word processor, web browser, or operating system. Sub-classes describing common features shared by various distinct programs can 13

Copyright, patents, trade secrets and how they relate to software are further described in Classen (2008), pp. 11–16. 14 Hettinger (1989), p. 34. 15 Classen (2008), p, 15. 16 Wetzel (http://www.plato.stanford.edu/archives/win2008/entries/ types-tokens/), Wilson (http://www.ucl.ac.uk/*rehbjgs/docs/ontologyip.pdf), Wilson’s paper is forthcoming in The Monist in 2010.

123

188

D. M. Douglas

Table 1 Software classification Type

Token

Class

Sub-class(es)

Basis

Title

Version

Platform

Web browser

GUI (graphical user interface)

Mozilla

Mozilla Firefox

3.0

Windows

The copy of the program on a computer hard drive

Operating system

Unix

BSD

FreeBSD

8.0

x86

The copy of the program on a disc

further refine the class (‘Unix’ is a sub-class of ‘operating system’, for example). Below the sub-class level is the basis level, which denotes whatever program (if any) was the primary source for this particular program. If I create a new program Y that incorporates a significant portion of source code from X, then X is the basis for Y. Unlike a class or sub-class, the basis level designates a single particular program, which is something that be can be owned. A program can also have more than one basis. Below the basis level is the title denoting the unique software type. As the title specifies a particular program it is the level of abstraction that software ownership normally operates (i.e., the title level and below represents the intangible object owned). However, if a particular program is a development of another (i.e., there is one or more particular programs identified at the basis level) some of the software’s ownership rights and duties may belong to the owner of the program that served as a basis. Below the title level is the version level that describes the particular software release. Finally, the platform level describes the particular hardware or software platform that the program is designed for. It is below the version level as the same version of a program can be developed for different platforms. Table 1 shows these different levels of abstraction and illustrates them with a couple of examples. This framework of rights has a single foundational right, in the same way that Honore´’s incidents of ownership is founded on the right to possess.17 While possession is necessary to use of physical property, software can be used without necessarily possessing a physical copy of it (such as using a program stored on another computer via a network, for example). The equivalent of possessing physical property for software is accessing it, as access is necessary to interact with it in the same way that possession is required to use and control physical property. One or more other rights and duties that define the actions permitted with the software always accompany the right to access, as the other rights describe how the software can be accessed.

17

Honore´ (1968), p. 113.

123

Creators, custodians, and users The rights and duties define relationships that can involve three types of party with an interest in a particular program: creators, custodians, and users. These parties can be individuals, informal groups of people, more structured organisations like non-profit groups, companies, governments, or anything in between. The creator is the party who originally wrote the software, while the custodian is the party controlling how others can use the software. The creator and the custodian will often be the same.18 One case where they are distinct is where the custodian commissions the creator to develop a program as (in copyright law terms) a ‘work made for hire’ so that the creator’s rights to the program are assigned to the custodian employing her.19 Users are those interested in applying the software to perform a particular task, and are limited in what actions they can perform on and perform with the programs by the terms the custodian sets in the software license. Creators, custodians, and users will each have a different perspective on how software should be used by themselves and others. The creator initially holds all of the rights and duties over the software she creates unless another party has a prior claim to any of them. In a practical sense this is because the creator holds the copyright over her work as copyright exists over a new creative work (such as software) as soon as it is created.20 Some or all of the rights and duties can be assigned to another party who then becomes the custodian of that software. Keeping all of the rights and duties to herself makes the creator the software’s custodian as well. The custodian is the party who controls how others can use a particular piece of software, usually through the terms of a software license. This ability means that the custodian effectively ‘owns’ the software (i.e., she controls the software type). She is also the party that controls the ‘endorsed’ or ‘official’ version of the software in question, as the endorsed version is the one that the creator or the 18

Distinguishing between creator and custodian is important for personality-based justifications for creators to hold particular rights and duties. 19 Classen (2008), p. 83. 20 Ibid., p. 16.

A bundle of software rights and duties

custodian recognises as her program. The creator can still endorse a program even if she did not actively contribute to the version produced by the current custodian. Consider a program X created by Alice. Alice is unable to continue work on X, so she hands over custody for X to Bob and publicly states that Bob is the new custodian of X. Bob now controls X’s future development. If Bob creates a new version of X called X1, X1 will be the endorsed version of X as Alice recognises Bob as X’s custodian. As X1 is the endorsed version of X, X1 and X are the same software type. This makes Bob the creator and custodian of X1 and the custodian of X, while Alice is still X’s creator. The free and open source software community uses the term ‘maintainer’ to describe the party responsible for the endorsed version of a program. I have used the term ‘custodian’ instead as it covers a wider range of cases. A custodian may have no interest in fixing problems or adding new features to her software and may wish to prevent others from doing so. A maintainer is a custodian with an active interest in and the ability to make changes and improvements to the software. In the example described above, Bob is the maintainer of X. A maintainer is a custodian, but a custodian is not necessarily a maintainer. If Alice did not have the ability or interest to continue work on X, but did not want someone else to take over control of it, Alice would still be the custodian, but not the maintainer, as there would not be a maintainer for X. A creator of a variant of an existing program only becomes the custodian of that variant, as it is the only version that she is responsible for creating (thus allowing her to endorse it as ‘her version’). The variant becomes a software type distinct from the original program. The practice of creating a variant distinct from the creator’s endorsed version is called forking as the original program’s development now progresses along two different paths.21 A historical example is the fork of XEmacs from the GNU Emacs text editor.22 As GNU Emacs is controlled by its original creator and custodian Richard M. Stallman it is the endorsed version of it. XEmacs is a variant of GNU Emacs as it is not under Stallman’s control and is not endorsed by him as being ‘GNU Emacs’. The creators of the XEmacs variant have custody over XEmacs but not over GNU Emacs, and likewise Stallman does not have custody over XEmacs. XEmacs is a distinct software type with GNU Emacs as its basis. If the custodian is also the creator she may hold all of the rights over the software. If the creator and custodian are distinct the custodian may still hold most of the rights but may also have duties to the creator, such as acknowledging

189

the creator as the software’s original author. The creator also might not hold all of the rights and duties if she has used portions of software controlled by others within her program. While the creator may hold the rights over the portions she has written herself, she must also respect the rights granted to her by the creators of what she has used within her work. If Carol uses portions of Alice’s program X within her new program X2 she must respect the rights and duties Alice places on using X. However, Carol may control the rights and duties over her own original work contained in X2. The third party with an interest in a particular program are its users. Their interaction with a program might be as simple as merely utilising the software in one’s daily work or as complex as modifying it to run on a different type of computer hardware than it was originally designed for. The rights and duties the custodian grants or denies to the user are defined in the agreement made between them (i.e., the software license). The user has no rights or duties regarding the software beyond those that the custodian grants her unless the state requires that user cannot be denied particular rights. A user can become the creator and custodian of a software variant if the custodian of the endorsed version permits such variants. Bob and Carol are users of X before they gain custody over their own particular variants of it. Many free and open source software projects pass from one custodian to another by mutual agreement, much like the passing of control from the creator to a separate custodian.23 A variant’s creator establishes a similar relationship between herself and the endorsed version’s custodian as the custodian has with the original creator (if they are distinct). The creator of a variant can gain custody over her version it if the original software’s custodian gives her the right to do so. (This is the right to manage, which is described below with the other rights and duties.)

Software rights and duties As mentioned earlier, the right to access is the foundational software right (as the right to possess is for Honore´’s standard incidents of ownership). All of the rights and duties developed in this framework are dependent on the right to access as this allows any other action to be performed on the software. To illustrate this, suppose I have the right to sell copies of a program’s object code for commercial gain. I will call this the right to revenue. To profit from selling these copies I must be able to distribute them, so the right to distribute is the pre-requisite for the

21

St. Laurent (2004), pp. 171–173. The split between GNU Emacs and XEmacs is described in Turnbull (http://www.xemacs.org/About/XEmacsVsGNUemacs.html).

22

23

Raymond (http://catb.org/*esr/writings/cathedral-bazaar/cathedralbazaar/).

123

190

right to revenue. To distribute copies I must be able to make them (the right to duplicate), which itself requires that I can access the program in order to copy it. Only the right to access is independent of any other rights. While holding pre-requisite rights is necessary to hold the rights that require them (such as having the right to distribute is necessary to also hold the right to revenue), it is not sufficient. Holding the right to distribute does not imply that the holder can also necessarily claim the right to revenue. A program’s source code and object code can have different rights and duties associated with them. The ability to ‘read’ software concerns the software’s source code as it is human-readable. Likewise, being able to decompile the object code into source code is only relevant to object code. A custodian may wish to allow others a particular right to only one form of the software. A creator might want to keep her software source code secret by denying others rights to it while still granting them some rights to the object code. The rights and duties do not apply indefinitely. If the mechanism allowing the custodian to enforce her rights elapses (if the copyright expires, for example), the rights over the software become available to anyone. A right or duty might also be withdrawn from the holder if a particular condition is met, such as the passing of a particular length of time. A creator might give a custodian the right to distribute her software for a certain number of years, after which the right to distribute returns to the creator. Performing an action that the custodian has denied to the user may also be grounds for withdrawing that user’s rights to the software. A custodian may also withdraw the rights and duties granted to a particular user if she violates the duties granted to her, such as by failing to fulfil the duty to reward the custodian. The parties involved must be aware of the conditions under which the rights and duties can be withdrawn when that they enter into the relationship. The software rights and duties that make up this framework are listed in Table 2, followed by detailed descriptions of each right and duty. While some of these rights and duties share their names with specific legal terms (in particular, duplicate, distribute, transfer, and assign), their usage here should be understood as denoting a general concept rather than their specific legal definition. These rights and duties cover the major interests of creators and custodians (reward, attribute, responsibility, revenue, manage and assign), ordinary users (use, duplicate, distribute, transfer and responsibility) and users who are also software developers (read, imitate, modify, decompile and reuse). Access The right to access is the right to interact with a token of the software in the ways specified by the other rights and

123

D. M. Douglas

duties someone holds. In the same way that possession is necessary to make any use of physical property, access is the foundational right necessary to perform any action with software. The right to access is a privilege for the user and a no-claim right for the custodian. As the other rights and duties possessed define the forms of access someone has, the right to access is not granted to anyone on its own. Suppose Alice allows Bob read the source code for her program X and gives Carol the right to distribute copies of X’s object code. Both Bob and Carol have access to X but their forms of access differ depending on the other rights they have to X. Carol would have access to physical copies of X’s object code while Bob might only have access to a copy of X’s source code. The right to access may include access to a copy of the software token on some form of physical media depending on how the user interacts with it. Having the rights to access and use software running on a server does not necessarily give the user access to a copy of that program in the same way that installing and running a program on her own computer does. For example, my rights to access and use the Google search engine does not give me access to a copy of it on physical media, while my rights to access and use Microsoft Word gives me access to a copy of it on my computer’s hard drive. Use This is the right to execute the software and utilise it on a computer. It is directly analogous to Honore´’s right to use if ‘use’ is defined narrowly as ‘‘the owner’s personal use and enjoyment of the thing owned’’.24 The right to use is a privilege for the user, with a corresponding no-right for the custodian. It requires the right to access as a pre-requisite right. The method of actually executing the software differs between source and object code. Object code is normally executed directly on hardware, while source code may require the intermediary step of conversion into object code before it is executed. Source code may require compiling into object code or being run through an interpreter program that changes the source code into object code when the user executes it. The right to use for source code would therefore also include the ability to perform this intermediary step of compilation or interpretation. The right to use can vary from being a right to use the software on a single computer to the right to use it on any number of computers. The software license specifies how many computers it can be used on. If the user holds the right to use the software on multiple computers at the same time (so that a copy of the program exists on each 24

Honore´ (1968), p. 116.

A bundle of software rights and duties

191

Table 2 List of software rights and duties Software right

Type/token

Relationship

Pre-requisite(s)

Access

Token

User (privilege) and custodian (no-right)

None

Use

Token

User (privilege) and custodian (no-right)

Access

Read

Token

User (privilege) and custodian (no-right)

Access

Attribute

Token

User (duty) and creator (claim right)

Access (read)a

Duplicate

Token

User (privilege) and custodian (no-right)

Access (read)a

Reward

Token

User (duty) and custodian (claim right)

Access (read)a

Transfer

Token

Former user (power) and new user (liability)

Access (read)a

Imitate

Type

User (privilege) and creator (no-right)

Use

Modify

Token

User (privilege) and custodian (no-right)

Use (read)a

Responsibility

Token

User (claim right) and custodian (duty)

Attribute

Distribute Decompile

Token Token

User (privilege) and custodian (no-claim right) User (privilege) and custodian (no-right)

Duplicate (read)a Use and duplicate

Reuse

Token

User (privilege) and custodian (no-right)

Imitate, modify, and distribute (read)a

Revenue

Type

User (privilege) and custodian (no-right)

Distribute (read)a

Manage

Type

Existing custodian (power and immunity) and new custodian (liability and disability)

Distribute and whenever rights and duties are to be changed for others

Assign

Type

Former custodian (power) and new custodian (liability)

Manage and whatever rights and duties are to be passed onto the new custodian

a

The right to read is a pre-requisite if this right or duty applies to the software’s source code

computer), the user must also be given the right to duplicate as duplicates of it will exist on each computer. The right to use also covers any duplication of the software occurring within the computer itself as it runs (such as copying it from the hard drive into memory) as this copying is a necessary part of executing it. These points are discussed further under the right to duplicate.

interpreter). This may occur if the user does not have access to the particular software or hardware necessary for the source code to run. However, the ability to read the source code is still dependent on having access to it, so the right to access is the pre-requisite for holding this right.

Read

This is the duty to acknowledge the creator as the software’s developer. The duty holder cannot claim that the creator’s work is her own if she distributes it or otherwise attempts to take credit for it. If portions of software carrying the duty to attribute are reused in a new program, the new program’s creator must acknowledge the software’s origin somewhere in their program where it is accessible to others. The particular means and degree of attribution depends on the terms of the particular software license granting this duty. All that matters for this discussion is that using some or all of the software must be acknowledged in some way so that others are aware of its origin. The duty to attribute the software author is a claim-right for the creator, as the user has a duty to the creator to acknowledge her work. The custodian may also have a duty to attribute the creator if the creator and custodian are distinct. Copyright law generally gives creators a moral right (which they cannot assign to others) to have their work attributed to them.26 However, in some jurisdictions (such

This is the right to examine the program’s source code, where the source code is in a format that allows the user to understand how it works. This makes the ideas implemented within the software easily accessible to other developers. Like the rights to access and use this right is a privilege for the user. The right to access is its only prerequisite right. The right to read is necessary (but not sufficient) to hold any other rights or duties over a program’s source code. A custodian might allow the user to read the source code but not to modify or distribute it.25 This possibility means that the right to read does not require the right to use as a prerequisite due to the possibility that the source code might be presented in such a way that it cannot be easily used as a program (by processing it through a compiler or 25

Some of Microsoft’s Shared Source Initiative licenses are examples of this, as the licensee can read the source code of a particular program but is limited in what she can do with it. See St. Laurent (2004), pp. 144–146.

Attribute

26

Classen (2008), p. 86.

123

192

as the United Kingdom) this does not extend to software.27 This leaves open the possibility of the creator assigning this right to someone else if they wish to do so. Whether this is permissible depends on how this duty for users (and possibly custodians) is justified. For example, a Hegelian argument for software ownership would make this a moral right (and so cannot be assigned to anyone else) as the program is an expression of the creator’s personality.28 The duty of attribution has the right to access as a prerequisite. The right to read is necessary if the source code is distributed and attributed (as the right to read is necessary for any use of the source code). Although they are not formally connected to it, other rights related to this duty are the rights to modify (as those who modify the software must describe what has been modified and by whom) and reuse (as the portions of other software used in a new program must be attributed to their original source). Duplicate This is the right to create a copy of a portion or all of the software that is distinct from the original. This does not include the copying that takes place within the computer when the software is executed or installed on a single computer as this duplication is a necessary part of using it. Duplicating the software must be a deliberate act by the user to copy it from one computer to another. Having multiple copies of a program on a single computer (such as a copy in the computer’s memory and a copy on the hard drive, for example) does not require the right to duplicate, while having copies on two separate computers does. The right to duplicate is a privilege for the user and requires the right to access as a pre-requisite in order to have something to copy. As duplication requires a copy of the object or source code, the holder of this right must be able to possess such a copy. The right to read is also required for duplicating the source code. The right to duplicate is necessary to use software operating on different computers. For example, consider a database program accessible via a computer network. The database software is stored on the network server and not on the user’s computer. However, part of the database is duplicated on the user’s computer when the server returns the results of a query, as the results make up the portion of the database matching that query. Using this database necessarily requires duplicating a portion of it onto more than one computer unless the database is stored and queried on the same computer (as then the database is stored on only one computer). Another example is network software that transfers to the user’s computer and is then executed 27 28

Stamatoudi (2002), pp. 160–164. Hughes (1988), p. 342.

123

D. M. Douglas

there, such as a Java applet on a web page.29 The web server duplicates the Java program onto the user’s computer, where it is executed. In this case duplication is necessary to access and use the program. However, the user does not need the right to distribute the Java program as she is only receiving a copy and not sending one to someone else. The right to duplicate is distinct from the right to distribute as it describes instances where the user makes copies of the software for personal use. The right to duplicate covers self-regarding copying while the right to distribute covers other-regarding copying. Self-regarding copying includes backing up the software, where the user creates a copy of it for her personal use as a safeguard against the original being damaged. The user cannot give that backup copy to another person as this requires the right to distribute. If the user holds the right to use on multiple computers the right to duplicate also allows them to install the software on more than one computer. If the user holds the right to use on one computer and the right to duplicate, the user can create a backup copy of the software but not install it or the original on more than one computer. If the right to use is not restricted to one computer, than the user can both create a backup copy and install the software on multiple computers. Installing copies of software on multiple computers used by the same individual does not require the right to distribute if it is not to be used by others, as it is not being distributed to anyone else. Reward The duty to reward obliges the user to give something to the custodian in return for using the software. This reward is often paying the purchase price of a software license. The reward might also be paying a regular fee for using the software, such as the monthly fees levied for playing some multiplayer games over the Internet or a contract to use the software for a given period. This is a duty for the user and a claim-right for the custodian. The duty of reward has the right to access as a pre-requisite as this access (in whatever form it takes) is the reason for the user rewarding the custodian. The right to read is also required for there to be an obligation to reward the custodian for the source code. While the custodian specifies the form of the reward, merely ‘using’ the program is not considered a reward for the purposes of this duty. The reward does not necessarily have to be a payment from the user to the custodian. A reward could be as simple as sending the custodian a message of appreciation for their work, such as in the ‘postcardware’ variation of the shareware concept where the user is obliged to send the custodian a postcard if she 29

Sun Microsystems (http://java.sun.com/applets/).

A bundle of software rights and duties

finds the software useful. All that is necessary for this duty is that the user is obliged to give something to the custodian that she requests. The duty to reward can also cover other creators who use some of another creator’s software within their own work. Such a reward might take the form of a single upfront payment, a royalty for every software license sold that incorporates the other creator’s work, or a combination of the two. Such cases generally also have the duty to attribute that software to its original creator. Transfer The right to transfer allows the user to pass on her the rights and duties she holds over a particular program to another user. The original user loses all of her rights and duties over the software and the recipient gains those same rights and duties. This right allows the user to alienate herself from the software, ending her relationship with the custodian and creating a new one between the recipient and the custodian. If instead the original user had kept some of the rights (by keeping a copy of the program for her own use, for example), she would not be transferring the software but rather distributing it (and so requires the right to distribute). The right to transfer does not cover the case where a custodian hands over her rights and duties to another as the custodian’s rights are concerned with the software type rather than the rights over a particular software token. The custodian holds rights and duties over the type while users have rights and duties over their particular tokens. The right to transfer allows the user to hand over her rights and duties to her particular token (as well as the token itself) to another user. If I do not possess a physical copy of the software, the token I am transferring is whatever allows me access to that program. For example, I can transfer my rights to access a particular server by giving my authentication details (like a username and password) to someone else. The recipient can confirm that I do not keep my right to use by changing these details so that I cannot access that server anymore. The right to assign covers handing over the rights and duties over the software type to another custodian. The right to transfer is a power for the user giving up her rights and a liability for the user receiving them. The right to access is the pre-requisite for this right, and the right to read is required to transfer the source code to another user.

193

in that new work. This allows others to recreate particular features and aspects of the software type in a new program that is a distinct software type of its own, although it will share a class and one or more sub-classes with the original. The right to reuse covers instances where the actual source or object code itself is used within a new program. The right to use is the pre-requisite for this right as the imitator must have some experience of the features she is attempting to recreate. It is also a privilege for the user. If the custodian could deny the right to imitate to others developers would be unable to create programs with similar features or a similar user interface (i.e., the software’s ‘look and feel’) to that software. Denying others the right to imitate effectively gives the custodian ownership of the sub-class level of the software type, and even possibly the class level if the software’s function is unique. For example, if Alice denies Bob the right to imitate her program X, Bob is unable to write a program that is functionally equivalent to X. Bob therefore could not create a program belonging to the sub-class ‘X-alike’ or ‘X-compatible’. Modify This is the right to make changes to the software for the modifier’s own use. For the purposes of this right such modifications must be a deliberate action of the user and not changes occurring during its normal operation.30 Modifications a user might wish to make include bug fixes (correcting flaws in the software) or changing it to better fulfil her particular needs. This right is a privilege for the user. To be practical in most instances modifying software usually requires access to the source code, and hence possession of the right to read. While it is possible to modify software’s object code itself it is often prohibitively difficult to do so. In some cases altering the software’s configuration files (which may be in a human readable format) can usefully change the software’s operation. Due to these possible cases the right to modify requires only the right to use as a pre-requisite and access to a copy of the software to modify. As a practical matter, however, the right to read would be necessary to make significant changes and would be desirable for anyone interested in using this right. In order to distribute the modified program the user also requires the right to reuse, as the user is creating her own variant of the program.

Imitate The right to imitate is the right to recreate aspects and functionality of the software in a new program without using any of the source or object code from the original

30

An example of this is ‘self-modifying’ or ‘self-adaptive’ software, i.e., software that rewrites part of itself during the normal course of its operation.

123

194

Responsibility Responsibility is the user’s claim-right to hold the custodian accountable for any damage or harm caused to her or her interests by flaws in the software. This is a duty for the custodian, and the duty to attribute is the pre-requisite right for responsibility as it is the means of identifying the responsible party. Someone might be motivated to release software anonymously in order to avoid responsibility for what it does, such as the creators of viruses and other malware. Software custodians often do not grant users a claimright to responsibility. Much like decompilation, the right to hold the creator or custodian responsible is usually only specified in order to deny it to the user. Software licenses often feature warranty disclaimers that do not guarantee the software’s fitness for a particular use, for example.31 Distribute This is the right to give copies of the software to others. Depending on the terms given by the custodian, such copies can be given to others for free or with a charge to cover the costs of duplication and distribution. Distributing copies of a program with the intent of profiting from it requires the distributor to also hold the right to revenue. The user of the copy may also have a duty to reward the distributor in return for receiving it. This right is a privilege for the user. The scope of distribution depends on any conditions the custodian places on how and to whom the software can be distributed. A custodian might permit the user to only distribute the software to individuals or non-profit organizations, for example. While the user might distribute such a program to a business, the business will not gain any of the rights over the software (and so would be unable to use it) as the user has violated her right to distribute it. Whether the right to distribute is distinct from giving others access to that software depends on whether the software is operated or stored on one or more computers. I am not distributing a program if I let a friend use it on my computer but I am distributing it if I give her a copy to use on her own computer. The recipient of the distributed copy receives the same rights and duties as the copier, unless the copier holds the right to manage. If the copier has the right to manage she may choose which of the rights she holds are given or denied to those who receive the software from her. Distribution requires the right to duplicate as a pre-requisite as

31

St. Laurent (2004), pp. 11–13.

123

D. M. Douglas

passing on the original copy the user received (without the user keeping a copy of it) is covered by the right to transfer. The right to distribute the source code requires the right to read it as a pre-requisite. Decompile This is the right to convert the object code into source code through the use of a decompiler. The source code from the decompiler is not as readable as the original source code as it lacks the comments made by the original developer within the source code (as the comments are removed from the program during the compilation process). However, the ideas used within the software may still be apparent to a skilled programmer reading the decompiled version of source code. This right is a privilege for the user. Custodians who only distribute software as object code often deny users this right in order to hide the workings of their software. This allows them to protect their ideas as trade secrets. Decompilation is limited to object code as it is normally unnecessary when source code is available. The pre-requisite rights for decompilation are the rights to use (as someone decompiling a program would need to have some idea of what it does in order to understand the decompiled source code) and duplicate (as decompilation creates a new copy of the source code). Reuse The right to reuse is the right to incorporate some or all of an existing program’s source or object code into a new program. Often a discrete part of the original is taken and used within a new work. The new program may or may not resemble the original depending on how and how much of it is reused in the new work. An entire program can even be placed within another program that acts as a ‘wrapper’, allowing the original program to run on a different computer or operating system that it was originally designed for. The right to reuse also covers instances where a user distributes a modified version to others, as the user is effectively ‘reusing’ most of the software in her modified version. This right is a privilege for the user and a no-claim right for the custodian. This right has the rights to imitate, modify and distribute as pre-requisites, as the new program necessarily imitates some aspect of the original program, and involves changing a portion of the original to fit it into the new program and then distributing that portion within it. The right to read the original program’s source code is also necessary to reuse the source code. Depending on the rights she holds over the reused program the user may be unable to change the rights and duties others have over the new software that incorporates it. The user needs to hold the right to manage in order to take some

A bundle of software rights and duties

(or all) of the code from the reused program and place it under her own control by placing different rights and duties over the new program. Without the right to manage she must give her new program’s users the same bundle of rights and duties that users of the original reused program had.32 A distinction needs to be made between distributing a portion of software with a new program (i.e., bundling it) and reusing a portion inside a new program. If the portion is usable independently of the program that it is bundled with (either by the user directly or by another program on the computer), that portion is merely distributed rather than reused. If the portion cannot be used separately from the program it is distributed with then it has been reused. If the reused program had the duty to attribute attached to it, the creator of the new program would have to include acknowledgements of the origins of the reused code within in her work. If the new program reused portions of many different programs that all carried duties to attribute, the new program would have to include acknowledgements for all of them. Revenue The right to revenue is the right to attempt to profit from distributing the software. This includes selling copies of the program to users or renting or leasing it to others. This does not include placing a cost on software copies that covers only duplication and distribution costs as this covered by the right to distribute (since the distributor does not profit from this). Distribution is just propagating software while revenue is both propagating and making money from doing so. The right to profit is a privilege for the user and is analogous to Honore´’s right to the income from a thing.33 Normally this right allows the custodian to gain financially from selling licenses to use the software she controls. Users might also hold this right, allowing them to sell any copies they make to others. This right does not cover the payment a user may receive for transferring the software copy in her possession to another user (i.e., selling the software second-hand)34 as this is covered by the right to transfer. Software retailers would not ordinarily have this right as they generally do not sell copies that they create themselves but rather sell copies obtained from their suppliers. The right to distribute is the pre-requisite for this right and the right to read is necessary for the right to profit from distributing the source code.

32

This is the case with the GNU General Public License. See Free Software Foundation (http://www.gnu.org/licenses/gpl.html). 33 Honore´ (1968), pp. 117–118. 34 This is quite common for video games.

195

Manage The right to manage allows the holder to change one or more of the rights and duties granted to those receiving the software from her. It effectively makes the right holder a new custodian over the software while leaving the original custodian’s rights over it in place. It can cover both source and object code, and it is directly analogous to Honore´’s right to manage, ‘‘the right to decide how and by whom the thing owned shall be used.’’35 To describe this right in Hohfeldian terms it is necessary to distinguish between the custodians involved. The party granting the right to manage is the first custodian while the party receiving the right is the second custodian. This right is a power for the first custodian and a liability for the second custodian. The first custodian also has an immunity since the second custodian has a disability to change the rights and duties held by the first custodian. For the creator (or the original custodian), the right to manage is the right to set the rights and duties anyone else has over her software. As the original custodian (or the creator) initially holds all the rights and duties over the software she decides what rights and duties others may have over it. In some cases the custodian might grant users the right to manage as well, allowing them to become custodians to the users (and only those users) who receive the software from them. The new custodian (i.e., the user) must herself hold the particular right that she wishes to change for her users. If the custodian does not hold the right to decompilation, for example, she cannot give that right to those receiving the software from her. The pre-requisite rights for a user to hold the right to manage are the right to distribute (since it is required for the user to give or sell the software to someone else) and whatever rights and duties the custodian allows users to change for others. The original custodian, who holds all of the rights and duties, is not restricted in the rights and duties she can grant or deny to others. The right allowing all of the rights and duties to be moved from one custodian to another (with the first custodian losing those rights in the process) is the right to assign. The ability to control how other users can use the software makes the right to manage is a particular powerful right for users to hold. While the user can change the rights and duties of users receiving the software from her, she cannot change the rights and duties of the custodian who granted her the right to manage. A user with the right to manage cannot change the rights and duties of other users who receive the software from other sources (such as the custodian who gave her the right to manage). For example, an extreme case would be taking software granting anyone 35

Honore´ (1968), p. 116.

123

196

D. M. Douglas

all the rights to it, reusing it in a new program, and then restricting users’ rights to duplicate, modify and distribute that new program. However, since the second custodian cannot change the rights of those who received their rights to the software from the first custodian, the original program in this case is still available for others from the first custodian with all of the rights associated with it intact. The second custodian can only affect the rights and duties of users who use her own version of the software. The custodian requires the right to assign to affect the rights and duties of all others over that software.

•

Assign

In terms of this framework, a free software license gives users the rights to use (freedom 0), read (freedom 1), duplicate (freedom 2), distribute (freedom 2), modify (freedom 1) and reuse (freedom 3). Users also have the right to access as it is the foundational right required by all the others. The right to imitate follows from freedom 3 as it is a pre-requisite for the right to reuse (since the modified program will resemble the original in some way). A free software license therefore is one that gives users the rights to access, use, read, duplicate, distribute, imitate, modify, distribute, decompile, and reuse. The Free Software Foundation also distinguishes between ‘copyleft’ licenses (like the GNU General Public License) and ‘non-copyleft’ licenses, such as the BSD and MIT licenses.38 Copyleft requires that the user cannot change the rights of other users who received the software (or a new program that reuses some of the copylefted program) from her.39 Copyleft denies users the right to manage in order to prevent them limiting the rights of other users.40 Non-copyleft licenses do not prevent users from using the right to manage to deny rights to others that they received from the original custodian. This means that users who modify non-copylefted software or reuse it within their own programs are not obliged to allow other users to read their source code, distribute it or modify it. Copyleft attempts to protect the rights of users by denying them the right to manage, which can be seen as a way of coercing custodians and users to give others the same rights that they have.41 Whether denying others the right to manage is justified depends on the software creator’s reasoning for why they distribute the rights and duties in the way that

This is the custodian’s right to pass on her rights and duties over a software type to a new custodian, with the original custodian losing those rights and duties in the process. Users who acquired the software from the original custodian now have the same relationship with the new custodian that they previously had with the original. This allows the custodian to alienate herself from the software under her control. This alienation distinguishes this right from the right to manage, as the right to manage does not remove the rights and duties from the original custodian. As this right is concerned with the software type rather than the software token it is primarily intended for creators and custodians. The right to transfer covers the passing of rights and duties from one user to another over a software token. A custodian can assign some rights and duties to another and still keep some rights and duties to herself. A creator might assign the right to distribute to a custodian and keep the right to attribution as the software’s creator to herself, for example. The right to manage is a pre-requisite for this right as it allows the holder to change the rights others have over the software and whatever rights and duties are to be handed over to the new custodian. The right to assign is a power for the original custodian and a liability for the new custodian. The right to assign is similar to Honore´’s right to the capital of a thing in the sense that it allows the right holder to alienate herself from that thing by transferring her bundle of rights and duties to another party (the ‘thing’ being the software type under the custodian’s control).36

An example: defining free software and copyleft I will conclude by using this framework to classify the concepts of free software and copyleft. The Free Software Foundation defines a free software license as one that gives users these four freedoms: 36

Ibid., p. 118.

123

•

• •

37

The freedom to run the program, for any purpose (freedom 0). The freedom to study how the program works, and change it to make it do what you wish (freedom 1). Access to the source code is a precondition for this. The freedom to redistribute copies so you can help your neighbor (freedom 2). The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.37

Free Software Foundation (http://www.gnu.org/philosophy/freesw.html). 38 St. Laurent (2004), pp. 35–49, 14–17. 39 Free Software Foundation (http://www.gnu.org/copyleft/copyleft. html). 40 Kuhn and Stallman (http://www.gnu.org/philosophy/freedom-orpower.html). 41 Watson (http://www.ram.org/ramblings/philosophy/fmp/free-soft ware-philosophy.html).

A bundle of software rights and duties

they have, and whether users can argue that it is unacceptable to deny them certain rights. This is just one way that this framework can be used to highlight the particularly controversial aspects of software ownership and licensing. Acknowledgements I would like to thank Julian Lamont, Kimberlee Weatherall, Fabien Medvecky, and the two anonymous reviewers for their many helpful comments and suggestions.

References Cifuentes, C., & Fitzgerald, A. (1997). Copyright in shareware software distributed on the internet—the trumpet winsock case. In Proceedings of the 19th International Conference on Software Engineering (pp. 456–464). Boston, MA: ACM. Classen, H. W. (2008). A practical guide to software licensing for licensees and licensors (3rd ed.). Chicago, IL: American Bar Association. Hettinger, E. C. (1989). Justifying intellectual property. Philosophy and Public Affairs, 18, no. 1, 31–52. Hohfeld, W. N. (2001). Fundamental legal conceptions as applied in judicial reasoning. Burlington, VT: Ashgate/Dartmouth. Honore´, A. M. (1968). Ownership. In A. G. Guest (Ed.), Oxford essays in jurisprudence, first series (pp. 107–147). Oxford: Clarendon. Hughes, J. (1988). The philosophy of intellectual property. Georgetown Law Journal, 77, no. 2, 287–366.

197 Lessig, L. (2002). The future of ideas. New York: Vintage Books. Munzer, S. R. (1990). A theory of property. Cambridge: Cambridge University Press. St. Laurent, A. M. (2004). Understanding open source & free software licensing. Sebastopol, CA: O’Reilly. Stamatoudi, I. A. (2002). Copyright and multimedia products: A comparative analysis. Cambridge: Cambridge University Press. Wetzel, L. Types and tokens. http://www.plato.stanford.edu/archives/ win2008/entries/types-tokens/. Free Software Foundation. GNU general public license (Version 3). Free Software Foundation. http://www.gnu.org/licenses/gpl.html. Free Software Foundation. The Free Software Definition. Free Software Foundation. http://www.gnu.org/philosophy/free-sw. html. Free Software Foundation. What is copyleft? Free Software Foundation. http://www.gnu.org/copyleft/copyleft.html. Kuhn, B. M., & Stallman, R. M. Freedom or Power? http://www.gnu. org/philosophy/freedom-or-power.html. Raymond, E. S. The cathedral and the bazaar. http://www.catb.org/ *esr/writings/cathedral-bazaar/cathedral-bazaar/. Sun Microsystems. Applets. http://www.java.sun.com/applets/. Turnbull, S. J. Xemacs vs. GNU emacs. http://www.xemacs.org/ About/XEmacsVsGNUemacs.html. Watson, B. Philosophies of free software and intellectual property. http://www.ram.org/ramblings/philosophy/fmp/free-softwarephilosophy.html. Wilson, J. Ontology and the regulation of intellectual property. http://www.ucl.ac.uk/*rehbjgs/docs/ontology-ip.pdf.

123