Is unauthorized copying of software theft?

Intellectual Property table of contents

• Software Ownership and Natural Rights
• Software Ownership and Intellectual Property Rights

Software Ownership and Natural Rights

Richard Volkman

Abstract The moral force of the prohibition against uncompensated copying and use of software is traced to a natural right to the product of one’s labor, as this is guaranteed by one’s right to life. Important implications of this view for the ideological debate among proponents of “free software” or “open source” are explored.

Do the authors of software have a right against uncompensated copying? When it comes to offering an account of what rights individuals have, anyone would agree that a right to life is among them, that the taking of another’s life constitutes a serious infringement of that person’s rights. Thus, it is a promising strategy to start our investigation by interrogating the right to life. What is the nature and scope of this right? What other rights does it entail? I begin by defending a deep connection between life and liberty. This connection is then extended to include a right to the product of one’s labor, and that will amount to a right against uncompensated copying. Finally, it is shown that acknowledging such a right is not inconsistent with the commitments of those who advocate “open source” software.

Clearly, a merely biological sense of “life” is not sufficient to explain the importance of the right to life. If someone kidnapped the Pope and brainwashed him so that all his psychological states and ways of responding to the world were identical to the states and responses of Bertrand Russell, it is clear that some extremely important right of the Pope’s was violated. This would be clear even if we thought the resulting person was an improvement. It doesn’t seem right to say that we would have made the Pope a better (or worse) person, since the person now before us does not seem to be the Pope at all. We have obliterated the Pope and replaced him with an ersatz-Russell, thereby ending the Pope’s life, even though the same biological organism is still in possession of its biological life. Surely the Pope would have lost nothing of more importance to him if he had been murdered outright rather than “merely” reprogrammed. This strongly suggests that the kind of “life” that is morally significant is a person’s biographical rather than biological life.

A biographical life, as the phrase implies, is constituted by that person’s story (as in “the story of my life.”) It generally includes a person’s actual activities in the course of his biological life. But there is something more to having a biographical life than the mere continuity and conjoinment of various psychological and physical states. In addition, it must be mine, in the sense that I identify with it. That is, I understand and justify it as something that comes from the values, relationships, and projects that tell me what my life is all about.

Hence the significance of liberty for having a biographical life. The total slave, one whose every thought was dictated and controlled by someone else, could not have a biographical life (cf. Rachels and Ruddick, 1989). Every action is directed by the projects, values and desires of someone else. So, the right to life entails that every person has claims as regards everyone else that they not interfere with her actions in pursuit of her own life, insofar as her actions do not interfere with the ability of anyone else to lead their lives. Here we have the deep identity of the right to life and the right to liberty associated with classical natural rights theorists like John Locke. The third part of the classical trinity-property-remains to be shown.

Intellectual property is usually justified on the utilitarian grounds that we need to protect innovation by guaranteeing innovators a market return on their investment of time and effort. Otherwise, no one will create intellectual property. But this argument turns on empirical claims that are seldom examined or defended. Indeed, it is hard to imagine how such a defense could proceed, given that there is no easy way to conduct the relevant experiments. Pamela Samuelson (1989) argues that faith in the efficacy of copyright protection may be misguided, especially when the efficiencies of protecting innovation work against the efficiencies of robust competition in an intellectual property system designed to grant monopolies.

This way of questioning the utilitarian foundation of intellectual property takes an even more radical turn in the hands of Richard Stallman. Stallman argues, with no less empirical data than the others (viz., none), that allowing proprietary ownership of software actually has tremendous negative consequences. According to Stallman, proprietary software undermines utility in a number of ways. Fewer people can use proprietary software. Furthermore, users of proprietary software are generally not privy to the source code that makes it work, and are therefore unable to fix or adapt the program or learn from it. Added to these direct costs, ownership of software encourages a selfishness that compounds the costs of proprietary software. “Signing a typical software license agreement means betraying your neighbors.” (Stallman, 1995) The better solution, Stallman maintains, is to make software “free” by removing intellectual property protections.

He maintains that this will not threaten innovation in software, since there are sufficient incentives internal to the art of programming to motivate dedicated programmers, who will be better educated and their programs more widely accessible and customized. Any reduction in the number of programmers and programs is offset by the improved quality and productivity of each. If Stallman is right about these empirical matters, then the balance of utilitarian reasons clearly lies on the side of doing away with intellectual property protections on software.

But does the morality of paying the producers of software really turn on such empirical issues? It is worth examining just how “free” the individuals in Stallman’s imagined world would be. Would talented programmers be free to pursue more lucrative careers, in lieu of the more modest sums they could earn writing free code? Presumably so. Any other answer would be a clear violation of their right to life, effectively enslaving them to the needs of software consumers. But allowing programmers to make these choices admits the principle that one may withhold one’s labor unless the conditions of use meet one’s own expectations. If I have a right to withhold my labor unless conditions for use meet my expectations, then I may withhold my labor unless I am compensated in a manner of my own choosing. Furthermore, I can withhold my labor unless the purchaser agrees not to redistribute my product. If you do not like my conditions, you are free to write the program yourself, or to find someone who will do so for a lower price. But I have the right to determine the conditions under which I will work. After all, I am the one who is to invest a part of my life into this project. “I put my sweat, my heart, my soul into this program.”

This is the first premise of what Stallman calls “the emotional argument.” He maintains that it merely reflects a shallow feeling of attachment for the object of one’s labor, not any genuine moral claim. But this is clearly a straw man. The real argument has nothing to do with emotional attachment. If I have a right to choose for myself how and when and under what conditions I will act, then I am well within my rights to refuse to act except under the condition that you pay me. I am also at liberty to withhold my labor unless you agree not to use the product of my labor in ways I forbid. This does not reduce or infringe your rights in the least, since you are just as free as before to do anything you want in pursuit of your life. But you have no right to my help in the pursuit of your life.

So, you have no claim on the product of my labor, at least where that product would not exist were it not for my actions. But it will be objected that the product of my labor does not come into existence simply from my labor alone. There were, after all, the initial resources that went into its creation. My labor cannot be used to make a clay pot without first having the clay. Even if I am in some sense entitled to the pot, which wouldn’t exist were it not for my labor, I am not entitled to the clay from which it is made at least, not by the above argument. Since my labor alone cannot produce anything without the introduction of natural resources, my claim over the product of my labor may be overshadowed by the claims of others over those natural resources. The traditional answer to this difficulty is Locke’s (1690) theory of “labor-mixing”:

Whatsoever then removes out of the state that nature hath provided, and left it in, he hath mixed his labor with, and joined to it something that is his own, and thereby makes it his property… at least where there is enough, and as good, left in common for others.

But what is the precise nature of this “mixing” of one’s labor? If I have “joined” my labor to something unowned, why should I now own the previously unowned thing? Is it not just as reasonable to suppose that I have lost ownership of some of my labor?

These difficulties are readily cleared away by applying the right to life as it was unpacked above. Since the right to life generates claims that no one interfere with my leading my life, I will have a claim that no one prevent me from using any natural resource that is not significant for another person’s pursuit of his or her life. When I make something out of that resource, the product of my labor is in practice inseparable from it. Since I have a claim that no one use the product of my labor without my permission, and since no one can use this resource without using the product of my labor, I have a claim that no one use this resource. That is, I have the exclusive right to use this resource; I now own it. Since no one had a claim over the use of this resource prior to its appropriation, I have violated no one’s rights in coming to own it, and anyone else who tries to use it now will violate my rights.

The condition that no one else has a prior claim over the use of a resource embodies what has come to be known as the Lockean Proviso that one leave “enough and as good.” Each of us has a claim that no one interfere with one’s actions in pursuit of one’s life. If my appropriation interferes with the life of another, then he or she has a claim that I not appropriate that resource. For most ways of life, mixing labor with resources is a means, not an end in itself. So, if my appropriation does not diminish the value of a person’s labor, then the Proviso does not rule out that appropriation. It should take no more time or effort to achieve the same ends as it was possible for that person to achieve before the appropriation took place. Thus, if one is unable to appropriate anything but is able to sell his/her labor at a price that will buy the same or more goods in trade as s/he could have made with his/her labor had there been resources to appropriate, then that person cannot complain that the Proviso was violated.

It is clear that the physical resources required for the manufacture and distribution of software are abundant and their appropriation does not violate the Proviso. The value of a disk comes from the data that’s on it, not from the natural resources that make it up, and that data is entirely the product of someone’s labor in putting it there. But the data itself cannot be owned without violating the right to life of those who want to use those ideas. No one may own an idea. Even if it is granted that I have a natural right to the products of my own mental labors, that is different from the right to exclude everyone else from those products. My rights to life and liberty guarantee that you may not interfere with my thinking and using an idea, but your rights surely guarantee you the same protection from me, and it makes no difference if I have come to think the thought first. If I cleverly think up the first use of the wheel, I might make a living selling wheels. No one may deprive me of a wheel I have made from justly appropriated resources. But there is no natural right that others not use the idea to make their own wheels, or that they not compete with me. To the contrary, they have the right that I not interfere with their pursuit of their own lives, and depriving them of the use of this idea would surely deprive them of something valuable. Any appropriation of an idea violates the Proviso.

But the prohibition against uncompensated copying and use need not derive solely from an alleged exclusive right to the product of one’s mental activities. Rather, the right to contract, in combination with the rights to the software media, reveals a legitimate moral claim against unauthorized use. If I have written a program, I cannot claim any exclusive rights to the ideas in it. Some things – like people, scenic views, and ideas – simply cannot be owned, as a matter of the internal logic of ownership. But there is no requirement that I share my thoughts with you. Instead, I may let you use them under certain conditions, and among those conditions I might require that you not allow anyone else to make a copy of the disk. This bargain in no way diminishes your rights, since you are just as free as before to write your own program. The Proviso has not been violated.

So it is not permissible to copy your neighbor’s software. Not only would your neighbor be violating a contract with the software provider, but, given the conventions associated with the conditions of use for software, you would be acting immorally yourself. The words, “I give you my word that…” or “I promise that…” are merely a conventional way of inviting reliance and accepting responsibility for producing the required outcome. In the case of intellectual property, the conventions in question are clear enough even without explicit language. The institution of shareware depends on the widespread acceptance of these conventions. Where the conventions governing software ownership are unclear, they can be legitimately established by law. Thus, there is still a great deal of work to do in filling out the best legal approximation of these natural rights for a given society. But these issues are not legal all the way down. There is a legitimate moral force, akin to the moral force of keeping a promise, behind the requirement that I not copy my neighbor’s software.

This is a version of what Helen Nissenbaum (1995) has called the “strong no-copy position.” Echoing Stallman, she rejects this view because it rules out giving a copy of one’s software to a friend as a gesture of generosity or kindness. But giving a copy of a proprietary program to a friend is not generosity. You may not displace the costs of your “generosity” so they land squarely on the shoulders of someone else. If you want to be generous, buy your neighbor the software. Giving a copy to your neighbor is not an act of generosity, nor is refusing to copy it an act of selfishness. It is fulfilling your fair and voluntary obligation to the maker of that software.

This is the proper response to Stallman’s concern that proprietary software encourages selfishness. Having “free software” must not come at the expense of having free people. Programmers need to be free to follow their own conscience, to work on the projects that they deem important, for their own reasons, and this requires that they be able to put limitations on the use of their software as they see fit. This is exemplified by WarFTP, a freeware FTP server by Jarle Aase that is distributed under the condition that it not be used “by governmental institutions and mainstream political parties.” (Aase, 1997) The point of these conditions is to avoid implicating the author in activities contrary to his principles. His right to require these conditions is guaranteed by the right to life, but Stallman’s view implies that this software is not free and is therefore not to be permitted.

Giving programmers this freedom to pursue their own visions, under their own terms, is better for programmers and for society at large, as open source advocate Eric Raymond (1997) points out in his seminal “The Cathedral and the Bazaar.” Raymond argues that open source is better for developing and maintaining quality software due to its open-ended, self-correcting, and distributed development. Instead of building ponderous, centrally planned cathedrals, in which every decision is carefully administered by a few “experts,” it is more effective to decentralize the process and let there be a free-for-all of innovation and change as in the market or the bazaar.

The principle at work here is hardly a totally original discovery. It has been embraced and defended by free market economists like Adam Smith and Friedrich von Hayek. “The Linux world behaves in many respects like a free market or an ecology, a collection of selfish agents attempting to maximize utility which in the process produces a self-correcting spontaneous order more elaborate and efficient than any amount of central planning could have achieved.” (Raymond, 1997) This ode to the invisible hand could be right out of Hayek. But such a system cannot exist without individual claims to this or that piece of work, so the self-interested and distributed actors can be compensated. In classical economics, this compensation is in the form of cash reward. For the open source movement, compensation is in the form of reputation – what Raymond calls “egoboo.” Either way, the right to be compensated for one’s labors is paramount. It is this compensation that generates the spontaneous order that is so much more efficient and sensitive to dispersed knowledge than central planning.

Stallman and others worry about the selfishness they see in such a system, but their concern is misplaced. As Raymond suggests,

Many people (especially those who politically distrust free markets) would expect a culture of self-directed egoists to be fragmented, territorial, wasteful, secretive, and hostile. But this expectation is clearly falsified by…the stunning variety, quality and depth of Linux documentation…Evidently Linux’s free market in egoboo works better to produce virtuous, other-directed behavior than the massively-funded documentation shops of commercial software producers.

This contrasts directly with Stallman’s approach to “free software.” Stallman writes, “…essential pieces of GNU software were developed in order to have a complete free operating system. They come from a vision and a plan, not from impulse.” (Stallman, 1999a) But even Stallman recognizes the importance of connecting software products to the persons responsible for them. What else could explain his insistence that we not speak of “Linux” as if it were a complete OS? Rather, he points out (1999b), we should speak of “GNU/Linux,” since many of the tools and programs that make the bare kernel written by Linus Torvalds into a useful system were originally written and distributed by Stallman’s GNU project. He is surely correct. Stallman and his comrades have a right to get credit for their work. But the moral intuitions that underlie their right to get credit equally justify rights to intellectual property, if one prefers cash to credit.

And this right to property is in fact quite important for making good software. For the marketplace to function best, the bazaar needs to extend beyond the confines of those for whom compensation is reputation. We should embrace the labors of as many actors as possible, on whatever terms they prefer. Let the market decide between them. Torvalds has commented on this, “I tend to think that some things work better as commercial software, mainly because a lot of the program is that ‘final polish’ that commercial software is so good at. For example, user interfaces are usually better in commercial software.” (Torvalds, 1998) If open source improves in these areas, it is in an excellent position to win in a free and open software market, and we will all be the winners by having the best possible software.

But until open source software improves, we need commercial software. If programmers aren’t interested in writing the interfaces we end-users want without financial reward, if that’s not what they want to do with their spare time, they do not deny us anything we have a right to. If they are interested, it is just that we give them the financial rewards they ask for in exchange for doing the work that interests us instead of the work that interests them. Protecting the product of their labor from misappropriation by others allows them to sell their labor on the free market, resulting in a system of maximum competition, in a truly open and free bazaar, where we all win on our own terms. That is moral force of intellectual property.

References

Aase, J. (1997), WarFTP FAQ, http://war.jgaa.com:8 080/faq/alt.comp.jgaa.faq.html, 3:40P EST June 29, 1999.

Locke, J. ([1690] 1980), Second Treatise of Government, ed. C. B. Macpherson, Hackett Publishing Co.

Nissenbaum, H. (1995), Should I Copy my Neighbor’s Software?, in Computer Ethics and Social Values, ed. D. Johnson and H. Nissenbaum, Prentice Hall.

Rachels, J. and Ruddick, W. (1989), Lives and Liberty, in The Inner Citadel, ed. J. Christman, Oxford University Press.

Raymond, E. (1997), The Cathedral and the Bazaar, http://www.tuxedo.org/~esr/writings/cathedral-bazaar/, 3:59P EST June 29, 1999.

Samuelson, P. (1989), Innovation and Competition: Conflicts over Intellectual Property Rights in New Technologies, in Owning Scientific and Technical Information, ed. V. Weil and J. W. Snapper, Rutgers University Press.

Stallman, R. (1999a), The GNU Operating System and the Free Software Movement, http://www.oreilly.com/catalog/opensources/book/stallman.html, 3:00P EST June 29, 1999.

– . (1999b), Linux and the GNU Project, http://www.gnu.org/gnu/linux-and-gnu.html, 3:47P EST June 29, 1999.

– . (1995), Why Software Should be Free, in Computer Ethics and Social Values, ed. D. Johnson and H. Nissenbaum, Prentice Hall.

Torvalds, Linus. (1998), The Pragmatist of Free Software: Linus Torvalds Interview, by H. Yamagata, http://www.kde.org/food/linus.html , 3:54P EST June 29, 1999.

Software Ownership and Intellectual Property Rights

The National Conference on Computing and Values (NCCV) was held on the campus of Southern Connecticut State University in August 1991. The Conference included six “tracks”: Teaching Computing and Human Values, Computer Privacy and Confidentiality, Computer Security and Crime, Ownership of Software and Intellectual Property, Equity and Access to Computing Resources, and Policy Issues in the Campus Computing Environment. Each track included a major address, three to five commentaries, some small “working groups,” and a packet of relevant readings (the “Track Pack”). A variety of supplemental “enrichment events” were also included.

This monograph contains the proceeding of the “Ownership of Software and Intellectual Property” track of NCCV. It includes the “track address,” three commentaries, three enrichment papers, the conference bibliography, and a report on the findings of the small working group on software ownership and intellectual property. Some of the papers express controversial views that do not necessarily represent those of the editors.

The track address is “Proprietary Rights in Computer Software: Individual and Policy Issues” by Deborah G. Johnson. The commentaries include “The Virtues of Software Ownership” by David H. Carey, “Trade Secrets and Software Ownership” by John W. Snapper, and “Comments on Johnson’s ‘Proprietary Rights in Computer Software’” by Helen Nissenbaum. The enrichment papers include “Why Software Should Be Free: A Free Software Foundation Paper” by Richard Stallman, “Against User Interface Copyright” by The League for Programming Freedom, and “Against Software Patents” by The League for Programming Freedom. The “Track Report” on the small working group is by David H. Carey, who was “track coordinator.”

The National Conference on Computing and Values was a major undertaking that required significant help from many people. The Editors would like to express sincere thanks to the National Science Foundation and the Metaphilosophy Foundation for support that made the project possible. And we wish to thank the following people for their invaluable help and support: (in alphabetic order) Denice Botto, William Bowersox, Aline W. Bynum, Robert Corda, Donald Duman, Richard Fabish, James Fullmer, Ken W. Gatzke, Steven J. Gold, Edward Hoffman, Rodney Lane, Sheila Magnotti, Armen Marsoobian, John Mattia, P. Krishna Mohan, Beryl Normand, Robert O’Brien, Daniel Ort, Anthony Pinciaro, Amy Rubin, Brian Russer, Elizabeth L.B. Sabatino, Charlene Senical, J. Philip Smith, Ray Sparks, Larry Tortice, Suzanne Tucker.

Deborah G. Johnson

Proprietary Rights in Computer Software: Individual and Policy Issues

1.0 Introduction

In this paper I want to focus on two central moral issues surrounding the ownership of computer software. These are the individual moral question and the policy issue. The individual moral issue is simply this: is it morally wrong for an individual (or company) to make an illegal copy of a piece of proprietary software? Here the question is one of what is right or wrong for an individual to do, given the law, and not a question of what the law should be. The policy issue centers on what the law should be and includes the following questions: Should computer software be private property? Does the extant system of copyright, patent, and trade secrecy protection adequately protect computer software? Does the system produce good consequences? I want to sketch positions on both of these issues taking the copying issue first, but recognizing that the two are somewhat interdependent.

2.0 Is It Wrong to Copy Proprietary Software?

The issue here must be clarified in at least two ways. First, making a backup copy of a piece of software (which you have purchased) for your own protection may not be illegal. Second, while I have labeled this the “individual” moral issue, it is not just an issue for individuals but applies as well to collective units such as companies, agencies, and institutions. The typical cases that I have in mind are the cases in which either you make a copy of a piece of proprietary software to give to a friend, or you borrow a piece of software from someone who has purchased it and you make a copy for your own use. These cases do not seem to differ significantly from the case in which a company buys a single copy of a piece of software and makes multiple copies for use within the company in order to avoid purchasing more.

The intuition that copying a piece of software is not wrong is understandable. Making a copy of a piece of proprietary software is easy, seems harmless, and the laws aimed at preventing it seem ill-suited for doing the job. Nevertheless, when I examine the arguments that are made (or might be made) to support the conclusion, I find that I can not “buy in.” I am compelled to conclude that it is morally wrong to make an illegal copy of a piece of software, because it is illegal. The key issue here has little to do with software per se, and everything to do with the relationship between law and morality.

Perhaps the best way to begin is by laying out what I take to be the strongest arguments for the moral permissibility of individual copying. The strongest arguments claim (1) that the laws protecting computer software are bad, and, then, either: (2a) making a copy of a piece of software is not intrinsically wrong, or (2b) making a copy of a piece of software does no harm, or (2c) not making a copy of a piece of software may do some harm.

I will address premise (1) in the next section of this paper when I examine complaints about the law. For now, however, it is important to get clear on what might be claimed in premise (1). Here are some of the possibilities: (1a) all property law in America is unjust and the software laws are part of this; (1b) all intellectual property laws are unjust and software laws are part of this; (1c) most property law in America is just, but the laws surrounding computer software are not; (1d) while the laws surrounding the ownership of software are not unjust, they could be a lot better. The list could go on and just which position one holds makes much of the difference in the copying argument.

I do not want to take the time to run through these arguments so I am going to short-cut my argument here by just proclaiming that my position (to be elaborated in the next section) is that the system of intellectual property rights in America (in particular the patent and copyright systems) may not be the best of all possible systems in every detail, but both copyright and patent law have good ends and aim at the right balance between what can and what cannot be owned. In other words, while I recognize that the extant system of copyright and patent protection for software could be improved, I do not believe that these systems of law are blatantly unjust or wholly inappropriate for computer software.

The next step in my argument is to claim that an individual has a prima facie obligation to obey the laws of a roughly just system of law. “Prima facie” means “all things being equal” or “unless there are overriding reasons.” The prima facie obligation to obey the law can be overridden by higher order obligations or by special circumstances which justify disobedience. Higher order obligations will override when, for example, obeying the law will lead to greater harm than disobeying. Higher order obligations may even require civil disobedience. That is, if the law is immoral, then disobedience is morally obligatory. Special circumstances can justify disobedience to an otherwise good law when harm will come from obeying the law this one time. For example, the law prohibiting one to drive on the left side of the road is a good law, but one would be justified in breaking it in order to avoid hitting someone.

So I am not claiming that one always has an obligation to obey the law. I argue only that the burden of proof is on those who would disobey roughly good laws.

Given that extant laws regarding computer software are roughly good, which I am simply proclaiming for the moment, and given that one has a prima facie obligation to obey roughly good laws, the second premise carries the weight of any argument for the moral permissibility of copying. Hence premises (2a) – (2c) have to be examined carefully.

I agree with premise (2a) that there is nothing intrinsically wrong with making a copy of a piece of software. If there were no laws against it, such acts would not be wrong. Indeed, I have argued elsewhere that property rights are not natural or moral in themselves (Johnson, forthcoming). They acquire moral significance only when they are created by law and only in relatively just systems of law. However, premise (2a) does not support the argument for copying because copying has been made illegal and as such it is prima facie wrong.

According to premise (2b) making a copy of a piece of software for personal use harms no one. If we think of copying taking place, as in (2a), in a state of nature, this premise appears to be true, i.e., no one is harmed. However, once we are in a society of laws, the laws create legal rights, and it seems that one harms others by depriving them of their legal rights. When one makes a copy of a piece of software, one deprives the owner of the legal right to control the use of that software and to require payment in exchange for the use of the software, and this is a harm. Those who think this is not a harm should talk to small software companies or individual entrepreneurs who have gone into the business of developing software, invested time and money, only to be squeezed out of business by customers who buy one copy and make others instead of buying more. So, premise (2b) is false in that making a copy of a piece of software does harm someone.

Premise (2c) has the most promise, for if it were true that one would actually be doing harm by obeying the law, then one might have a moral reason for overriding the law, even if it were relatively good. Richard Stallman (1990) and Helen Nissenbaum (1991) have both made arguments of this kind. Both argue that there are circumstances in which not making a copy or not making a copy and providing it to a friend does some harm. However, in their arguments, the harm referred does not seem of the kind to counterbalance the effects of a relatively just system of property rights. Both give examples of how an individual might be able to help a friend out by providing an illegal copy of a piece of proprietary software. Both argue that this discourages altruism. But, this argument ignores the harm to the copyright or patent holder.

Even if I were to grant that not providing a copy to a friend is doing harm, we have to compare the harms and choose the lesser. Given what I said above about the prima facie obligation to obey the law, it follows that there may be some situations in which copying will be justified, namely when some fairly serious harm can only be prevented by making an illegal copy of a piece of proprietary software and using it. In most cases, however, the claims of the software owner to her legal rights would seem to be much stronger than the claims of someone who needs a copy to make her life easier.

If the position I have just sketched seems odd, consider an analogy with a different sort of property. Suppose I own a private swimming pool and I make a living by renting the use of it to others. I do not rent the pool everyday and you figure out how to break in undetected and use the pool when it is not opened and I am not around. The act of swimming is not intrinsically wrong, and swimming in the pool does no obvious harm to me (the owner) or anyone else. Nevertheless, you are using my property without my permission. It would hardly seem a justification for ignoring my property rights if you claimed that you were hot and the swim in my pool made your life easier. Similarly, if you argued that you had a friend who was very uncomfortable in the heat and you, having the knowledge of how to break into the pool, thought it would be selfish not to use that knowledge to help your friend out.

Of course, there are circumstances under which your illegal entry into my pool might be justified. For example, if someone else had broken in, was swimming, and began to drown. You were innocently walking by, saw the person drowning, and broke in, in order to save the other. Here the circumstances justify overriding my legal rights.

There seems to be no moral difference between the two cases. Breaking into the pool and making a copy of a proprietary piece of software are both acts which violate the legal rights of the owner. And, they are legal rights created by reasonably good laws. I will grant that these laws do prevent others from acting altruistically, but this, I believe, is inherent to private property. Private property is individualistic, exclusionary, and, perhaps, selfish. So, if Stallman and Nissenbaum want to launch an attack on all private property laws, I am in sympathy with their claims. However, I would press them to explain why they had picked out computer software law when private ownership of other things, such as natural resources or corporate conglomerates, seem much more menacing.

I conclude that it is prima facie wrong to make illegal copies of proprietary software because to do so is to deprive the owners of their legal rights, and this is to harm them. I admit that this has been a sketchy discussion of a topic that needs much more attention, but it is a topic that needs to be put on the table here.

3.0 Is Our System of Copyright and Patent Protection for Computer Software Good?

To put the policy issue in a moral or value framework, let me begin by saying that while in earlier work (Johnson, 1985), I toyed with moral arguments supporting the ownership of software, namely a Lockean labor theory argument, I now believe that property rights do not have a moral basis in the sense that they would exist prior to a society of laws. That is, I believe that property rights are social or conventional or artificial. This is entirely consistent with copyright and patent law in this country for both these systems of law are utilitarian in character. Both systems aim to produce good consequences for society in the long run. Debate and discussion about what the law should be with regard to computer software should, then, be framed in utilitarian theory.

In the late 1970s and early 1980s, a good deal of concern was being expressed that neither copyright nor patent law would adequately protect computer software. A sizable literature described the extent and impact of software piracy and illegal copying, and expressed fear that software development would be significantly impeded because software companies would not be able to recover the costs of development, let alone, profit from their creations. The incentive to create would be significantly dampened.

In the late 1980s and early 1990s, more and more concern is being expressed that there is too much protection for computer software, that is, that too much has become proprietary. The concern now is that copyright and patent protection are being extended too far. They now get in the way of software development (Kahin, 1991).

This shift of concern goes to the heart of the aims of our intellectual property laws, for both copyr

3.1 Patents

The shift in concern about patent protection on software from the early 1980s to the early 1990s can be traced to a shift in the policies and practices of the Patent Office and the Court of Customs and Patent Appeals (CCPA) after the Diamond v Diehr case (Samuelson, 1990). Up until Diamond v Diehr the Patent Office had been extremely reluctant to grant patents on computer-related claims, though its reluctance had been challenged by the CCPA. After Diamond v Diehr the Patent Office began granting patents and the CCPA found new reasons to grant more. While only a handful of software related patents had been granted before Diamond v Diehr, several thousand have probably been granted since (Kahin, 1990).

The new concerns about patent protection on software go to the heart of the patent system’s aim, for they suggest that because so much is owned, invention is now being inhibited. The subject matter limitation on what can be patented aims to insure that the building blocks of science and technology should not be owned so that continued development will flourish, yet complaints suggest that the building blocks may now be owned.

The situation is described roughly as follows: Because so many patents have been granted, before putting new software on the market, one must do an extensive and expensive patent search. If overlapping patents are found, licenses must be bought. Even if no overlapping patents are found, there is always the risk of late issuing patents. Patent searches are not guaranteed to identify all potential infringements because the Patent Office has a poor classification system for software. Hence, there is always the risk of lawsuit due to patent infringement. One may invest a great deal in developing a product, invest even more in a patent search, and then find at the last minute that the new product infringes on something already claimed. These factors make software development a risky business and constitute barriers to development of new software. In particular the costs and risks are barriers to small entrepreneurs.

I have argued elsewhere that computer algorithms should not be patentable and these criticisms lend support to that position. Depending on how the term “algorithm” is defined, these criticisms suggest that an even broader subject matter limitation for program-related patent claims should be implemented. Stallman proposes that we pass a law that excludes software from the domain of patents. Samuelson argues that the Patent Office and the CCPA have overextended the meaning of the Supreme Court’s decision in the Diamond v Diehr case.

3.2 Copyrights

The situation with regard to copyright is less clear and I am not going to spend as much time on it. Copyright protection has the legal advantage that the Copyright Act was amended in 1980 to explicitly specify that it applies to computer software. On the other hand, the meaning of copyright protection is unclear in the sense that it is not clear what aspect of a piece of software you own. The focus of attention has been on a number of aspects of software which are roughly classified as “look and feel.”

Copyright protection is easier to acquire in the sense that if you develop a new system on your own, even though the new software may duplicate something already copyrighted, you do not infringe as long as you were unfamiliar with the copyrighted program while you were developing your own. This is an advantage from the point of view of acquiring protection, but a disadvantage in that the protection you acquire is weak.

It is becoming increasingly apparent that the idea/expression distinction which is the conceptual heart of copyright law may not be adequate to handle computer software. The uncertainty of the application of copyright law is itself enough to get in the way of development in the field.

3.3 Not Bad Laws

Note that these criticisms of patent and copyright protection are not directed at the fundamental character of the laws. The aims and strategies of copyright and patent law seem right on target in seeking to create an environment in which invention can flourish. In this respect they are not bad laws. But while their aims are right, they seem to lack the conceptual tools to handle the issues posed by computer technology. It appears that copyright law and patent law will have to be modified or abandoned for computer-related invention.

4.0 Is Policy Change Called For?

In recent years a number of recommendations have been made for changes in the protection of computer software? Pamela Samuelson has, perhaps, done the most thorough job of identifying the alternatives. In her Emory Law Journal (1990) article, she outlines four possible changes. They are: (1) rely on Copyright alone; (2) limit software patents to traditional industrial processes and machines; (3) accept an expansion of the patent subject matter limitation and work out a patent/copyright interface for programs; and (4) develop sui generis legislation for the protection of computer programs. Samuelson examines the advantages and disadvantages of each, but it is not at all clear which is the best.

Whatever changes one supports, it seems clear that we must keep in mind that our ends should be the same as those of the patent and copyright systems, to create an environment in which creativity and invention are encouraged and facilitated.

Rensselaer Polytechnic Institute

References

Deborah G. Johnson, “A Reply to ‘Should Computer Programs Be Ownable?’” Metaphilosophy, Vol. 24, 1993, pp. 85 – 90.

Deborah G. Johnson, Computer Ethics,Prentice-Hall, 1985.

Brian Kahin, “The Case Against ‘Software Patents’,” unpublished paper.

Helen Nissenbaum, “Should I Copy My Neighbor’s Software?” Computing & Philosophy, forthcoming.

Pamela Samuelson, “Benson Revisited: The Case Against Patent Protection for Algorithms and Other Computer Program-Related Inventions,” Emory Law Journal, Vol. 39, No. 4, Fall 1990: 1025 – 1154.

Richard Stallman, conference paper, American Philosophical Association Meetings, December, 1990.

The Virtues of Software Ownership

Three broad approaches seem to dominate recent work in ethics: the consequentialist, the deontological, and the emphasis on character or virtue. The consequentialist approach evaluates an action (rule, policy, etc.) by its net consequences or effects. On this approach, for example, good policies are those which on balance do more good than harm for the people affected. The deontological approach, in contrast, appeals to universal principles on which a decision should be based rather than the actual outcome of that decision. On this approach, for example, a decision has moral worth if it respects a right, fulfills an obligation, or follows from a duty. Typically, such rights, obligations or duties have a universal and necessary quality; that is, they would hold for anyone in a given situation, even if undesirable consequences would result from recognizing them. Finally, the third approach (that of so-called “virtue ethics”) emphasizes long-term, habitual character-traits (virtues and vices) rather than actions, policies, or principles.

In her address (above), Johnson claims that “copyright and patent laws in this country… are utilitarian in character. Both systems aim to produce good consequences for society in the long run. Debate and discussion about what the law should be with regard to computer software should, then, be framed in utilitarian theory.” In my own work to date, I have likewise taken a consequentialist approach to intellectual property issues. I have argued, for instance, that if allowing some algorithms to be patented benefits society in the long run more than it costs society temporarily to forego unrestricted use of those algorithms, then such patents are morally defensible. I have taken a consequentialist approach largely because I believe that approach reflects the spirit and motivation of U.S. law more than the other two approaches do. In contrast, elsewhere in the world (among other signatories to the Berne Convention), intellectual property laws smack more of deontology. The French, for instance, appeal to what they call droits morals such as paternite – the inherent right of a creator to control the treatment of his or her creation, analogous to the alleged right that parents have with respect to their own children. On this approach, to infringe on a copyright is to violate a personal right, not merely to fail to uphold a social bargain.

On this occasion, however, I want to take the third approach, which emphasizes character traits, virtues. My reasons for taking this approach are twofold: First, of the three approaches just outlined, virtue ethics has the most venerable pedigree, tracing its development from the earliest days of philosophy among the ancient Greeks. (I suspect a similar pedigree may be found in nonwestern thought, but I am here focusing my attention on Western traditions of ethics.) Second is the belief that moral discourse should indicate not merely what is permissible but also what is noble. While I uphold the permissibility, the justification, of intellectual property laws applied to computational resources, I also applaud the nobility of a character like Richard Stallman’s. So, for example, I am both willing to defend AT&T’s rights to its Karmarkar algorithm and, at the same time, to challenge its executives, directors, and shareholders to be generous in permitting its liberal use. Since I am focusing on virtue ethics here, my concern is not so much for the goodness, fairness, and coherence of an intellectual property system – this is Johnson’s concern – as with the goodness, fairness, and integrity of individual persons. Systems, as analogues of persons, may have virtues, too, but my focus here will be on the characters of people.

Specifically, my guiding question is this: How might a virtue-centered ethics in the Aristotelian-Thomistic tradition bolster Stallman’s position philosophically? Several years ago (1987), Stallman gave a talk at the University of Texas, a transcript of which was widely circulated on e-mail lists and bulletin boards. In this talk he referred to “spiritual harm” which results from placing some intellectual property restrictions on software:

The spiritual harm comes from the nondisclosure agreements and licenses that people sign, because each buyer is asked to betray his neighbors. If you want to use a program and your neighbor wants to use the program, the Golden Rule says that you should want both of you to get that program. You shouldn’t aim for a solution where you get it and the other people don’t, if you want to be a good citizen, that is. And the nondisclosure agreement essentially says “I promise to be a bad citizen – I promise to say ‘To hell with my neighbors!’ To hell with everyone! Just give me a copy!” And you can see the spiritual effect that has on the community you live in.

I claim that what Stallman calls “spiritual harm” can be understood, and his thesis defended, in terms of the Aristotelian-Thomistic tradition’s virtue-centered ethics.

Aristotle claims that it is better (beltion) for acquisitions (tas kteseis) to be one’s own (idias), on the one hand, but on the other hand, to make them available to the public (koinas) with respect to their use (tei chresei – the cognate noun chreia and the root verb chraomai can connote poverty, need, or want; so we might expand the last phrase to read “with respect to their use by those in need”). He illustrates this claim with the example of Spartans who use one another’s slaves, horses, and dogs as if they were their own (hos eipein idiois), “even if they have occasion to lack supplies for a journey (ephodion – cf. the Latin viaticum) in the countryside.” Aristotle’s concern here is not so much with rights or benefits but with character – that is, with virtue. For immediately he goes on to say that it is a proper function of the lawgiver how citizens become people of this sort (ginontai toioutoi – that is, disposed to share their possessions). Later in the same passage he refers to the virtue of liberality (eleutheriotes) with respect to possessions (to peri tas kteseis): “To give favors and help to loved ones, guest-friends, or colleagues is the sweetest thing (hediston), and this is a consequence (ginetai) of the possession being one’s own (tes kteseos idias ouses).” He also notes, in defense of property, that evils attributed to it (such as litigation over breach of contract) are due not so much to the political, economic or legal system (i.e., the absence of communism – akoinonesia) as to human nature or character (wretchedness or wickedness – mochtheria).

Echoing Aristotle’s discussion, Aquinas asks whether someone may possess something as propriam – as one’s own. His answer to this question is a pair of theses, based on a distinction between (a) a power to manage and dispense (potestas procurandi et dispensandi) and (b) the use (usus) of external things (res exteriores). The first thesis is that with regard to the power to manage and dispense external things, a human being may possess propria. In fact, he says, humans not only may own things, in a certain sense they must (est etiam necessarium ad humanam vitam), for three reasons: (1) Everyone is more motivated, more anxious (magis sollicitus) to take care of something which concerns oneself alone than something shared by everybody or by a crowd. This reason has as its premise a belief about human laziness (laborem fugiens) to the effect that we are inclined to “let the other guy do it” when it comes to shared responsibilities. (2) Human affairs are conducted more ordinately (ordinatius) when an individual is saddled with responsibility for taking care of something than they are when anyone who wishes manages anything he wishes indiscriminately (indistincte). (3) Peace is better preserved when everybody is contented with his or her “own thing” (re sua), in contrast to a state of affairs in which people share something undivided. In the latter case, quarrels more frequently arise. It is interesting for our purposes here that the argument for property has a distinctly consequentialist flavor: If you want to get things done in a peaceful and orderly fashion, divide things up among individuals.

The second thesis, following Aristotle’s thought, introduces a more virtue-centered emphasis, however: With regard to use, a human being ought not to hold (habere) external things as propria but as communes (things shared in common). This is so that someone (aliquis) may more readily (de facile) share them when others need them. The concern here is not merely with meeting needs (consequences) but also (and perhaps more directly) with a character trait, namely, the disposition to help others. This disposition seems to involve both a cognitive habit (holding, that is, considering, external things as communes) and a conative one (the readiness to share). While this disposition itself can be valued for a consequentialist reason, namely, the likelihood that in cases of need at least someone will be willing to help the needy by sharing resources, the disposition is also valuable in itself, as a readiness or facility, even when needs don’t actually arise.

When the two theses are combined, Aquinas’ position is roughly this: Responsibility for material resources should be an individual matter, but access to them should be communal. This does not seem to be far from the socialist slogan, “From each according to his ability, to each according to his need.” Both views, the Thomistic and the socialist, seem to ascribe to individuals the burden but not the reward of property. Both views, to be plausible, need a theory of human motivation to undergird them. For the socialist, it may be Marxian doctrine that unalienated productive activity is desirable for its own sake, is its own reward, and indeed is the chief human need. For the Thomist or Aristotelian, it is the eudaimonistic value of virtue: That is, one must be virtuous in order to be happy. Insofar as we all want to be happy, we all have a motive for being virtuous. If virtue with regard to property involves both responsible management and willingness to share with others, then we have a motive for bearing these burdens of stewardship.

So what are the implications of the Aristotelian-Thomistic view for software ownership? A summary answer is that individual ownership can be a good thing insofar as it contributes to an incentive for software development (overcoming the tendency to “let the other guy do the work”), to an orderly division of labor, and to a settled understanding about what one can use and what is off limits. Stallman and others have pointed out many of the ways in which software ownership may in practice fail to optimize these desirable consequences, and these failures should be remedied. In principle, though, intellectual property in software is defensible.

At the same time, defense of property rights is only one side of the issue, and perhaps not the most important side. Another side of the issue, one that seems to call for more attention, is the challenge to owners (or rights-holders) to cultivate the virtues of ownership – what makes ownership excellent and noble, and not merely defensible. Noteworthy among these virtues is the disposition to regard software as destined for the public domain even while it enjoys the temporary protection of intellectual property law. This involves a disposition to put the needs of the public ahead of the desire for personal profit.

Many objections may be made to this view. I want to address one of them here. Adam Smith, in reference to the famous “invisible hand,” wrote:

By pursuing his own interest [the individual] frequently promotes that of the society more effectually than when he really intends to promote it. I have never known much good done by those who affected to trade for the public good. It is an affectation, indeed, not very common among merchants, and very few words need be employed in dissuading them from it.

If one really wants to benefit the public, one might argue, forget about Aristotelian-Thomistic virtue and appeal to the profit motive.

In light of the foregoing discussion, one may respond to this objection on many levels. First, benefiting the public may be a, or even the only, concern of consequentialist ethics, but it is not the only concern of ethics in general. Notions of rights, duties, obligations, character, virtue, motivation, and happiness must also be addressed. Secondly, Smith does not (nor does he intend to) give us a complete ethical theory here. He is not even offering (in this passage) a complete economic theory. He does not say that by pursuing his own interest the individual always, invariably, or even typically promotes that of the society more effectually than when he really intends to promote it. Rather, Smith says “frequently.” His tone his anecdotal ( “I have never known . . .”), not systematic. Indeed, his tone may be even be construed as sardonic (“It is an affectation, indeed, not very common among merchants, and very few words need be employed in dissuading them from it.”) In any case, mere affectation of concern for the public good is quite distinct from the actual virtue of stewardship, which is a thoroughgoing, stable, perduring disposition deeply involving the springs of motivation and therefore much more likely to be effective in contributing to the public good than mere affectation could ever be. So even if we confine our discussion to consequentialist ethics, the cultivation of Aristotelian-Thomistic virtue may be superior to the profit motive in maximizing social utility. Aquinas’ position, of course, depends on many presuppositions the discussion of which would take us far afield here, but so does Smith’s. The metaphysical reality of the “invisible hand” may be as elusive to empirical investigation as the summum bonum of Thomistic ethics. But to the extent that my response here is an invocation of the noble, Aquinas, I think, has the edge.

Whitman College

Footnotes

1. This is the approach which Johnson emphasizes in her address. The League for Programming Freedom’s section on the purpose of copyright (in “Against User Interface Copyright”) also reflects this approach and traces it to the U.S. Constitution. In that paper, the ten reasons against copyrights for user interfaces are predominantly consequentialist, as is the discussion of patents (e.g., the section called “The Fundamental Question.”)
2. This is the approach of what Johnson calls “Lockean labor theory.”
3. The League for Programming Freedom’s paper “Against Software Patents” (below) has persuaded me that many software patents ought not to have been granted and therefore should be invalidated, but I see no reason in principle why all algorithms should be excluded from patent protection; it may make sense to patent some algorithms or programs. The League for Programming Freedom partially agrees; they say, “we do not claim that every single software patent is necessarily harmful. Careful study might show that under certain specific and narrow conditions (necessarily excluding the vast majority of cases) it is beneficial to grant software patents.” Yet they think that in general software patents have been so harmful that “the right thing to do now is to eliminate all software patents as soon as possible, before more damage is done. The careful study can come afterward.”
4. Again, see the League for Programming Freedom’s section (below)on the purpose of copyright.
5. Called “the last of the hackers” by Steven Levy (Hackers: Heroes of the Computer Revolution (New York: Dell Publishing Co., 1984), “Epilogue”), he opposes software ownership on principle and has been working for years to develop a complete, top-quality software library known as “GNU” (a recursive acronym for “GNU’s Not UNIX”) and make it available to the world free of charge. Recently, The Wall Street Journal (in a special report on technology, May 20, 1991, pp. R23 – 24) described how his efforts were dealt a “major blow” earlier this year by AT&T – I take it, over patent number 4,555,775, “covering the use of ‘backing store’ in a window system that lets multiple programs have windows.” (I’m referring here to the account in “Against Software Patents” – although the paper modestly declines to mention Stallman by name but refers instead to “computer companies distributing the free X Window System” and MIT.
6. Perhaps the most successful attempt, and certainly the most famous, to parallel the virtues of a system with the virtues of individual persons is Plato’s Republic. The concept of virtue that unfolds in that work significantly influences the Aristotelian-Thomistic tradition in which I situate my argument here.
7. Politics, 1263a, 35ff.
8. Ibid.
9. “Utrum liceat alicui rem aliquam quasi propriam possidere.” Summa Theologiae, II – II, Q. 66, A.2.
10. The Wealth of Nations (New York: The Modern Library, 1937), p. 423.

References

Saint Thomas Aquinas, Summa Theologiae (Ottawa: Instituti Studiorum Medievalium Ottaviensis, 1941 – 45).

Aristotle, Aristotelis Opera, Academia Regia Borussica edition (Berlin: G. Reimerum, 1831 – 70).

Steven Levy, Hackers: Heroes of the Computer Revolution (New York: Dell Publishing Co., 1984).

Plato, Platonis Opera, Ioannes Burnet, ed. (Oxford: Clarendon Press, 1905 – 1913).

Adam Smith, The Wealth of Nations (New York: The Modern Library, 1937).

The Wall Street Journal (a special report on technology, May 20, 1991).

A Plea for Casual Copying

1.0 Casual Copying

Let me introduce the notion of casual copying and define it as follows:

An individual engages in casual copying when, having purchased a commercial software application (program), he or she duplicates the program in a private setting giving a copy to a friend or family-member.

2.0 Johnson’s Two Challenges

In Johnson’s discussion about personal copying, she questions whether casual copying is moral, arguing that it is not moral. I hold, and have also argued this elsewhere, that it is. Johnson opposes my position issuing two challenges:

1. It is unreasonable to target software property laws when private ownership of other things, such as natural resources or corporate conglomerates, seem much more menacing; and
2. Since the system of laws governing software ownership is “relatively just,” unauthorized copying is immoral because it violates the legal rights of property owners even if it is done in the name of altruism.

3.0 Property Rights Not Challenged

In her first challenge, Johnson has misinterpreted the intent of my argument about software property laws. Far from rejecting the grounds for private ownership of computer software, or for that matter any other property, I take as a working assumption that individuals do have the right to privately own property. However, the set of rights frequently defended for software owners is even more extensive than the equivalent rights accorded to owners of other forms of property. Far from being the poor relative, when it comes to protection of software under property law, software owners are particularly well-endowed. Furthermore, I charge that there are at least some cases – such as the case of a well-meaning person duplicating a program for a friend – for which this extra-protection is not morally defensible because while it responds to the interests of software owners, it fails to credit the competing demands of other individuals. In other words, I have not in general disputed private ownership of software, but rather, have argued that even if we assume there to be good grounds for defending private ownership in general, and private ownership of software in particular, casual copying is not immoral.

4.0 Is Casual Copying Immoral?

For the remainder of my time I respond to Johnson’s second challenge, that since the laws of software ownership are reasonably good, illegal acts of copying are immoral because they violate the legal rights of owners.

I will argue that my position has not been correctly interpreted; it is not a plea for the toleration for casual copying on the grounds that it is done to achieve noble ends, even though the copier breaks the law and violates the property rights of the software’s owner. It is not therefore equivalent to a justification of stealing for a good cause. Rather, it is the plea for toleration for casual copying on the grounds that casual copying does not violate morally grounded property rights.

If we assume property rights to be a bundle of rights defining a relationship between an owner and a piece of property we would in any given case want to circumscribe those rights that are justifiably within the bundle. Nozick’s knife example vividly illustrates this point in showing that while the owner of a knife can do with it what she pleases, she may not place it in another’s chest. While I would argue that placing the knife in another’s chest does not fall inside the boundary of the bundle of rights an owner has over her knife, it would seem that my opponents would argue that since owners have the right to fully determine the use and enjoyment of their property, these rights are violated by restriction. Presumably, they would agree that the violation is justified. Similarly in the case of software, I argue not for the violation of software-owner rights, but that the restriction of casual copying does not fall within the bundle of rights at all. The boundaries suggested by those who decry casual copying are too inclusive, delineating a set of rights for software owners that is not morally defensible (and consequently should not be protected in a system of reasonably just laws.) In summary, while I do not dispute whether program owners are entitled to property rights over software, I do dispute the moral boundary lines urged by Johnson and others.

4.1 The Civil Disobedience Question Finessed

I plan to sidestep the question of civil disobedience with respect to casual copying. Many of our systems of law and social convention are only more-or-less good. To take a trivial case, let’s assume that traffic analysts are correct in thinking that a system of rules allowing right turns on red lights works better than one that doesn’t. Then the system before the change was not as good as it could have been. I think we should always work to make laws as just as they can be, but it is not clear that in each less-than-optimal case civil disobedience is justified. The driver who realizes the wisdom of turning right on red probably ought not engage in acts of disobedience.

My approach in dealing with the question of casual copying is not to decide whether civil disobedience is the best course of action for improving the system of laws, but rather, for now, to imaginatively set aside existing law and assume we have the opportunity to determine the law, from scratch, as we see best.

4.2 Copying and Murder: Unauthorized Copying is Not a Moral Category

Software copying defines an action category and unlike murder does not also define a moral category. Murder refers to a subset of killing that is morally wrong, while there are other categories of killing that are not. Similarly we expect some copying to be morally permissible, others perhaps not. On one end – fairly unproblematic I assume – we find copying for archival purposes, copying of freeware and shareware; that is so-called “authorized copying.” Some seem to have drawn the line right there, urging that any other copying, in particular, copying that is not authorized by the program’s owner, is wrong. In so urging they are making the desire of the property owner the sole consideration determining whether an act of copying is right or wrong, thus saying that while copying is like killing, unauthorized copying is like murder. Johnson does not fall into this group.

Johnson recognizes at least one set of considerations that can override a software-author’s preferences, namely the consideration of what “aspect” of software is in question. How we determine ownership rights over software, and consequently, the moral status of copying, will depend on whether we are looking at object or source code, a basic algorithm, or the “look-and-feel.” For example, Johnson has urged a weak form of ownership over basic algorithms, one that would surely grant authorial credit to their discoverers, but would deny them patent rights. She argues that the bottom line here is not the preference of the author, but whether the underlying goals of private ownership over intellectual products – to stimulate and encourage creativity and invention – are optimized. Johnson, is not in principle opposed to unauthorized copying of at least some aspects of software.

I take this line of thinking one step further in that I urge that there are other factors, contextual ones, that can also override the preferences of software owners thereby giving rise to additional cases of morally permissible unauthorized copying. Returning to our killing analogy, we observe that acts of killing take on varying moral hues depending on contextual factors, most notably factors like whether the killer had been mortally threatened by the person killed. It would be an unjust system indeed that lumped all killings together in a legal category and did not discriminate finely enough to recognized the difference between murder and self-defense. Turning back to unauthorized copying, I suggest that casual copying is a subset of unauthorized copying that, because of morally relevant contextual factors, is not immoral.

4.3 Morally Relevant Contextual Factors

In our contentious cases of casual copying we observe that, on the one hand, the owner of the software (that is, the intellectual property owner), desires that the copy not be made arguing on the basis of her right to control, and profit from her software. On the other hand, the casual copier wants to make the copy arguing on the basis of a right to be free of interference in her private domain to fulfill the “normal” obligations of responsiveness and kindness to friends and family. It appears that the solution to these cases comes down to balancing between two sets of conflicting rights: on the one hand the rights of property owners to the “use and enjoyment of their property” and to limit others’ access to it. And on the other hand we weigh in the rights of others to freely carry out actions within the bounds of normalcy. Those who judge casual copying immoral are adjudicating in favor of the program owner’s demands. And this, I argue, is unreasonably unlike existing judgment in analogous cases with other forms of private property.

If we turn to other forms of private ownership, we find that it is common practice to limit the extent of control an owner has over property in the face of competing demands. (Such balancing of rights is not, of course, restricted to property rights only.) Thus, an urban dweller who owns a piece of property must subject construction proposals to a strict set of zoning and planning guidelines. The guidelines respond both to the rights of the other town dwellers as well as to other more abstract principles such as historical preservation, or “fittingness” with the rest of the neighborhood. A landlord’s desire to inspect his property is curtailed by the tenants competing right to privacy. A musician’s right to play on his trombone is restricted by a neighbor’s right to peace-and-quiet. Such balancing of rights is not, of course restricted to property rights only.

With casual copying, I submit that the right of the purchaser of consumer software to be free of interference in responding to personal obligations of kindness and generosity in the private domain should truncate the competing claim of the software owner to completely determine copying practice. That is, full determination over who can copy and when is no longer one among the bundle of rights accorded to software owners.

5.0 Two Objections and Rejoinders

I will discuss two objections to my position; the second of which is explicitly raised by Johnson in her comments.

5.1 In a Free Market Let the Market Decide Morality

Some have argued that in a free-market economy software owners have a right to place any conditions they please upon the sale of their product. Just as a lawnmower manufacturer could, as a condition of purchase, prohibit the lending of their lawnmower to neighbors, so a producer of a word processor can demand that no copies be made of the software except for archival backup, or could just as well demand that purchasers never use the software to write in favor of abortion. Consumers can express our objections to these terms by freely deciding not to buy the product. However, if they do buy, then they are morally obligated to carry out the stipulations.

5.1.1 Rejoinder: In Our Markets Individual Rights Are Protected

Even if in some “ideal” free-market economy world the conditions prescribed above would work, in the real world, and in current commercial and social context in which we live and in which we write, buy and sell software they are moot. Why? Because we treat the participation in public commerce as something of a privilege and demand that those who enter this domain play by certain “rules” and respect certain fundamental values. Whereas in the private domain, under the right to free association, an anti-Semite restaurant owner may refuse to allow Jews into her home, she can do no such thing in her place of business. We do not currently have an economy in which we leave to the free-market the adjudication of such matters of value.

In the case of commercial consumer-software, the sale occurs in the public, commercial, domain. We expect that those who participate in it will abide by certain norms, generally speaking ones that are mutually beneficial to both buyers and sellers. Sellers can expect a system in which their commercial interests are nurtured, while buyers can expect that basic rights and liberties will not be violated.

Consider another analogy which, while outside of the commercial domain, makes a similar point about the shifts in expectations from the private to the public domain. In our culture there are parts of our bodies designated “private” and related rules whose violation we take very seriously indeed. Thus you abhor the Peeping Tom who huddles under the window watching while you undress. However, should you choose to walk into a public building stark naked, you cannot demand that passersby avert their eyes so as not to violate your privacy, even though they will be observing the same body parts as the Peeping Tom. Similarly, when manufacturers place their products into the commercial realm for consumers to buy, insisting that the diskettes be bought and not copied, they are similar to the naked person insisting that passersby avert their eyes. Because manufacturers choose to place their products in the public domain, maximizing their commercial interest from exposure to consumers, they cannot at the same time expect to curtail or interfere with the “normal” behavior or their consumers.

Thus the protection of casual copying is a consequence of protecting consumer interests in the public commercial domain. It is worth noting that in legally protecting the will of software owners, we set up a ‘bad’ system of law that could only be enforced at a very high cost to individual freedom.

5.2 Stealing is Wrong; Even if Done For the Sake of Altruism

A second objection to casual copying, one raised today by Johnson, is that while altruism is surely a noble goal, being altruistic with stolen goods is not moral because the good produced almost never outweighs the harm done to the property owner.

5.2.1 Rejoinder: Casual Copying is Not Stealing

This objection is valid only if we can show that unauthorized copying is universally immoral; that is, that the only significant factor determining whether copying is moral is the desire of the program’s owner. In that case unauthorized copying would be analogous to stealing and the objection valid.

However, the assumption that the objectors make, and that is crucial to their conclusion, is the very issue I call into question. Earlier, drawing on examples from other domains for private ownership, I demonstrated that the control we accord owners over their property is not fully dictated by their desires, but tempered by other considerations. So, turning Johnson’s question back to her, why should software be different?

We appear to have reached a deadlock, with critics insisting that since the casual copying is not sanctioned by the owner, it must be immoral, and copiers claiming that their rights are being abridged by unreasonable restrictions. Is there a way out?

5.2.2 The Goal of Intellectual Property

I suggest that the way out of the deadlock is to look beyond owner preferences toward the very rationale for private ownership over intellectual property. Johnson offers a promising route in suggesting that the right to own software (a form of intellectual property) is not adequately grounded in “natural rights,” but rather in maximizing the general welfare. And the general welfare is maximized by ensuring an environment in which invention, productivity, and creativity will flourish.

Accordingly, when we determine the bundle of rights over software that we will come to identify as ownership rights, we take as the primary function the nurturing of the underlying value of a society in which creativity and invention are encouraged. Although frequently the bundle of rights will include the right to have all the owner’s preferences respected with regard to the use of the property, it need not always be so. Critics who insist that an owner’s preferences must always prevail make the mistake of identifying the owner’s preferences as the ends of intellectual ownership, and not simply one of the means of achieving the true end of intellectual ownership. Thus Johnson, in her discussion of algorithms, agrees that no matter what the preferences of the discoverer of a fundamental algorithm, patent rights are not morally justifiable.

Instead of stopping at the superficial picture of competing desires, we look beyond that and toward the enhancement of underlying social values. In evaluating the limits of software property rights, we must recognize that at stake are both the values of personal autonomy in the private domain and the creation of a climate that is conducive to productivity and invention. I submit that in the case of casual copying we are able to uphold personal autonomy while not significantly undermining our chances at an environment that stimulates creativity and invention. Put more bluntly, the closed scope of casual copying suggests only a minimal reduction in potential profits of software producers, while it realizes a significant need to respect the liberties and rights of consumers.

5.2.3 The Slippery Slope

Some opponents of casual copying argue that if we grant permission to casual copiers we open up a floodgate of copying. What about the more insidious and threatening forms of copying such as mass duplication of software by third parties for purposes of resale, making of multiple copies for free distribution, or even placing of software on a public file-server.

While I acknowledge the danger, I do not agree that judging casual copying morally acceptable implies the same for the other forms of copying. There are two, complementary reasons for this (for drawing the line): (i) because those forms of copying are bound to have significant detrimental impact on the commercial interest and consequently could threaten the underlying value of creativity and invention, while (ii) they do not involve countervailing claims analogous to those of the casual copier. Thus, I think we can reasonably place the prohibition of mass and impersonal copying within the boundary of property rights of software owners while placing the other, casual copying, outside of it.

It is interesting to note here the recent developments concerning laws governing the photocopying of written materials. In this domain, there is a move toward explicitly recognizing a distinction between personal copying and mass copying – making allowances for the former but outlawing the latter. This at least suggests that even if drawing the precise boundary between personal and mass copying is hard (and probably will not carry over precisely into the domain of software), it is a distinction that in principle is possible, and also a distinction that is worth respecting legally.

6.0 Conclusion

I have suggested that Johnson’s characterizing the existing system of software laws as relatively just is no more accurate than characterizing a system of laws relatively just that did not discriminate between killing in self-defense, and murder. Why? Because there are good reasons for viewing casual copying as morally justified copying, having to do with the enhancement of important social values.

While I do not question the moral basis for private ownership of software, I propose that we extend the base from which we deduce the bundle of rights that are properly accorded to software owners. In particular, in the case of casual copying, because it is done in fulfillment of perceived obligations to help, or to act responsibly to the needs of others close by, and because it does not significantly threaten the underlying goals of intellectual ownership, it should not be outlawed.

Princeton University

The Ownership of Ideas in Computing Software

A Contrast Between Trade Secrets, Copyrights, and Chip-Mask Protections

John W. Snapper

It is a cliché that federally mandated, intellectual property rights (e.g. patents and copyrights) do not confer ownership over ideas. Rather, they protect certain uses, applications, or expressions of ideas. It is also a cliché that trade secrecy does (in some contexts) amount to actual ownership of ideas. I argue that the cliché presents a false picture. The present argument emphasizes a version of the cliché found in the new Semiconductor Chip Protection Act (17 U.S.C. ##901 – 914 (1984)). A comparison of this law to copyright and trade secrecy law suggests that our intellectual property policies provide for greater and lesser amounts of ownership of ideas. There is minimal ownership of ideas under the SCPA registration, more under copyright registration, and more yet under trade secrecy protection. This is not the clichéd picture that draws a line between copyright and trade secrecy.

Ideas (as opposed to their applications or expressions) are owned to the extent that protections create obstacles to their discovery, to new research based on them, and to their dissemination. The present paper considers whether their are obstacles to reverse engineering of protected software and semiconductor chips. At issue is the methods that can be used to reverse engineer and the availability of those ideas for further research and development. The SCPA registration is fairly open to most methods: copyright is somewhat restrictive; and trade secrecy is very restrictive.

1.0 the Cliché

The SCPA protects chip masks (something like stencils for circuit or logic designs) that are (photographically) produced in computer chips. A mask registered under the SCPA may not be mechanically reproduced for use or for sale without permission of the owner. That SCPA rights do not protect ideas is asserted in section #902(c):

In no case does protection under this chapter for a mask work extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.

Substituting the phrase “original work of authorship” for “mask work,” exactly the same language appears in the 1976 Copyright Act (17 USCA #103b). These are pretty sentiments, but we should be puzzled by what, if anything, they mean. The common reader must wonder what ownership of an “idea” might be, how it differs from ownership of a chip mask, or why the lawmakers were so worried about a confusion of these two forms of ownership that they had to include the above paragraph in the statute.

The sentiments are given meaning in how they limit the rights that owners of chip masks may have under the SCPA. I interpret section #906, titled “Limitations on exclusive rights: reverse engineering; first sale,” as explaining the difference between owning a chip mask and owning the ideas that are embodied in it. In particular, #906a notes that it is permissible to do the following without infringing the rights of an owner of a chip:

(l) …reproduce the mask work solely for the purpose of teaching, analyzing, or evaluating the concepts or techniques embodied in the mask work or the circuitry, logic flow, or organization of components…; or (2)… incorporate the results [of that analysis] in an original masked work…

The language of #906 is also inspired by the Copyright Law, although there are significant differences. Most obviously, the SCPA has a fairly short discussion of the limitation of mask ownership, and the copyright law has a lengthy discussion, covering the whole range of copyrighted items from books to films to software, etc. The similarity to the Copyright Law is easiest to see in the opening general statement of limits on copyrights, #107, which states that it is “fair use” to make copies for “purposes such as criticism, comment, news reporting, teaching…. scholarship, or research.” It is the differences, however, between the limits on copyright and mask protections, as discussed below, which will lead to my conclusion that there is “more ownership of ideas” in copyright than in mask ownership.

In reading section #906 of the SCPA as an explanation of the bar on the ownership of ideas, I suggest that to prevent the teaching, analysis, or evaluation of a concept would be to own an idea. Although the statute does not explicitly say that #906 is an explication of #902, this is the natural reading of the statute, in parallel with the usual reading of the copyright law. The following argument further develops and justifies this view that the “ownership of ideas” amounts to restrictions on teaching, analysis, and evaluation of those ideas.

Although the limits on protections explain what it means to bar ownership of ideas, we must note that the presence in the statute of this explanation permits avoidance of the issue in the case law. Most judges, presented with a relevant copyright case, for instance, will naturally discuss it in the more precise terms of “fair use” than in terms of the rather vacuous remark that copyright does not protect ideas. The existence of the sections in the intellectual property statutes that explain what it means to bar ownership of ideas provides an opportunity to avoid discussion of what it means to own an idea. This is certainly a good thing for jurisprudence, but rather a bother for those who like to read philosophical discussions on the ownership of ideas. In fact, it makes much of the following discussions appear moot for legal purposes.

One area where there has been lengthy discussion of the difference between copyright ownership and idea ownership concerns the “merger of idea and expression” in copyright law. This happens when there are so few alternative ways to express an idea that a copyright would interfere with the opportunity for non-infringing statements of the ideas. If that happens, all copyright claims are invalid. In Apple v Franklin (714 F.2nd. 1240 (1983)), for instance, the court noted that if there are few ways to rewrite the Apple BIOS programs that are compatible with Apple’s hardware, then the Apple programs are uncopyrightable. Again, there is an intuitive connection between this insistence on the need for non-infringing statements of any idea and the note that copyright or mask ownership cannot interfere with the aims of analysis and education: both ensure appropriate dissemination of the ideas contained in copyrighted material. In contrast to the SCPA and Copyright Law, the Uniform Trade Secrets Act (now endorsed, with some variations, by most states) says (#1.3) that:

“trade secret” means information…

Whereas, the SCPA permits any activity done for the purpose of analyzing the contents of a mask, the UTSA forbids “improper means to acquire knowledge.” Whereas the SCPA permits all activities for the purpose of teaching the contents of a mask, the UTSA forbids “disclosure … of a trade secret.” Trade secrecy often prevents exactly what the SCPA endorses. It is these differences that lead most commentators to conclude that trade secrecy is a form of protection for ideas per se. (Similarly attitudes are found throughout that mishmash of legal traditions that are grouped together under the “trade secrecy” rubric.)

2.0 A Different Picture

It looks like we have two opposing traditions in intellectual property – one recognizing and the other eschewing the ownership of ideas. There are two issues here. On the one hand there is the issue of how we draw a line between ownership of ideas and the ownership that is granted in federal, intellectual property protections. On the other hand, there is the issue of whether there is a philosophical conflict between the aims of our federal protections and the ownership of ideas as exemplified in trade secrecy. We can see the difference clearly in a short diversion into patent policy.

Patent policy clearly depends on complementary features of trade secrecy policy. Patent policy has, in fact, greatly contributed to the use of trade secrecy: Since patentable material must be unfamiliar to industry at the time of the patent application, inventors who seek patents are expected to keep their work secret during development. All the same, not long ago, it looked as if the courts might find that federal patent policy conflicted with competing state trade secrecy policies. That view was decisively rejected in Kewanee v Bicron (416 U.S. 470 (1974)), which is the classic decision on the compatibility of patents and trade secrets. In that case, the court used the clichéd picture as a basis for finding ownership of ideas compatible with federal licensing policy. The Court suggested (although this was not the main argument) that trade secrets and patents do not conflict because they protect different things: ideas and applications of ideas.

On the other hand, the ownership of ideas is viewed as conflicting with federal licensing aims in a commonplace justification of patents as a social contract in which inventors exchange their secrets for monopolies over applications of their secrets. Some version of this “exchange for secrecy” argument appears in almost all discussions of patent law. (I am personally always surprised at the persistent popularity of the “exchange for secrecy” justification, given how patent policy has so encouraged trade secrecy in the R&D departments of corporations that plan to seek patents.) The purported line between ownership of patents and ownership of ideas has been used by both those who find a conflict between these forms of ownership and those who find them essential to each other. My claim, however, is that there are problems with the very distinction between the ownership of ideas and such ownership as is conferred by federal licensing.

Trade secrecy prevents the discovery and use of ideas in protected items. Copyright policy and the SCPA do not stand together in opposing trade secrecy restrictions on the discovery and dissemination of ideas. We can note the different extent to which they oppose the ownership of ideas by noting the extent to which reverse engineering (i.e. taking an item apart to see how it works) is discouraged or encouraged in chip-mask policy, copyright policy, and trade secrecy policy. Trade secrecy policy is clearly the extreme in discouraging reverse engineering. Copyright and mask registration have different standards for how we may reverse engineer and what we may do with what we discover.

Section #906 of the SCPA was clearly intended to address the issue of

reverse engineering. (Note its title.) This section, in fact, is meant to defend reverse engineering at a higher level than it is defended in copyright policy. This difference between copyright and mask registration is, for instance, a central point in Rep. Kastenmeier’s defense of the SCPA in a law review article (Kastenmeier and Remington, 70 Minnesota Law Review 426, 449 (1986)). Kastenmeier clearly thinks that by giving a stronger statement of the right of competitors to reverse engineer each other’s products, the SCPA has gone further than the copyright law in barring the ownership of ideas. The SCPA #906 addresses both the process of reverse engineering and the use of the results of reverse engineering. The two matters are deeply interconnected. Let us consider them in reverse order.

3.0 Using the Results of Reverse Engineering

Assuming that the informational content of a copyrighted work or mask-registered work has been legally acquired, one may “fix” that information in a “new work.” There are, however, different criteria for when the results are new. The result infringes a copyright if it is “substantially similar” to the original. It infringes a mask registration if it is “substantially identical” to the original. This difference is the focus of the only significant case to date on SCPA policy: Brooktree v A.M.D. (705 F. Supp. 491; 757 F. Supp 1088, 11O1). I will now give an interpretation of this difference, which was both supported and then rejected in Brooktree at various stages of the legal battle.

Copyright policy is that information contained in a copyrighted item may be used by a competitor if it is rewritten and not copied. Remember that (on the doctrine of a merger of idea and expression) certain simple expressions may be expected to appear naturally in a rewritten manuscript. Whether a new version is too close to the original is sometimes hard to determine, and cannot be shown simply on the basis of natural coincidence. One way used by the software industry to assure that a new version is truly rewritten (and that all similarities are coincidental) is to recreate copyrighted software in a “clean room.” The idea is that a team of engineers reverse engineers the copyrighted, meant-for-machine software and puts the contents into some meant-for-humans language. A second team writes new meant-for-machine software based on that meant-for-humans version. If the second team does its work in a “clean room” that is uncontaminated by the original code, it cannot be copying that code. Any similarity between its software and the original is then probably entailed by the nature of the original’s content.

On my interpretation of the SCPA, any mask created by human effort, as opposed to mechanical reproduction, is non-infringing. On this interpretation, all one needs show to establish non-infringement is that the “new” mask was created by human effort following reverse engineering of the original chip. You need not bother with clean rooms. You need not worry about simply repeating the patterns of circuitry. Any human reproduction will result in at least slight alterations in the placement of circuits in the chip. Although such reproduction violates copyright standards, I think it is entirely in keeping with the intent of the SCPA. On this view, you can only achieve “substantial identity” by automated reproduction processes, e.g. by producing a mask directly from photographs of layers taken off a registered chip.

We may explain the difference by an analogy with copies of recorded music. An automated reproduction of a record is made by using a tape recorder. A non-automated reproduction is made by listening to the music, figuring out the score, and then taping a new performance that as closely as possible mimics the original. This violates the “substantial similarity” standard for copyrighted music. I do not think it would violate a “substantial identity” standard. This interpretation is suggested by Brooktree at 705 F. Supp. 494. But the claim gets a less favorable treatment in a JNOV plea by A.M.D. at Brooktree 757 F. Supp. 1092. (For an opposing view, see an article by H. Brown at 41 Syracuse L.R. 985 (1990).)

This difference is essential to our understanding of the cliché that copyrights or mask registrations do not grant ownership of ideas. The copyright law recognizes that protections which prevent the independent expression of ideas would amount to ownership of the idea (Morissey v Procter & Gamble, 379 F. 2nd 675 (1967)). We can reasonably view the whole notion of “substantial similarity” as an attempt to balance the non-ownership of ideas against the right of copyright owners. The SCPA’s tighter criterion for infringement provides a new interpretation of what it would mean to own an idea. In fact, the SCPA criterion for infringement may be viewed as an attack on the copyright version of the familiar cliché (See Kastenmeier at 70 Minnesota L.R. 449)

4.0 The Methods of Discovery in Reverse Engineering

The issue in Kewanee was whether the ideas behind an invention could be held as a trade secret during the patent application process and continue to be held as a trade secret if the application is denied. If there were a straightforward conflict between federal patent policy and state trade secrecy policy (one excluding and the other promoting the protection of ideas), then the federal policy might have “preempted” state law in this specific case. The preemption issue has also arisen for the copyright law in the context of computer software, and it will (we may assume) sooner or later also arise for chip registration. By comparing policy on how copyright and chip-registration, we can get a sense of the extent to which these forms of intellectual property extend to protections for ideas.

Prior to the use of copyrights for software, it is hard to imagine someone attempting to keep information secret while at the same time putting it into a copyrighted manuscript. The nature of the subject matter of copyrights precluded dual use of trade secrets and copyrights and thus precluded conflicts leading to disputes over preemption. This changed with copyrights on computer software. Computer software may be copyrighted while largely in machine executable form. It will then require considerable effort at reverse engineering to discover the algorithms contained in that functioning software. In fact, the copyright could be used to prevent discovery of secret information encoded in copyrighted software because the process of reverse engineering might involve steps of copying that infringe the copyright. I personally consider this an abomination of the copyright tradition (see Snapper, 5 Social Epistemology 78, l991). But I would not wish to predict the direction that the law will take in this area.

Dual use of copyrights and trade secrecy is presently much debated in the law reviews, as a form of the issue of “preemption.” It is entirely possible that we may see a new version of the argument used in Kewanee that justifies dual usage on the grounds that copyrights and trade secrets protect different things (the expression of ideas and ideas themselves). (This philosophically displeasing argument was used in Warrington Associates v Real-Time Engineering Systems (522 F. Supp. 369), although it does not have the weight in copyright law that it holds in patent law.) The dual usage of trade secrets and copyrights contemplated here is, in fact, much more extreme than that upheld in Kewanee. Kewanee considered the status of trade secrets in rejected patent claims. The copyright issue concerns the status of trade secrets in software with recognized copyrights. (This form of dual protection is clearly rejected by patent law. In White Consolidated v Vega Servo-Control the court refused to grant trade secret protection to software required for the operation of a patented machine, since patent law requires disclosure of all operational information; 713 F. 2d. 788 (1983).)

If developing copyright policy (a) recognizes dual protection of software as a trade secret and copyrighted code, and (b) further recognizes that copying involved in engineering may violate a copyright, then reverse engineering of copyrighted software will be severely limited. Some form of reverse engineering would still be possible. Software could be tested against certain conditions to see how it reacts, and inferences then drawn about its underlying algorithms. Duncan Davidson has called this “black box” reverse engineering, since the engineers never look internally into the code of the software. Davidson argues that reverse engineering of copyrighted software should be restricted to black box investigations, as not only the one form of reverse engineering that is clearly within the bounds of the law but also as a form of study that encourages R&D among competing firms (see 47 Univ. of Pittsburgh Law Review 1037 (1986)).

In contrast to the restrictions on reverse engineering that might be entailed by copyright policy, the SCPA #906 specifically and loudly endorses any form of reverse engineering for the discovery of all information held in a registered chip. Once again, this contrast with the copyright law is to a large extent the reason for the inclusion of that section. On the other hand, the fact that information has been placed into a registered chip need not exclude its continued protection as a trade secret for some period. By so strongly promoting reverse engineering, the SCPA tacitly admits that there may be secrets in a chip mask. I therefore conclude that the SCPA clearly does not preempt simultaneous use of trade secrets, such as is debated in copyright law. Imagine for instance, that a chip is registered and available for reverse engineering. But a competitor, rather than spend the year needed to reverse engineer, learns the information from an employee of the chip owner. Could the chip owner sue for lost profits for the one-year period, claiming misappropriation of a secret? (The analogous situation in copyright law would be complicated if copyrights are found to preempt trade. A suit for unfair trade practice might still be possible, although it is unlikely to be viewed as misappropriation.)

The SCPA makes a point of spelling out the relation between its protection and trade secrets differently than in developing copyright policy. It is conceivable that Congress’s explicit discussion of these points in the SCPA will be seen by the courts as justification for a looser interpretation of the copyright preemption issue. The argument is that since Congress has decided not to address the issue for copyrights like it did for chips, Congress must have intended a different standard. (I hope we do not, in fact, see this bad argument made by the courts.) But in any event, the differences between copyright and chip law illustrate the wide range of give and take in what we interpret as a conflict between federally mandated intellectual property and the ownership of ideas.

Illinois Institute of Technology

Why Software Should Be Free: A Free Software Foundation Paper

Introduction

Richard Stallman

The existence of software inevitably raises the question of how decisions about its use should be made. For example, suppose one individual who has a copy of a program meets another who would like a copy. It is possible for them to copy the program; who should decide whether this is done? The individuals involved? Or another party, called the “owner”?

Software developers typically consider these questions on the assumption that the criterion for the answer is to maximize developers’ profits. The political power of business has led to the government adoption of both this criterion and the answer proposed by the developers: that the program has an owner, typically a corporation associated with its development.

I would like to consider the same question using a different criterion: the prosperity and freedom of the public in general.

This answer cannot be decided by current law – the law should conform to ethics, not the other way around. Nor does current practice decide this question, although it may suggest possible answers. The only way to judge is to see who is helped and who is hurt by recognizing owners of software, why, and how much. In other words, we should perform a cost-benefit analysis on behalf of society as a whole, taking account of individual freedom as well as production of material goods.

In this essay, I will describe the effects of having owners, and show that the results are detrimental. My conclusion is that programmers have the duty to encourage others to share, redistribute, study and improve the software we write: in other words, to write free software, the word “free” in “free software” refers to freedom, not to price; the price paid for a copy of a free program may be zero, or small, or (rarely) quite large.

How Owners Justify Their Power

Those who benefit from the current system where programs are property offer two arguments in support of their claims to own programs: the emotional argument and the economic argument.

The emotional argument goes like this: “I put my sweat, my heart, my soul into this program. It comes from me, it’s mine!”

This argument does not require serious refutation. The feeling of attachment is one that programmers can cultivate when it suits them; it is not inevitable. Consider, for example, how willingly the same programmers usually sign over all rights to a large corporation for a salary; the emotional attachment mysteriously vanishes. By contrast, consider the great artists and artisans of medieval times, who didn’t even sign their names to their work. To them, the name of the artist was not important. What mattered was that the work was done – and the purpose it would serve. This view prevailed for hundreds of years.

The economic argument goes like this: “I want to get rich (usually described inaccurately as ‘making a living’), and if you don’t allow me to get rich by programming, then I won’t program. Everyone else is like me, so nobody will ever program. And then you’ll be stuck with no programs at all!” This threat is usually veiled as friendly advice from the wise. I’ll explain later why this threat is a bluff. First I want to address an implicit assumption that is more visible in another formulation of the argument.

This formulation starts by comparing the social utility of a proprietary program with that of no program, and then concludes that proprietary software development is, on the whole, beneficial, and should be encouraged. The fallacy here is in comparing only two outcomes – proprietary software vs no software – and assuming there are no other possibilities.

Given a system of intellectual property, software development is usually linked with the existence of an owner who controls the software’s use. As long as this linkage exists, we are often faced with the choice of proprietary software or none. However, this linkage is not inherent or inevitable; it is a consequence of the specific social/legal policy decision that we are questioning: the decision to have owners. To formulate the choice as between proprietary software Vs no software is begging the question.

The Argument Against Having Owners

The question at hand is, “Should development of software be linked with having owners to restrict the use of it?”

In order to decide this, we have to judge the effect on society of each of those two activities independently: the effect of developing the software (regardless of its terms of distribution), and the effect of restricting its use (assuming the software has been developed). If one of these activities is helpful and the other is harmful, we would be better off dropping the linkage and doing only the helpful one.

To put it another way, if restricting the distribution of a program already developed is harmful to society overall, then an ethical software developer will reject the option of doing so.

To determine the effect of restricting sharing, we need to compare the value to society of a restricted (i.e., proprietary) program with that of the same program, available to everyone. This means comparing two possible worlds.

This analysis also addresses the simple counter-argument sometimes made that “the benefit to the neighbor of giving him or her a copy of a program is canceled by the harm done to the owner.” This counter-argument assumes that the harm and the benefit are equal in magnitude. The analysis involves comparing these magnitudes, and shows that the harm is much greater.

To elucidate this argument, let’s apply it in another area: road construction.

It would be possible to fund the construction of all roads with tolls. This would entail having toll booths at all street corners. Such a system would provide a great incentive to improve roads. It would also have the virtue of causing the users of any given road to pay for that road. However, a toll booth is an artificial obstruction to smooth driving – artificial, because it is not a consequence of how roads or cars work.

Comparing free roads and toll roads by their usefulness, we find that (all else being equal) roads without toll booths are cheaper to construct, cheaper to run, safer, and more efficient to use.1 In a poor country, tolls may make the roads unavailable to many citizens. The roads without toll booths thus offer more benefit to society at less cost; they are preferable for society. Therefore, society should choose to fund roads in another way, not by means of toll booths. Use of roads, once built, should be free.

When the advocates of toll booths propose them as merely a way of raising funds, they distort the choice that is available. Toll booths do raise funds, but they do something else as well: in effect, they degrade the road. The toll road is not as good as the free road; giving us more or technically superior roads may not be an improvement if this means substituting toll roads for free roads. Of course, the construction of a free road does cost money, which the public must somehow pay. However, this does not imply the inevitability of toll booths. We who must in either case pay will get more value for our money by buying a free road.

I am not saying that a toll road is worse than no road at all. That would be true if the toll were so great that hardly anyone used the road – but this is an unlikely policy for a toll collector. However, as long as the toll booths cause significant waste and inconvenience, it is better to raise the funds in a less obstructive fashion.

To apply the same argument to software development, I will now show that having “toll booths” for useful software programs costs society dearly: it makes the programs more expensive to construct, more expensive to distribute, and less satisfying and efficient to use. It will follow that program construction should be encouraged in some other way. Then I will go on to explain other methods of encouraging and (to the extent actually necessary) funding software development.

The Harm Done by Obstructing Software

Consider for a moment that a program has been developed, and any necessary payments for its development have been made; now society must choose either to make it proprietary or allow free sharing and use. Assume that the existence of the program and its availability is a desirable thing. One might regard a particular computer program as a harmful thing that should not be available at all, like the Lotus Marketplace database of personal information, which was withdrawn from sale due to public disapproval. Most of what I say does not apply to this case, but it makes little sense to argue for having an owner because the owner will make the program less available. The owner will not make it completely unavailable, as one would wish in connection with a program whose use is harmful.

Restrictions on the distribution and modification of the program cannot facilitate its use. They can only interfere. So the effect can only be negative. But how much? And what kind?

Three different levels of material harm come from such obstruction:

• Fewer people use the program.
• None of the users can adapt or fix the program.
• Other developers cannot learn from the program, or base new work on it.

Each level of material harm has a concomitant form of psycho-social harm. This refers to the effect that people’s decisions have on their subsequent feelings, attitudes and predispositions. These changes in people’s ways of thinking will then have a further effect on their relationships with their fellow citizens, and can have material consequences.

The three levels of material harm waste part of the value that the program could contribute, but they cannot reduce it to zero. If they waste nearly all the value of the program, then writing the program harms society by at most the effort that went into writing the program. Arguably a program that is profitable to sell must provide some net direct material benefit.

However, taking account of the concomitant psycho-social harm, there is no limit to the harm that proprietary software development can do.

Obstructing the Use of Programs

The first level of harm impedes the simple use of a program. A copy of a program has nearly zero marginal cost (and you can pay this cost by doing the work yourself), so in a free market, it would have nearly zero price. A license fee is a significant disincentive to use the program. If a widely-useful program is proprietary, far fewer people will use it.

It is easy to show that the total contribution of a program to society is reduced by assigning an owner to it. Each potential user of the program, faced with the need to pay to use it, may choose to pay, or may forego use of the program. When a user chooses to pay, this is a zero-sum transfer of wealth between two parties. But each time someone chooses to forego use of the program, this harms that person without benefiting anyone. The sum of negative numbers and zeros must be negative.

But this does not reduce the amount of work it takes to develop the program. As a result, the efficiency of the whole process, in delivered user satisfaction per hour of work, is reduced.

This reflects a crucial difference between copies of programs and cars, chairs, or sandwiches. There is no copying machine for material objects outside of science fiction. But programs are easy to copy; anyone can produce as many copies as are wanted, with very little effort. This isn’t true for material objects because matter is conserved: each new copy has to be built from raw materials in the same way that the first copy was built.

With material objects, a disincentive to use them makes sense, because fewer objects bought means less raw materials and work needed to make them. It’s true that there is usually also a startup cost, a development cost, which is spread over the production run. But as long as the marginal cost of production is significant, adding a share of the development cost does not make a qualitative difference. And it does not require restrictions on the freedom of ordinary users.

However, imposing a price on something that would otherwise be free is a qualitative change. A centrally-imposed fee for software distribution becomes a powerful disincentive.

What’s more, central production as now practiced is inefficient even as a means of delivering copies of software. This system involves enclosing physical disks or tapes in superfluous packaging, shipping large numbers of them around the world, and storing them for sale. This cost is presented as an expense of doing business; in truth, it is part of the waste caused by having owners.

Obstructing the Use of Programs

The first level of harm impedes the simple use of a program. A copy of a program has nearly zero marginal cost (and you can pay this cost by doing the work yourself), so in a free market, it would have nearly zero price. A license fee is a significant disincentive to use the program. If a widely-useful program is proprietary, far fewer people will use it.

It is easy to show that the total contribution of a program to society is reduced by assigning an owner to it. Each potential user of the program, faced with the need to pay to use it, may choose to pay, or may forego use of the program. When a user chooses to pay, this is a zero-sum transfer of wealth between two parties. But each time someone chooses to forego use of the program, this harms that person without benefiting anyone. The sum of negative numbers and zeros must be negative.

But this does not reduce the amount of work it takes to develop the program. As a result, the efficiency of the whole process, in delivered user satisfaction per hour of work, is reduced.

This reflects a crucial difference between copies of programs and cars, chairs, or sandwiches. There is no copying machine for material objects outside of science fiction. But programs are easy to copy; anyone can produce as many copies as are wanted, with very little effort. This isn’t true for material objects because matter is conserved: each new copy has to be built from raw materials in the same way that the first copy was built.

With material objects, a disincentive to use them makes sense, because fewer objects bought means less raw materials and work needed to make them. It’s true that there is usually also a startup cost, a development cost, which is spread over the production run. But as long as the marginal cost of production is significant, adding a share of the development cost does not make a qualitative difference. And it does not require restrictions on the freedom of ordinary users.

However, imposing a price on something that would otherwise be free is a qualitative change. A centrally-imposed fee for software distribution becomes a powerful disincentive.

What’s more, central production as now practiced is inefficient even as a means of delivering copies of software. This system involves enclosing physical disks or tapes in superfluous packaging, shipping large numbers of them around the world, and storing them for sale. This cost is presented as an expense of doing business; in truth, it is part of the waste caused by having owners.

Damaging Social Cohesion

Suppose that both you and your neighbor would find it useful to run a certain program. In ethical concern for your neighbor, you should feel that proper handling of the situation will enable both of you to use it. A proposal to permit only one of you to use the program, while restraining the other, is divisive; neither you nor your neighbor should find it acceptable.

Signing a typical software license agreement means betraying your neighbor: “I promise to deprive my neighbor of this program so that I can have a copy for myself.” People who make such choices feel internal psychological pressure to justify them, by downgrading the importance of helping one’s neighbors – thus public spirit suffers. This is psycho-social harm associated with the material harm of discouraging use of the program.

Many users unconsciously recognize the wrong of refusing to share, so they decide to ignore the licenses and laws, and share programs anyway. But they often feel guilty about doing so. They know that they must break the laws in order to be good neighbors, but they still consider the laws authoritative, and they conclude that being a good neighbor (which they are) is naughty or shameful. That is also a kind of psycho-social harm, but one can escape it by deciding that these licenses and laws have no moral force.

Programmers also suffer psycho-social harm knowing that many users will not be allowed to use their work. This leads to an attitude of cynicism or denial. A programmer may describe enthusiastically the work that he finds technically exciting; then when asked, “Will I be permitted to use it?”, his face falls, and he admits the answer is no. To avoid feeling discouraged, he either ignores this fact most of the time or adopts a cynical stance designed to minimize the importance of it.

Since the age of Reagan, the greatest scarcity in the United States is not technical innovation, but rather the willingness to work together for the public good. It makes no sense to encourage the former at the expense of the latter.

Obstructing Custom Adaptation of Programs

The second level of material harm is the inability to adapt programs. The ease of modification of software is one of its great advantages over older technology. But most commercially available software isn’t available for modification, even after you buy it. It’s available for you to take it or leave it, as a black box – that is all.

A program that you can run consists of a series of numbers whose meaning is obscure. No one, not even a good programmer, can easily change the numbers to make the program do something different.

Programmers normally work with the “source code” for a program, which is written in a programming language such as Fortran or C. It uses names to designate the data being used and the parts of the program, and it represents operations with symbols such as + for addition and – for subtraction. It is designed to help programmers read and change programs. Here is an example; a program to calculate the distance between two points in a plane:

double distance (p0, p1)
struct point p0, p1;

double xdist = p1.x – p0.x;
double ydist = p1.y – p0.y;
return sqrt (xdist * xdist + ydist * ydist);

Here is the same program in executable form, on the computer I normally use:
1314258944 –232267772 –231844864 1634862
1411907592 –231844736 2159150 1420296208
–234880989 –234879837 –234879966 –232295424
1644167167 –3214848 1090581031 1962942495
572518958 –803143692 1314803317

Source code is useful (at least potentially) to every user of a program. But most users are not allowed to have copies of the source code. Usually the source code for a proprietary program is kept secret by the owner, lest anybody else learn something from it. Users receive only the files of incomprehensible numbers that the computer will execute. This means that only the program’s owner can change the program.

A friend once told me of working as a programmer in a bank for about six months, writing a program similar to something that was commercially available. She believed that if she could have gotten source code for that commercially available program, it could easily have been adapted to their needs. The bank was willing to pay for this, but was not permitted to – the source code was a secret. So she had to do six months of make-work, work that counts in the GNP but was actually waste.

The MIT Artificial Intelligence lab received a graphics printer as a gift from Xerox around 1977. It was run by free software to which we added many convenient features. For example, the software would notify a user immediately on completion of a print job. Whenever the printer had trouble, such as a paper jam or running out of paper, the software would immediately notify all users who had print jobs queued. These features facilitated smooth operation.

Later Xerox gave the AI lab a newer, faster printer, one of the first laser printers. It was driven by proprietary software that ran in a separate dedicated computer, so we couldn’t add any of our favorite features. We could arrange to send a notification when a print job was sent to the dedicated computer, but not when the job was actually printed (and the delay was usually considerable). There was no way to find out when the job was actually printed; you could only guess. And no one was informed when there was a paper jam, so the printer often went for an hour without being fixed.

The system programmers at the AI lab were capable of fixing such problems, probably as capable as the original authors of the program. Xerox was uninterested in fixing them, and chose to prevent us, so we were forced to accept the problems. They were never fixed.

Most good programmers have experienced this frustration. The bank could afford to solve the problem by writing a new program from scratch, but a typical user, no matter how skilled, can only give up.

Giving up causes psycho-social harm – to the spirit of self-reliance. It is demoralizing to live in a house that you cannot rearrange to suit your needs. It leads to resignation and discouragement, which can spread to affect other aspects of one’s life. People who feel this way are unhappy and do not do good work.

Imagine what it would be like if recipes were hoarded in the same fashion as software. You might say, “How do I change this recipe to take out the salt?”, and the great chef would respond, “How dare you insult my recipe, the child of my brain and my palate, by trying to tamper with it? You don’t have the judgment to change my recipe and make it work right!”

“But my doctor says I’m not supposed to eat salt! What can I do? Will you take out the salt for me?”

“I would be glad to do that; my fee is only $50,000.” Since the owner has a monopoly on changes, the fee tends to be large. “However, right now I don’t have time. I am busy with a commission to design a new recipe for ship’s biscuit for the Navy Department. I might get around to you in about two years.”

Obstructing Custom Adaptation of Programs

The second level of material harm is the inability to adapt programs. The ease of modification of software is one of its great advantages over older technology. But most commercially available software isn’t available for modification, even after you buy it. It’s available for you to take it or leave it, as a black box – that is all.

A program that you can run consists of a series of numbers whose meaning is obscure. No one, not even a good programmer, can easily change the numbers to make the program do something different.

Programmers normally work with the “source code” for a program, which is written in a programming language such as Fortran or C. It uses names to designate the data being used and the parts of the program, and it represents operations with symbols such as + for addition and – for subtraction. It is designed to help programmers read and change programs. Here is an example; a program to calculate the distance between two points in a plane:

double distance (p0, p1)
struct point p0, p1;

double xdist = p1.x – p0.x;
double ydist = p1.y – p0.y;
return sqrt (xdist * xdist + ydist * ydist);

Here is the same program in executable form, on the computer I normally use:
1314258944 –232267772 –231844864 1634862
1411907592 –231844736 2159150 1420296208
–234880989 –234879837 –234879966 –232295424
1644167167 –3214848 1090581031 1962942495
572518958 –803143692 1314803317

Source code is useful (at least potentially) to every user of a program. But most users are not allowed to have copies of the source code. Usually the source code for a proprietary program is kept secret by the owner, lest anybody else learn something from it. Users receive only the files of incomprehensible numbers that the computer will execute. This means that only the program’s owner can change the program.

A friend once told me of working as a programmer in a bank for about six months, writing a program similar to something that was commercially available. She believed that if she could have gotten source code for that commercially available program, it could easily have been adapted to their needs. The bank was willing to pay for this, but was not permitted to – the source code was a secret. So she had to do six months of make-work, work that counts in the GNP but was actually waste.

The MIT Artificial Intelligence lab received a graphics printer as a gift from Xerox around 1977. It was run by free software to which we added many convenient features. For example, the software would notify a user immediately on completion of a print job. Whenever the printer had trouble, such as a paper jam or running out of paper, the software would immediately notify all users who had print jobs queued. These features facilitated smooth operation.

Later Xerox gave the AI lab a newer, faster printer, one of the first laser printers. It was driven by proprietary software that ran in a separate dedicated computer, so we couldn’t add any of our favorite features. We could arrange to send a notification when a print job was sent to the dedicated computer, but not when the job was actually printed (and the delay was usually considerable). There was no way to find out when the job was actually printed; you could only guess. And no one was informed when there was a paper jam, so the printer often went for an hour without being fixed.

The system programmers at the AI lab were capable of fixing such problems, probably as capable as the original authors of the program. Xerox was uninterested in fixing them, and chose to prevent us, so we were forced to accept the problems. They were never fixed.

Most good programmers have experienced this frustration. The bank could afford to solve the problem by writing a new program from scratch, but a typical user, no matter how skilled, can only give up.

Giving up causes psycho-social harm – to the spirit of self-reliance. It is demoralizing to live in a house that you cannot rearrange to suit your needs. It leads to resignation and discouragement, which can spread to affect other aspects of one’s life. People who feel this way are unhappy and do not do good work.

Imagine what it would be like if recipes were hoarded in the same fashion as software. You might say, “How do I change this recipe to take out the salt?”, and the great chef would respond, “How dare you insult my recipe, the child of my brain and my palate, by trying to tamper with it? You don’t have the judgment to change my recipe and make it work right!”

“But my doctor says I’m not supposed to eat salt! What can I do? Will you take out the salt for me?”

“I would be glad to do that; my fee is only $50,000.” Since the owner has a monopoly on changes, the fee tends to be large. “However, right now I don’t have time. I am busy with a commission to design a new recipe for ship’s biscuit for the Navy Department. I might get around to you in about two years.”

Obstructing Software Development

The third level of material harm affects software development. Software development used to be an evolutionary process, where a person would take an existing program and rewrite parts of it for one new feature, and then another person would rewrite parts to add another feature; in some cases, this continued over a period of twenty years. Meanwhile, parts of the program would be “cannibalized” to form the beginnings of other programs.

The existence of owners prevents this kind of evolution, making it necessary to start from scratch when developing a program. It also prevents new practitioners from studying existing programs to learn useful techniques or even how large programs can be structured.

Owners also obstruct education. I have met bright students in computer science who have never seen the source code of a large program. They may be good at writing small programs, but they can’t begin to learn the different skills of writing large ones if they can’t see how others have done it.

In any intellectual field, one can reach greater heights by standing on the shoulders of others. But that is no longer generally allowed in the software field – you can only stand on the shoulders of the other people in your own company.

The associated psycho-social harm affects the spirit of scientific cooperation, which used to be so strong that scientists would cooperate even when their countries were at war. In this spirit, Japanese oceanographers abandoning their lab on an island in the Pacific carefully preserved their work for the invading U.S. Marines, and left a note asking them to take good care of it.

Conflict for profit has destroyed what international conflict spared. Nowadays scientists in many fields don’t publish enough in their papers to enable others to replicate the experiment. They publish only enough to let readers marvel at how much they were able to do. This is certainly true in computer science, where the source code for the programs reported on is usually secret.

It Does Not Matter How Sharing Is Restricted

I have been discussing the effects of preventing people from copying, changing and building on a program. I have not specified how this obstruction is carried out, because that doesn’t affect the conclusion. Whether it is done by copy protection, or copyright, or licenses, or encryption, or ROM cards, or hardware serial numbers, if it succeeds in preventing use, it does harm.

Users do consider some of these methods more obnoxious than others. I suggest that the methods most hated are those that accomplish their objective.

Software Should be Free

I have shown how ownership of a program – the power to restrict changing or copying it – is obstructive. Its negative effects are widespread and important. It follows that society shouldn’t have owners for programs.

Another way to understand this is that what society needs is free software, and proprietary software is a poor substitute. Encouraging the substitute is not a rational way to get what we need.

Vaclav Havel has advised us to “Work for something because it is good, not just because it stands a chance to succeed.” A business making proprietary software stands a chance of success in its own narrow terms, but it is not what is good for society.

Why People Will Develop Software

If we eliminate intellectual property as a means of encouraging people to develop software, at first less software will be developed, but that software will be more useful. It is not clear whether the overall delivered user satisfaction will be less; but if it is, or if we wish to increase it anyway, there are other ways to encourage development, just as there are ways besides toll booths to raise money for streets. Before I talk about how that can be done, first I want to question how much artificial encouragement is truly necessary.

Programming is Fun

There are some lines of work that no one will enter except for money; road construction, for example. There are other fields of study and art in which there is little chance to become rich, which people enter for their fascination or their perceived value to society. Examples include mathematical logic, classical music, and archaeology; and political organizing among working people. People compete, more sadly than bitterly, for the few funded positions available, none of which is funded very well. They may even pay for the chance to work in the field, if they can afford to.

Such a field can transform itself overnight if it begins to offer the possibility of getting rich. When one worker gets rich, others demand the same opportunity. Soon all may demand large sums of money for doing what they used to do for pleasure. When another couple of years go by, everyone connected with the field will deride the idea that work would be done in the field without large financial returns. They will advise social planners to ensure that these returns are possible, prescribing special privileges, powers and monopolies as necessary to do so.

This change happened in the field of computer programming in the past decade. Fifteen years ago, there were articles on “computer addiction”: users were “onlining” and had hundred-dollar-a-week habits. It was generally understood that people frequently loved programming enough to break up their marriages. Today, it is generally understood that no one would program except for a high rate of pay. People have forgotten what they knew fifteen years ago.

When it is true at a given time that most people will work in a certain field only for high pay, it need not remain true. The dynamic of change can run in reverse, if society provides an impetus. If we take away the possibility of great wealth, then after a while, when the people have readjusted their attitudes, they will once again be eager to work in the field for the joy of accomplishment.

The question, “How can we pay programmers?” becomes an easier question when we realize that it’s not a matter of paying them a fortune. A mere living is easier to raise.

Funding Free Software

Institutions that pay programmers do not have to be software houses. Many other institutions already exist which can do this.

Hardware manufacturers find it essential to support software development even if they cannot control the use of the software. In 1970, much of their software was free because they did not consider restricting it. Today, their increasing willingness to join consortiums shows their realization that owning the software is not what is really important for them.

Universities conduct many programming projects. Today, they often sell the results, but in the 1970s, they did not. Is there any doubt that universities would develop free software if they were not allowed to sell software? These projects could be supported by the same government contracts and grants which now support proprietary software development.

It is common today for university researchers to get grants to develop a system, develop it nearly to the point of completion and call that “finished,” and then start companies where they really finish the project and make it usable. Sometimes they declare the unfinished version “free”; if they are thoroughly corrupt, they instead get an exclusive license from the university. This is not a secret; it is openly admitted by everyone concerned. Yet if the researchers were not exposed to the temptation to do these things, they would still do their research.

Programmers writing free software can make their living by selling services related to the software. I have been hired to port the GNU C compiler to new hardware, and to make user-interface extensions to GNU Amerces. (I offer these improvements to the public once they are done.) I also teach classes for which I am paid.

I am not alone in working this way; there is now a successful, growing corporation which does no other kind of work. Several other companies also provide commercial support for the free software of the GNU system. This is the beginning of the independent software support industry – an industry that could become quite large if free software becomes prevalent. It provides users with an option generally unavailable for proprietary software, except to the very wealthy.

New institutions such as the Free Software Foundation can also fund programmers. Most of the Foundation’s funds come from users buying tapes through the mail. The software on the tapes is free, which means that every user has the freedom to copy it and change it, but many nonetheless pay to get copies. (Recall that “free software” refers to freedom, not to price.) Some users who already have a copy order tapes as a way of making a contribution they feel we deserve. The Foundation also receives sizable donations from computer manufacturers.

The Free Software Foundation is a charity, and its income is spent on hiring as many programmers as possible. If it had been set up as a business, distributing the same free software to the public for the same fee, it would now provide a very good living for its founder.

Because the Foundation is a charity, programmers often work for the Foundation for half of what they could make elsewhere. They do this because we are free of bureaucracy, and because they feel satisfaction in knowing that their work will not be obstructed from use. Most of all, they do it because programming is fun. In addition, volunteers have written many useful programs for us. (Recently even technical writers have begun to volunteer.)

This confirms that programming is among the most fascinating of all fields, along with music and art. We don’t have to fear that no one will want to program.

What Do Users Owe to Developers?

There is a good reason for users of software to feel a moral obligation to contribute to its support. Developers of free software are contributing to the users’ activities, and it is both fair and in the long term interest of the users to give them funds to continue.

However, this does not apply to proprietary software developers, since obstructionism deserves a punishment rather than a reward.

We thus have a paradox: the developer of useful software is entitled to the support of the users, but any attempt to turn this moral obligation into a requirement destroys the basis for the obligation. A developer can either deserve a reward or demand it, but not both.

I believe that an ethical developer faced with this paradox must act so as to deserve the reward, but should also entreat the users for voluntary donations. Eventually the users will learn to support developers without coercion, just as they have learned to support public radio and television stations.

What Is Software Productivity?

If software were free, there would still be programmers, but perhaps fewer of them. Would this be bad for society?

Not necessarily. Today the advanced nations have fewer farmers than in 1900, but we do not think this is bad for society, because the few deliver more food to the consumers than the many used to do. We call this improved productivity. Free software would require far fewer programmers to satisfy the demand, because of increased software productivity at all levels:
•Wider use of each program that is developed.
•The ability to adapt existing programs for customization instead of starting from scratch.
•Better education of programmers.
•The elimination of duplicate development effort.

Those who object to cooperation because it would result in the employment of fewer programmers, are actually objecting to increased productivity. Yet these people usually accept the widely-held belief that the software industry needs increased productivity. How is this?

“Software productivity” can mean two different things: the overall productivity of all software development, or the productivity of individual projects. Overall productivity is what society would like to improve, and the most straightforward way to do this is to eliminate the artificial obstacles to cooperation which reduce it. But researchers who study the field of “software productivity” focus only on the second, limited, sense of the term, where improvement requires difficult technological advances.

What Do Users Owe to Developers?

There is a good reason for users of software to feel a moral obligation to contribute to its support. Developers of free software are contributing to the users’ activities, and it is both fair and in the long term interest of the users to give them funds to continue.

However, this does not apply to proprietary software developers, since obstructionism deserves a punishment rather than a reward.

We thus have a paradox: the developer of useful software is entitled to the support of the users, but any attempt to turn this moral obligation into a requirement destroys the basis for the obligation. A developer can either deserve a reward or demand it, but not both.

I believe that an ethical developer faced with this paradox must act so as to deserve the reward, but should also entreat the users for voluntary donations. Eventually the users will learn to support developers without coercion, just as they have learned to support public radio and television stations.

What Is Software Productivity?

If software were free, there would still be programmers, but perhaps fewer of them. Would this be bad for society?

Not necessarily. Today the advanced nations have fewer farmers than in 1900, but we do not think this is bad for society, because the few deliver more food to the consumers than the many used to do. We call this improved productivity. Free software would require far fewer programmers to satisfy the demand, because of increased software productivity at all levels:

• Wider use of each program that is developed.
• The ability to adapt existing programs for customization instead of starting from scratch.
• Better education of programmers.
• The elimination of duplicate development effort.

Those who object to cooperation because it would result in the employment of fewer programmers, are actually objecting to increased productivity. Yet these people usually accept the widely-held belief that the software industry needs increased productivity. How is this?

“Software productivity” can mean two different things: the overall productivity of all software development, or the productivity of individual projects. Overall productivity is what society would like to improve, and the most straightforward way to do this is to eliminate the artificial obstacles to cooperation which reduce it. But researchers who study the field of “software productivity” focus only on the second, limited, sense of the term, where improvement requires difficult technological advances.

Is Competition Inevitable?

Is it inevitable that people will try to compete, to surpass their rivals in society? Perhaps it is. But competition itself is not harmful; the harmful thing is combat.

There are many ways to compete. Competition can consist of trying to achieve ever more, to outdo what others have done. For example, in the old days, there was competition among programming wizards – competition for who could make the computer do the most amazing thing, or for who could make the shortest or fastest program for a given task. This kind of competition can benefit everyone, as long as the spirit of good sportsmanship is maintained.

Constructive competition is enough competition to motivate people to great efforts. A number of people are competing to be the first to have visited all the countries on Earth; some even spend fortunes trying to do this. But they do not bribe ship captains to strand their rivals on desert islands. They are content to let the best person win.

Competition becomes combat when the competitors begin trying to impede each other instead of advancing themselves – when “Let the best person win” gives way to “Let me win, best or not.” Proprietary software is harmful, not because it is a form of competition, but because it is a form of combat among the citizens of our society.

Competition in business is not necessarily combat. For example, when two grocery stores compete, their entire effort is to improve their own operations, not to sabotage the rival. But this does not demonstrate a special commitment to business ethics; rather, there is little scope for combat in this line of business short of physical violence. Not all areas of business share this characteristic. Withholding information that could help everyone advance is a form of combat.

Business ideology does not prepare people to resist the temptation to combat the competition. Some forms of combat have been banned with antitrust laws, truth in advertising laws, and so on, but rather than generalizing this to a principled rejection of combat in general, executives invent other forms of combat which are not specifically prohibited. Society’s resources are squandered on the economic equivalent of factional civil war.

“Why Don’t You Move to Russia?”

In the United States, any advocate of other than the most extreme form of laissez-faire selfishness has often heard this accusation. For example, it is leveled against the supporters of a national health care system, such as is found in all the other industrialized nations of the free world. It is leveled against the advocates of public support for the arts, also universal in advanced nations. The idea that citizens have any obligation to the public good is identified in America with Communism. But how similar are these ideas?

Communism as it was practiced in the Soviet Union was a system of central control where all activity was regimented, supposedly for the common good, but actually for the sake of the members of the Communist party. And where copying equipment was closely guarded to prevent illegal copying.

The American system of intellectual property exercises central control over distribution of a program, and guards copying equipment with automatic copying protection schemes to prevent illegal copying.

By contrast, consider a system where people are free to decide their own actions; in particular, free to help their neighbors, and free to alter and improve the tools which they use in their daily lives. A system based on voluntary cooperation, and decentralization.

Clearly it is the software owners, if anyone, who ought to move to Russia.

The Question of Premises

I make the assumption in this paper that a user of software is no less important than an author, or even an author’s employer. In other words, their interests and needs have equal weight, when we decide which course of action is best.

This premise is not universally accepted. Many maintain that an author’s employer is fundamentally more important than anyone else. They say, for example, that the purpose of having owners of software is to give the author’s employer the advantage he deserves – regardless of how this may affect the public.

It is no use trying to prove or disprove these premises. Proof requires shared premises. So most of what I have to say is addressed only to those who share the premises I use, or at least are interested in what their consequences are. For those who believe that the owners are more important than everyone else, this paper is simply irrelevant.

But why would a large number of Americans accept a premise which elevates certain people in importance above everyone else? Partly because of the belief that this premise is part of the legal traditions of American society. Some people feel that doubting the premise means challenging the basis of society.

It is important for these people to know that this premise is not part of our legal tradition. It never has been. Thus, the Constitution says that the purpose of copyright is to “promote the progress of science and the useful arts.” The Supreme Court has elaborated on this, stating in Fox Film v Doyal that “The sole interest of the United States and the primary object in conferring the [copyright] monopoly lie in the general benefits derived by the public from the labors of authors.”

We are not required to agree with the Constitution or the Supreme Court. (At one time, they both condoned slavery.) So their positions do not disprove the owner supremacy premise. But I hope that the awareness that this is a radical right-wing assumption rather than a traditionally recognized one will weaken its appeal.

Conclusion

We like to think that our society encourages helping your neighbor; but each time we reward someone for obstructionism, or admire them for the wealth they have gained in this way, we are sending the opposite message.

Software hoarding is one form of our general willingness to disregard the welfare of society for personal gain. We can trace this disregard from Ronald Reagan to Jim Bakker, from Ivan Boesky to Exxon, from failing banks to failing schools. We can measure it with the size of the homeless population and the prison population. The antisocial spirit feeds on itself, because the more we see that other people will not help us, the more it seems futile to help them. Thus society decays into a jungle.

If we don’t want to live in a jungle, we must change our attitudes. We must start sending the message that a good citizen is one who cooperates when appropriate, not one who is successful at taking from others. I hope that the free software movement will contribute to this: at least in one area, we will replace the jungle with a more efficient system which encourages and runs on voluntary cooperation.

The Free Software Foundation

Footnotes

1. The issues of pollution and traffic congestion do not alter this conclusion. If we wish to make driving more expensive to discourage driving in general, it is disadvantageous to do this using toll booths, which contribute to both pollution and congestion. A tax on gasoline is much better. Likewise, a desire to enhance safety by limiting maximum speed is not relevant; a free access road enhances the average speed by avoiding stops and delays, for any given speed limit.

© 1991, The Free Software Foundation, Inc. Copying and redistribution are permitted without royalty; alteration is not permitted.

Against User Interface Copyright

The League for Programming Freedom

In June 1990, Lotus won a copyright infringement suit against Paperback Software, a small company that implemented a spreadsheet that obeys the same keystroke commands used in Lotus 1-2-3. Paperback was not accused of copying code from 1-2-3 – only of supporting compatible user commands. Such imitation was common practice until unexpected court decisions in recent years extended the scope of copyright law.

Within a week, Lotus went on to sue Borland over Quattro, a spreadsheet whose usual interface has only a few similarities to 1-2-3. Lotus claims that these similarities in keystroke sequences and/or the ability to customize the interface to emulate 1-2-3 are enough to infringe.

More ominously, Apple Computer has sued Microsoft and Hewlett Packard for implementing a window system whose displays partially resemble those of the Macintosh system. Subsequently Xerox sued Apple for implementing the Macintosh system, which derives some general concepts from the earlier Xerox Star system. These suits try to broaden the Lotus decision and establish copyright on a large class of user interfaces. The Xerox lawsuit was dismissed because of a technicality; but if their planned appeal succeeds, a monopoly of unprecedented scope could still result.

And Ashton-Tate has sued Fox Software for implementing a database program that accepts the same programming language used in dBase. This is a radical demand, but in the current judicial climate, the threat cannot be neglected.1 In the same vein, Adobe claims that the Postscript language is copyrighted, though they are not suing those who reject this claim. If a language could be copyrighted, the result would be devastating for those who have written programs in the language.

While this paper addresses primarily the issue of copyright on specific user interfaces, most of the arguments apply with added force to any broader monopoly.

What is a User Interface?

A user interface is what you have to learn to operate a machine. The user interface of a typewriter is the layout of the keys. The user interface of a car includes a steering wheel for turning, pedals to speed up and slow down, a lever to signal turns, etc.

When the machine is a computer program, the interface includes that of the computer – its keyboard, screen and mouse – plus those aspects specific to the program. These typically include the commands, menus, programming languages, and the way data is presented on the screen.

A copyright on a user interface means a government-imposed monopoly on its use. In the example of the typewriter, this would mean that each manufacturer would be forced to arrange the keys in a different layout.

The Purpose of Copyright

In the United States, the Constitution says that the purpose is to “promote the progress of science and the useful arts.” Conspicuously absent is any hint of intention to enrich copyright holders to the detriment of the users of copyrighted works.

The Supreme Court made the reason for this absence explicit, stating in Fox Film v Doyal that “The sole interest of the United States and the primary object in conferring the [copyright] monopoly lie in the general benefits derived by the public from the labors of authors.”

In other words, since copyright is a government-imposed monopoly, which interferes with the freedom of the public in a significant way, it is justified only if the benefit to the public exceeds the cost to the public.

The spirit of individual freedom must, if anything, incline us against monopoly. Following either the Supreme Court or the principle of freedom, the fundamental question is: what value does user interface copyright offer the public – and what price would we have to pay for it?

Reason #1: More Incentive is Not Needed

The developers of the Star, the Macintosh system, 1-2-3 and dBase claim that without interface copyright there would be insufficient incentive to develop such products. This is disproved by their own actions.

Until 1986, user interface copyright was unheard of. The computer industry developed under a system where imitating a user interface was both standard practice and lawful. Under this system, today’s plaintiffs made their decisions to develop their products. When faced with the choice in actuality, they decided that they did, indeed, have “enough incentive.”

Even though competitors were free to imitate these interfaces, this did not prevent most of the original products from being successful and producing a large return on the investment. In fact, they were so successful that they became de facto standards. (The Xerox Star was a failure due to poor marketing even though nothing similar existed.)

Even if interface copyright would increase the existing incentive, additional improvements in user interfaces would not necessarily result. Once you suck a bottle dry, more suction won’t get more out of it. The existing incentive is so great that it may well suffice to motivate everyone who has an idea worth developing. Extra incentive, at the public’s expense, will only increase the price of these developments.

Reason #2: “Look and Feel” Will Not Protect Small Companies

The proponents of user interface copyright claim that it would protect small companies from being wiped out by large competitors. Yet look around: today’s interface copyright plaintiffs are large, established companies. User interface copyright is crushing when the interface is an effective standard. However, a small company is vulnerable when its product is little used, and its interface is little known. In this situation, user interface copyright won’t help the small company much.

Imagine a small company with 10,000 customers: a large company may believe there is a potential market of a million users, not reached by the small company, for a similar product. The large company will try to use its marketing might to reach them before the small company can.

User interface copyright won’t change this outcome. Forcing the large company to develop an incompatible interface will have little effect on the majority of potential customers – those who have not learned the other interface. They will buy from the large company anyway.

What’s more, interface copyright will work against the small company if the large company’s product becomes an effective standard. Then new customers will have an additional reason to prefer the large company. To survive, the small company will need to offer compatibility with this standard – but, due to user interface copyright, it will not be allowed to do so.

Instead of relying upon monopolistic measures, small companies are most successful when they rely on their own inherent advantages: agility, low overhead, and willingness to take risks.

Reason #3: Diversity in Interfaces is Not Desirable

The Copyright system was designed to encourage diversity; its details work toward this end. Diversity is the primary goal when it comes to novels, songs, and the other traditional domains of copyright. Readers want to read novels they have not yet read.

But diversity is not the goal of interface design. Users of any kind of machinery want consistency in interfaces because this promotes ease of use. Thus, by standardizing symbols on automobile dashboards, we have made it possible for any licensed driver to operate any car without additional instruction. Incompatibility in interfaces is a price to be paid when worthwhile, not a benefit.

Significantly better interfaces may be hard to think of, but it is easy to invent interfaces which are merely different. Interface copyright will surely succeed in encouraging this sort of “interface development.” The result will be gratuitous incompatibility.

Reason #4: Meaningful Competition is Reduced

Under the regime of interface copyright, there will be no compatible competition for established products. For a user to switch to a different brand will require retraining.

But users don’t like to retrain, not even for a significant improvement. For example, the Dvorak keyboard layout, invented several decades ago, enables a typist to type faster and more accurately than is possible with the standard “QWERTY” layout. Nonetheless, few people use it. Even new typists don’t learn Dvorak, because they want to learn the layout used on most typewriters.

Alternative products that require such an effort by the consumer are not effective competition. The monopoly on the established interface will yield in practice a monopoly on the functionality accessed by it. This will cause higher prices and less technological advancement – a windfall for lucky businesses, but bad for the public at large.

Reason #5: Incompatibility Does Not Go Away

If there had been a 50-year interface copyright for the steering wheel, it would have expired not long ago. During the span of the copyright, we would have got cars steered with joysticks, cars steered with levers, and cars steered with pedals. Each car user would have had to choose a brand of car to learn to drive, and it would not be easy to switch.

The expiration of the copyright would have freed manufacturers to switch to the best of the known interfaces. But if Ford cars were steered with wheels and General Motors were steered with pedals, neither company could change interface without abandoning their old customers. It would take decades to converge on a single interface.

Reason #6: Users Invest More Than Developers

The plaintiffs like to claim that user interfaces represent large investments on their part.

In fact, the effort spent designing the user interface of a computer program is usually small compared to the cost of developing the program itself. The people who make a large investment in the user interface are the users who train to use it. Users have spent much more time and money learning to use 1-2-3 than Lotus spent developing the entire program, let alone what Lotus spent develop the program’s interface per se.

Thus, if investment justifies ownership, it is the users who should be the owners. The users should be allowed to decide – in the marketplace – who may use it. According to InfoWorld (mid January 1989), computer users in general expect user interface copyright to be harmful.

Reason #7: Discrimination Against Software Sharing

User interface copyright discriminates against freely redistributable software, such as freeware, shareware and public domain software.

Although it may be possible to license an interface for a proprietary program, if the owner is willing, these licenses require payment, usually per copy. There is no way to collect this payment for a freely redistributable program. The result will be a growing body of interfaces that are barred to nonproprietary software.

Authors of these programs donate to the public the right to share them, and sometimes also to study and change their workings. This is a public service, and one less common than innovation. It does not make sense to encourage innovation of one sort with means that bar donation of another sort.

Reason #8: Copyright Will Be a Tool For Extortion

The scope of interface copyright is so vague and potentially wide that it will be difficult for any programmer to be sure of being safe from lawsuits. Most programs need an interface, and there is usually no way to design an interface except based on the ideas you have seen used elsewhere. Only a great genius would be likely to envision a usable interface without a deep resemblance to current practice. It follows that most programming projects will risk an interface infringement suit.

The spirit of “millions for defense, but not a cent for tribute” is little honored in business today. Customers and investors often avoid companies that are targets of suits; an eventual victory may come years too late to prevent great loss or even bankruptcy. Therefore, when offered a choice between paying royalties and being sued, most businesses pay, even if they would probably win a suit.

Since this tendency is well known, companies often take advantage of it by filing or threatening suits they are unlikely to win. As long as any interface copyright exists, this form of extortion will broaden its effective scope.

Reason #9: Useful Innovation is Inhibited

Due to the evolutionary nature of interface development, interface copyright will actually retard progress.

Fully fleshed-out interfaces don’t often arise as tours de force from the minds of isolated masters. They result from repeated implementations, by different groups, each learning from the results of previous attempts. For example, the Macintosh interface was based on ideas tried previously by Xerox and SRI, and before that by the Stanford Artificial Intelligence Laboratory. The Xerox Star also drew on the interface ideas that came from SRI and SAIL. 1-2-3 adapted the interface ideas of Visicalc and other spreadsheets. dBase drew on a program developed at the Jet Propulsion Laboratory.

This evolutionary process resembles the creation of folk art rather than the way symphonies, novels or films are made. The advances that we ought to encourage are most often small, localized changes to what someone else has done. If each interface has an owner, it will be difficult to implement such ideas. Even assuming the owner will license the interface that is to be improved, the inconvenience and expense would discourage all but the most determined.

Users often appreciate small, incremental changes that make programs easier or faster to use. This means changes that are upwards compatible, or affect only part of a well-known interface. Thus, on computer keyboards, we now have function keys, arrow keys, a delete key and a control key, which typewriters did not have. But the layout of the letters is unchanged.

However, such partial changes as this are not permitted by copyright

law. If any significant portion of the new interface is the same as a copyrighted interface, the new interface is illegal.

Reason #10: Interface Developers Don’t Want Interface Copyright

At the 1989 ACM Conference on Computer-Human Interaction, Professor Samuelson of the Emory School of Law presented a “mock trial” with legal arguments for and against user interface copyright, and then asked the attendees – researchers and developers of user interfaces – to fill out a survey of their opinion on the subject.

The respondents overwhelmingly opposed all aspects of user interface copyright, by as much as 4 to 1 for some aspects. When they were asked whether user interface copyright would harm or help the field, on a scale from 1 (harm) to 5 (help), the average answer was 1.6.2

The advocates of user interface copyright say that it would provide better security and income for user interface designers. However, the survey shows that these supposed beneficiaries would prefer to be let alone.

Do You Really Want a User Interface Copyright?

For a business, “locking in” customers may be profitable for a time. But, as the vendors of proprietary operating systems have found out, this generates resentment and eventually drives customers to try to escape. In the long run, this leads to failure.

Therefore, by permitting user interface copyright, society encourages counterproductive thinking in its businesses. Not all businesses can resist this temptation; let us not tempt them.

Conclusion

Monopolies on user interfaces do not serve the users and do not “promote the progress of science and the useful arts.” User interfaces ought to be the common property of all, as they undisputedly were until a few years ago.

Cambridge, MA

Footnotes

1. The Ashton-Tate suit was dismissed in December 1990, but the idea of copyright on a language was not explicitly rejected; this ruling is being appealed.
2. See the May 1990 issue of the Communications of the ACM, for the full results.

© 1991, The League for Programming Freedom. Copying and redistribution are permitted without royalty; alteration is not permitted.

Against Software Patents

The League for Programming Freedom

Software patents threaten to devastate America’s computer industry. Patents granted in the past decade are now being used to attack companies such as the Lotus Development Corporation for selling programs that they have independently developed. Soon new companies will often be barred from the software arena – most major programs will require licenses for dozens of patents, and this will make them unfeasible. This problem has only one solution: software patents must be eliminated.

The Patent System and Computer Programs

The framers of the United States Constitution established the patent system so that inventors would have an incentive to share their inventions with the general public. In exchange for divulging an invention, the patent grants the inventor a 17 year monopoly on its use. The patent holder can license others to use the invention, but may also refuse to do so. Independent reinvention of the same technique by others does not give them the right to use it.

Patents do not cover specific systems: instead, they cover particular techniques that can be used to build systems, or particular features that systems can offer. Once a technique or feature is patented, it may not be used in a system without the permission of the patent-holder – even if it is implemented in a different way. Since a computer program typically uses many techniques and provides many features, it can infringe many patents at once.

Until recently, patents were not used in the software field. Software developers copyrighted individual programs or made them trade secrets. Copyright was traditionally understood to cover the implementation details of a particular program; it did not cover the features of the program, or the general methods used. And trade secrecy, by definition, could not prohibit any development work by someone who did not know the secret.

On this basis, software development was extremely profitable, and received considerable investment, without any prohibition on independent software development. But this scheme of things is no more. A change in U.S. government policy in the early 1980’s stimulated a flood of applications. Now many have been approved, and the rate is accelerating.

Many programmers are unaware of the change and do not appreciate the magnitude of its effects. Today the lawsuits are just beginning.

Absurd Patents

The Patent Office and the courts have had a difficult time with computer software. The Patent Office refused until recently to hire Computer Science graduates as examiners, and in any case does not offer competitive salaries for the field. Patent examiners are often ill-prepared to evaluate software patent applications to determine if they represent techniques that are widely known or obvious – both of which are grounds for rejection.

Their task is made more difficult because many commonly-used software techniques do not appear in the scientific literature of computer science. Some seemed too obvious to publish while others seemed insufficiently general; some were open secrets.

Computer scientists know many techniques that can be generalized to widely varying circumstances. But the Patent Office seems to believe that each separate use of a technique is a candidate for a new patent. For example, Apple was sued because the HyperCard program allegedly violates patent number 4,736,308, a patent that covers displaying portions of two or more strings together on the screen – effectively, scrolling with multiple subwindows. Scrolling and subwindows are well-known techniques, but combining them is now apparently illegal.

The granting of a patent by the Patent Office carries a presumption in law that the patent is valid. Patents for well-known techniques that were in use many years before the patent application have been upheld by federal courts. It can be hard to prove a technique was well known at the time in question.

For example, the technique of using exclusive-or to write a cursor onto a screen is both well known and obvious. (Its advantage is that another identical exclusive-or operation can be used to erase the cursor without damaging the other data on the screen.) This technique can be implemented in a few lines of a program, and a clever high school student might well reinvent it. But it is covered by patent number 4,197,590, which has been upheld twice in court even though the technique was used at least five years before the patent application. Cadtrak, the company that owns this patent, collects millions of dollars from large computer manufacturers.

English patents covering customary graphics techniques, including airbrushing, stenciling, and combination of two images under control of a third one, were recently upheld in court, despite the testimony of the pioneers of the field that they had developed these techniques years before. (The corresponding United States patents, including 4,633,416 and 4,602,286, have not yet been tested in court, but they probably will be soon.)

All the major developers of spreadsheet programs have been threatened on the basis of patent 4,398,249, covering “natural order recalc” – the recalculation of all the spreadsheet entries that are affected by the changes the user makes, rather than recalculation in a fixed order. Currently Lotus alone is being sued, but a victory for the plaintiff in this case would leave the other developers little hope. The League has found prior art that may defeat this patent, but this is not assured.

Nothing protects programmers from accidentally using a technique that is patented, and then being sued for it. Taking an existing program and making it run faster may also make it violate half a dozen patents that have been granted, or are about to be granted.

Even if the Patent Office learns to understand software better, the mistakes it is making now will follow us into the next century, unless Congress or the Supreme Court intervenes to declare these patents void.

However, this is not the whole of the problem. Computer programming is fundamentally different from the other fields that the patent system previously covered. Even if the patent system were to operate “as intended” for software, it would still obstruct the industry it is supposed to promote.

What Is “Obvious”?

The patent system will not grant or uphold patents that are judged to be obvious. However, the system interprets the word “obvious” in a way that might surprise computer programmers. The standard of obviousness developed in other fields is inappropriate for software.

Patent examiners and judges are accustomed to considering even small, incremental changes as deserving new patents. For example, the famous Polaroid v Kodak case hinged on differences in the number and order of layers of chemicals in a film – differences between the technique Kodak was using and those described by previous, expired patents. The court ruled that these differences were unobvious.

Computer scientists solve problems quickly because the medium of programming is tractable. They are trained to generalize solution principles from one problem to another. One such generalization is that a procedure can be repeated or subdivided. Programmers consider this obvious – but the Patent Office did not think that it was obvious when it granted the patent on scrolling multiple strings, described above.

Cases such as this cannot be considered errors. The patent system is functioning as it was designed to do – but with software, it produces outrageous results.

Patenting What Is Too Obvious to Publish

Sometimes it is possible to patent a technique that is not new precisely because it is obvious – so obvious that no one would have published a paper about it.

For example, computer companies distributing the free X Window System developed by MIT are now being threatened with lawsuits by AT&T over patent number 4,555,775, covering the use of “backing store” in a window system that lets multiple programs have windows. Backing store means that the contents of a window that is temporarily partly hidden are saved in off-screen memory, so they can be restored quickly if the obscuring window disappears.

Early window systems were developed on computers that could not run two programs at once. These computers had small memories, so saving window contents was obviously a waste of scarce memory space. Later, larger multiprocessing computers led to the use of backing store, and to permitting each program to have its own windows. The combination was inevitable.

The technique of backing store was used at MIT in the Lisp Machine System before AT&T applied for a patent. (By coincidence, the Lisp Machine also supported multiprocessing.) The Lisp Machine developers published nothing about backing store at the time, considering it too obvious. It was mentioned when a programmers’ manual explained how to turn it on and off.

But this manual was published one week after the AT&T patent application – too late to count as prior art to defeat the patent. So the AT&T patent may stand, and MIT may be forbidden to continue using a method that MIT used before AT&T.

The result is that the dozens of companies and hundreds of thousands of users who accepted the software from MIT on the understanding that it was free are now faced with possible lawsuits. (They are also being threatened with Cadtrak’s exclusive-or patent.) The X Window System project was intended to develop a window system that all developers could use freely. This public service goal seems to have been thwarted by patents.

Why Software Is Different

Software systems are much easier to design than hardware systems of the same number of components. For example, a program of 100,000 components might be 50,000 lines long and could be written by two good programmers in a year. The equipment needed for this costs less than $10,000; the only other cost would be the programmers’ own living expenses while doing the job. The total investment would be less than a $100,000. If done commercially in a large company, it might cost twice that. By contrast, an automobile typically contains under 100,000 components; it requires a large team and costs tens of millions of dollars to design.

And software is also much cheaper to manufacture: copies can be made easily on an ordinary workstation costing under ten thousand dollars. To produce a complex hardware system often requires a factory costing tens of millions of dollars.

Why is this? A hardware system has to be designed using real components. They have varying costs; they have limits of operation; they may be sensitive to temperature, vibration or humidity; they may generate noise; they drain power; they may fail either momentarily or permanently. They must be physically assembled in their proper places, and they must be accessible for replacement in case they fail.

Moreover, each of the components in a hardware design is likely to affect the behavior of many others. This greatly complicates the task of determining what a hardware design will do: mathematical modeling may prove wrong when the design is built.

By contrast, a computer program is built out of ideal mathematical objects whose behavior is defined, not modeled approximately, by abstract rules. When an if-statement follows a while-statement, there is no need to study whether the if-statement will draw power from the while-statement and thereby distort its output, nor whether it could over-stress the while-statement and make it fail.

Despite being built from simple parts, computer programs are incredibly complex. The program with 100,000 parts is as complex as an automobile, though far easier to design.

While programs cost substantially less to write, market and sell than automobiles, the cost of dealing with the patent system will not be less. The same number of components will, on the average, involve the same number techniques that might be patented.

The Danger of a Lawsuit

Under the current patent system, a software developer who wishes to follow the law must determine which patents a program violates and negotiate with each patent holder a license to use that patent. Licensing may be prohibitively expensive, or even unavailable if the patent is held by a competitor. Even “reasonable” license fees for several patents can add up to make a project unfeasible. Alternatively, the developer may wish to avoid using the patent altogether; but there may be no way around it.

The worst danger of the patent system is that a developer might find, after releasing a product, that it infringes one or many patents. The resulting lawsuit and legal fees could force even a medium-size company out of business.

Worst of all, there is no practical way for a software developer to avoid this danger – there is no effective way to find out what patents a system will infringe. There is a way to try to find out – a patent search – but searches are unreliable and in any case too expensive to use for software projects.

Patent Searches Are Prohibitively Expensive

A system with a hundred thousand components can use hundreds of techniques that might already be patented. Since each patent search costs thousands of dollars, searching for all the possible points of danger could easily cost over a million. This is far more than the cost of writing the program.

The costs don’t stop there. Patent applications are written by lawyers for lawyers. A programmer reading a patent may not believe that his program violates the patent, but a federal court may rule otherwise. It is thus now necessary to involve patent attorneys at every phase of program development.

Yet this only reduces the risk of being sued later – it does not eliminate the risk. So it is necessary to have a reserve of cash for the eventuality of a lawsuit.

When a company spends millions to design a hardware system, and plans to invest tens of millions to manufacture it, an extra million or two to pay for dealing with the patent system might be bearable. However, for the inexpensive programming project, the same extra cost is prohibitive. Individuals and small companies especially cannot afford these costs. Software patents will put an end to software entrepreneurs.

Patent Searches Are Unreliable

Even if developers could afford patent searches, these are not a reliable method of avoiding the use of patented techniques. This is because patent searches do not reveal pending patent applications (which are kept confidential by the Patent Office). Since it takes several years on the average for a software patent to be granted, this is a serious problem: a developer could begin designing a large program after a patent has been applied for, and release the program before the patent is approved. Only later will the developer learn that distribution of the program is prohibited.

For example, the implementors of the widely-used public domain data compression program COMPRESS followed an algorithm obtained from the journal IEEE Computer. (This algorithm is also used in several popular programs for microcomputers, including PKZIP.) They and the user community were surprised to learn later that patent number 4,558,302 had been issued to one of the authors of the article. Now Unisys is demanding royalties for using this algorithm. Although the program COMPRESS is still in the public domain, using it means risking a lawsuit.

The Patent Office does not have a workable scheme for classifying software patents. Patents are most frequently classified by end results, such as “converting iron to steel;” but many patents cover algorithms whose use in a program is entirely independent of the purpose of the program. For example, a program to analyze human speech might infringe the patent on a speedup in the Fast Fourier Transform; so might a program to perform symbolic algebra (in multiplying large numbers); but the category to search for such a patent would be hard to predict.

You might think it would be easy to keep a list of the patented software techniques, or even simply remember them. However, managing such a list is nearly impossible. A list compiled in 1989 by lawyers specializing in the field omitted some of the patents mentioned in this paper.

Obscure Patents

When you imagine an invention, you probably think of something that could be described in a few words, such as “a flying machine with fixed, curved wings” or “an electrical communicator with a microphone and a speaker.” But most patents cover complex detailed processes that have no simple descriptions – often they are speedups or variants of well-known processes that are themselves complex.

Most of these patents are neither obvious nor brilliant; they are obscure. A capable software designer will “invent” several such improvements in the course of a project. However, there are many avenues for improving a technique, so no single project is likely to find any given one.

For example, IBM has several patents (including patent number 4,656,583) on workmanlike, albeit complex, speedups for well-known computations performed by optimizing compilers, such as register coloring and computing the available expressions.

Patents are also granted on combinations of techniques that are already widely used. One example is IBM patent 4,742,450, which covers “shared copy-on-write segments.” This technique allows several programs to share the same piece of memory that represents information in a file; if any program writes a page in the file, that page is replaced by a copy in all of the programs, which continue to share that page with each other but no longer share with the file.

Shared segments and copy-on-write have been used since the 1960’s; this particular combination may be new as a specific feature, but is hardly an invention. Nevertheless, the Patent Office thought that it merited a patent, which must now be taken into account by the developer of any new operating system.

Obscure patents are like land mines: other developers are more likely to reinvent these techniques than to find out about the patents, and then they will be sued. The chance of running into any one of these patents is small, but they are so numerous that you cannot go far without hitting one. Every basic technique has many variations, and a small set of basic techniques can be combined in many ways. The patent office has now granted at least 2000 software patents – no less than 700 in 1989 alone, according to a list compiled by EDS. We can expect the pace to accelerate. In ten years, programmers will have no choice but to march on blindly and hope they are lucky.

Patent Licensing Has Problems, Too

Most large software companies are trying to solve the problem of patents by getting patents of their own. Then they hope to cross-license with the other large companies that own most of the patents, so they will be free to go on as before.

While this approach will allow companies like Microsoft, Apple and IBM to continue in business, it will shut new companies out of the field. A future startup, with no patents of its own, will be forced to pay whatever price the giants choose to impose. That price might be high: established companies have an interest in excluding future competitors. The recent Lotus lawsuits against Borland and the Santa Cruz Operation (although involving an extended idea of copyright rather than patents) show how this can work.

Even the giants cannot protect themselves with cross-licensing from companies whose only business is to obtain exclusive rights to patents and then threaten to sue. For example, consider the New York-based Refac Technology Development Corporation, representing the owner of the “natural order recalc” patent. Contrary to its name, Refac does not develop anything except lawsuits – it has no business reason to join a cross-licensing compact. Cadtrak, the owner of the exclusive-or patent, is also a litigation company.

Refac is demanding five percent of sales of all major spreadsheet programs. If a future program infringes on twenty such patents – and this is not unlikely, given the complexity of computer programs and the broad applicability of many patents – the combined royalties could exceed 100% of the sales price. (In practice, just a few patents can make a program unprofitable.)

The Fundamental Question

According to the Constitution of the United States, the purpose of patents is to “promote the progress of science and the useful arts.” Thus, the basic question at issue is whether software patents, supposedly a method of encouraging software progress, will truly do so, or will retard progress instead.

So far we have explained the ways in which patents will make ordinary software development difficult. But what of the intended benefits of patents: more invention, and more public disclosure of inventions? To what extent will these actually occur in the field of software?

There will be little benefit to society from software patents because invention in software was already flourishing before software patents, and inventions were normally published in journals for everyone to use. Invention flourished so strongly, in fact, that the same inventions were often found again and again.

In Software, Independent Reinvention Is Commonplace

A patent is an absolute monopoly; everyone is forbidden to use the patented process, even those who reinvent it independently. This policy implicitly assumes that inventions are rare and precious, since only in those circumstances is it beneficial.

The field of software is one of constant reinvention; as some people say, programmers throw away more “inventions” each week than other people develop in a year. And the comparative ease of designing large software systems makes it easy for many people to do work in the field. A programmer solves many problems in developing each program. These solutions are likely to be reinvented frequently as other programmers tackle similar problems.

The prevalence of independent reinvention negates the usual purpose of patents. Patents are intended to encourage inventions and, above all, the disclosure of inventions. If a technique will be reinvented frequently, there is no need to encourage more people to invent it; since some of the developers will choose to publish it (if publication is merited), there is no point in encouraging a particular inventor to publish it – not at the cost of inhibiting use of the technique.

Overemphasis of Inventions

Many analysts of American and Japanese industry have attributed Japanese success at producing quality products to the fact that they emphasize incremental improvements, convenient features and quality rather than noteworthy inventions.

It is especially true in software that success depends primarily on getting the details right. And that is most of the work in developing any useful software system. Inventions are a comparatively unimportant part of the job.

The idea of software patents is thus an example of the mistaken American preoccupation with inventions rather than products. And patents will encourage this mistaken focus, even as they impede the development work that actually produces better software.

Impeding Innovation

By reducing the number of programmers engaged in software development, software patents will actually impede innovation. Much software innovation comes from programmers solving problems while developing software, not from projects whose specific purpose is to make inventions and obtain patents. In other words, these innovations are byproducts of software development.

When patents make development more difficult, and cut down on development projects, they will also cut down on the byproducts of development – new techniques.

Could Patents Ever Be Beneficial?

Although software patents in general are harmful to society as a whole, we do not claim that every single software patent is necessarily harmful. Careful study might show that under certain specific and narrow conditions (necessarily excluding the vast majority of cases) it is beneficial to grant software patents.

Nonetheless, the right thing to do now is to eliminate all software patents as soon as possible, before more damage is done. The careful study can come afterward.

Clearly software patents are not urgently needed by anyone except patent lawyers. The pre-patent software industry had no problem that was solved by patents; there was no shortage of invention, and no shortage of investment.

Complete elimination of software patents may not be the ideal solution, but it is close, and is a great improvement. Its very simplicity helps avoid a long delay while people argue about details.

If it is ever shown that software patents are beneficial in certain exceptional cases, the law can be changed again at that time – if it is important enough. There is no reason to continue the present catastrophic situation until that day.

Software Patents Are Legally Questionable

It may come as a surprise that the extension of patent law to software is still legally questionable. It rests on an extreme interpretation of a particular 1981 Supreme Court decision, Diamond v Deihr.1

Traditionally, the only kinds of processes that could be patented were those for transforming matter (such as, for transforming iron into steel). Many other activities which we would consider processes were entirely excluded from patents, including business methods, data analysis, and “mental steps.” This was called the “subject matter” doctrine.

Diamond v Deihr has been interpreted by the Patent Office as a reversal of this doctrine, but the court did not explicitly reject it. The case concerned a process for curing rubber – a transformation of matter. The issue at hand was whether the use of a computer program in the process was enough to render it unpatentable, and the court ruled that it was not. The Patent Office took this narrow decision as a green light for unlimited patenting of software techniques, and even for the use of software to perform specific well-known and customary activities.

Most patent lawyers have embraced the change, saying that the new boundaries of patents should be defined over decades by a series of expensive court cases. Such a course of action will certainly be good for patent lawyers, but it is unlikely to be good for software developers and users.

One Way to Eliminate Software Patents

We recommend the passage of a law to exclude software from the domain of patents. That is to say that, no matter what patents might exist, they would not cover implementations in software; only implementations in the form of hard-to-design hardware would be covered. An advantage of this method is that it would not be necessary to classify patent applications into hardware and software when examining them.

Many have asked how to define software for this purpose – where the line should be drawn. For the purpose of this legislation, software should be defined by the characteristics that make software patents especially harmful:

Software is built from ideal infallible mathematical components, whose outputs are not affected by the components they feed into.

Ideal mathematical components are defined by abstract rules, so that

failure of a component is by definition impossible. The behavior of any system built of these components is likewise defined by the consequences of applying the rules step by step to the components.

Software Can be Easily and Cheaply Copied

Following this criterion, a program to compute prime numbers is a piece of software. A mechanical device designed specifically to perform the same computation is not software, since mechanical components have friction, can interfere with each other’s motion, can fail, and must be assembled physically to form a working machine.

Any piece of software needs a hardware platform in order to run. The software operates the features of the hardware in some combination, under a plan. Our proposal is that combining the features in this way can never create infringement. If the hardware alone does not infringe a patent, then using it in a particular fashion under control of a program should not infringe either. In effect, a program is an extension of the programmer’s mind, acting as a proxy for the programmer to control the hardware.

Usually the hardware is a general purpose computer, which implies no particular application. Such hardware cannot infringe any patents except those covering the construction of computers. Our proposal means that, when a user runs such a program on a general purpose computer, no patents other than those should apply.

The traditional distinction between hardware and software involves a complex of characteristics that used to go hand in hand. Some newer technologies, such as gate arrays and silicon compilers, blur the distinction because they combine characteristics associated with hardware with others associated with software. However, most of these technologies can be classified unambiguously for patent purposes, either as software or as hardware, using the criteria above. A few gray areas may remain, but these are comparatively small, and need not be an obstacle to solving the problems patents pose for ordinary software development. They will eventually be treated as hardware, as software, or as something in between.

Fighting Patents One by One

Until we succeed in eliminating all patenting of software, we must try to overturn individual software patents. This is very expensive and can solve only a small part of the problem, but that is better than nothing.

Overturning patents in court requires prior art, which may not be easy to find. The League for Programming Freedom will try to serve as a clearing house for this information, to assist the defendants in software patent suits. This depends on your help. If you know about prior art for any software patent, please send the information to the League at the address given above.

If you work on software, you can personally help prevent software patents by refusing to cooperate in applying for them. The details of this may depend on the situation.

Conclusion

Exempting software from the scope of patents will protect software developers from the insupportable cost of patent searches, the wasteful struggle to find a way clear of known patents, and the unavoidable danger of lawsuits.

If nothing is changed, what is now an efficient creative activity will become prohibitively expensive. To picture the effects, imagine if each square of pavement on the sidewalk had an owner, and pedestrians required a license to step on it. Imagine the negotiations necessary to walk an entire block under this system. That is what writing a program will be like if software patents continue. The sparks of creativity and individualism that have driven the computer revolution will be snuffed out.

Cambridge, MA

Footnotes

1. See “Legally Speaking” in Communications of the ACM, August 1990

© 1991, The League for Programming Freedom. Copying and redistribution are permitted without royalty; alteration is not permitted.

Appendix: Report of NCCV Working Group on Software Ownership

As a preliminary to future research, the group identified the issues listed in Section 1 below. The group proceeded on the assumption that these issues are best explored with explicit reference to whatever goals – both social and individual – for which the ownership of software may be intended. Section 2 lists a number of these goals, without attempting either to be complete or even consistent. (In fact, a possible problem for future research is to determine which of these goals are mutually compatible, and to what extent.) Section 3 includes some observations about the process of inquiry in which the group was engaged during the conference. Section 4 concludes with some suggestions for further investigation.

This report aims at a widely inclusive representation of diverse views expressed in the working group. It does not aim to present a consensus, a majority view, or even the position of any single individual.

1. Issues

1.1. Ownership

“To own” means different things in different contexts (Becker, 1977). The verb does not have a single core concept but rather a complex of meanings. In questions of software ownership, four clusters of issues are to be investigated: Who? What? How? and Why? The following is a partial list in outline form.

1.2. who: persons

• 1.2.1. motivation

1. 1.2.1.1. money
2. 1.2.1.2. status
3. 1.2.1.3. power
4. 1.2.1.4. recognition
5. 1.2.1.5. self-preservation(# 1.2.1.2.5.1. organizational)(# 1.2.1.2.5.2. individual)

• 1.2.2. access
• 1.2.3. responsibility
• 1.2.4. liability

1.3. what: objects

• 1.3.1. ideas
• 1.3.2. media
• 1.3.3. expression
• 1.3.4. “look & feel”
• 1.3.5. function
• 1.3.6. design
• 1.3.7. algorithm
• 1.3.8. data (information)
• 1.3.9. code
• 1.3.9.1. source
• 1.3.9.2. object

1.4. how: modes

• 1.4.1. acquisition

1. 1.4.1.1. inventing
2. 1.4.1.2. discovering

• 1.4.2. transfer

1. 1.4.2.1. licensing
2. 1.4.2.2. purchasing
3. 1.4.2.3. contracting
4. 1.4.2.4. entrusting (confidentiality)

• 1.4.3. conditions:

1. 1.4.3.1. degree of openness or secrecy
2. 1.4.3.2. fee-based or free of charge (cost)
3. 1.4.3.3. other constraints or restrictions

1.5. why: see “Goals”

2. Goals

As noted above, these issues are best explored with explicit reference to the goals for which the ownership of software may be intended. The following is a partial list in outline form.

2.1. Social

• 2.1.1. information

1. 2.1.1.1. preservation
2. 2.1.1.2. dissemination
3. 2.1.1.2.1. (but not software proliferation as an end in itself?)

• 2.1.2. education
• 2.1.3. thriving economy
• 2.1.4. just distribution

1. 2.1.4.1. Power
2. 2.1.4.2. goods

• 2.1.5. equal access
• 2.1.6. democracy
• 2.1.7. will to cooperate (perhaps as a necessary condition for any other social goals)
• 2.1.8. stability
• 2.1.9. creation and maximization of resources and potentials
• 2.1.10. sciences
• 2.1.11. “useful arts”
• 2.1.12. life
• 2.1.13. happiness, good of humanity

2.2. Personal

• 2.2.1. credit
• 2.2.2. control
• 2.2.3. autonomy
• 2.2.4. enrichment
• 2.2.5. fulfillment (happiness)
• 2.2.6. empowerment
• 2.2.7. health, life
• 2.2.8. fun
• 2.2.9. privacy

3. Process

The search for analogies (e.g., housing, renewable energy sources, public utilities) was a recurring method or strategy of our inquiry. But software doesn’t seem to fit existing categories or conventions of ownership very well. So in the spirit of John Ladd’s Capstone Address, we continued to seek what was unique or special (non-analogous) about software – relative to the goals listed above and to the question of ownership. For example, unlike many other objects of ownership claims, software can be replicated at little or no additional cost per copy, disseminated easily (e.g., over networks), and the replication is as good (perfect, exact) as the original. Such reflections led to deep and thorny philosophical questions such as, Are functional equivalents “copies”? What constitutes identity for software?

Some in the group took comfort in seeing that “nobody else has good answers either” – some participants came away with less certainty about software ownership than they started with. Similarly, some appreciated the atmosphere of intellectual challenge rather than executive pronouncements. Yet several felt a strong need to identify basic principles, rules, and foundations in order to make progress with the issues. The conference itself stimulated a renewed hope for a supportive network of individuals and institutions concerned with these questions.

4. Some Concluding Suggestions

By way of conclusion, some suggested that the balance between creator and society was already skewed too much in favor of owners (often not themselves the creators!) and that, therefore, ownership should be rolled back as a last resort for resolving conflicts over the use of software – that openness should be maximized.

Finally, a couple of more specific topics for further study were suggested: (1) Samuel Slater’s influence on the U.S. textile industry and (2) the impact of incompatible software formats (e.g., user interfaces) on infrastructure.

Whitman College

Reference

Lawrence C. Becker. Property Rights, Boston: Routledge & Kegan Paul Ltd, 1977.