A basic ethical principle is not to steal -- that is, to take something that belongs to someone else without the owner's consent. The rule against stealing is so basic that it is usually stated without explaining why. But if we were to try to justify it, we might say something like, "Stealing someone else's property deprives the other person of something that is rightfully his."

If we try to apply that argument to computer software, we need to explain it further. Usually when software is stolen, it is not physically removed from a hard disk or the fileserver. Instead, it is just copied. The owner may not even realize that it has been "stolen." Who is the real "victim"? Is it the person whose software was copied, or someone else ... perhaps the author of the software?

After the dawn of the computer age, it took awhile before ownership rights to software were legally recognized. In the 1960s and 1970s, there was much debate over whether it was illegal to copy software without a license, but in 1980, an amendment to the Copyright Act of 1976 gave software developers the same protection enjoyed by other authors such as novelists, playwrights and songwriters. For the first time, software was recognized as property -- intellectual property that belonged to the author, not to just anyone who was in possession of a copy.

Copyright protection. Copyright is one of three legal protections for computer software. The others are patents and trade secrets. Copyright protects the literal expression of an idea, not the idea itself. Because it protects the expression and not the idea, you can't copyright algorithms -- though you can certainly copyright a program that embodies those algorithms. The copyrighted work may be literary, audio, video, multimedia, etc. It must embody a minimal level of creativity (you couldn't copyright a recording of someone counting from one to a hundred, for example), but this is not usually a problem with software.

A copyright grants the holder exclusive rights to reproduction (making copies of the work), preparation of derivative works (for example, a novel based on a short story), distribution, and public performance or display. However, protection does not extend to the underlying idea, procedure, discovery, or method of operation. This means that independent development is not protected against. For example, you can develop a program that does the same thing as a program already on the market, as long as you do not copy any of the code of the first program. The "look and feel" of a program is not currently copyrightable, so it is OK if your program's menus look like the menus of the original program. The legal status of this is somewhat shaky, however.

Copyright protection has both advantages and disadvantages. It is easy to obtain; it costs only $400, or less if you fill out the forms yourself. The only rejections are based on formalities. No substantive examination is required, for example, to demonstrate that your program is in some way better than all programs currently on the market.

But copyright protection does have its limitations. Independent development is not protected against. Reverse engineering is not prohibited -- in other words, someone can observe the functioning of your program and then write a program that does the same thing, without owing you any compensation. Finally, the burden of proof is on the copyright holder to show infringement.

Patent protection. Patents are the second kind of protection applicable to computer programs. A patent protects an idea or concept relating to software, while copyright protects only the expression of that idea. Protection is granted for 20 years from the date of the application, which is a much shorter period than copyright protection, which lasts for the lifetime of the author plus 70 years. There is a special kind of patents, called design patents, which are granted for 14 years. They protect the aesthetic appearance of lamps, for example. There has been a push to use them to protect the appearance of screens displayed by a program. It is not clear how successful this attempt will be.

Unlike obtaining a copyright, obtaining a patent requires demonstrating some things about the invention to be patented. It must be novel, nonobvious (here the "reasonable man" standard is employed--would it be obvious to the reasonable man or woman?), useful (this is not usually a problem with software), and fully disclosed. The reason for the latter requirement is that when the patent expires, people should be able to pick up your design and build the "invention." In the United States, you have to file for a patent within one year of first offering the "invention" for sale; otherwise you lose the right to protect it. But in many other countries, the 1-year grace period does not exist. There, you must file for the patent first, before you try and sell the product.

A 1972 Supreme Court decision held that computer programs were not patentable per se. There was a long debate as to whether programs were patentable at all. But in 1981, the Supreme Court, in the case of Diamond v. Diehr, ruled that a patent claim for a product should not be rejected just because it includes a computer program. In this case, a process for curing rubber was patentable, and the patent was not disallowed just because a computer program was part of the process.

Originally, patents for programs had to be tied to hardware. The distinction was based on the mathematical algorithm vs. the application of the algorithm. Later, the U.S. Patent and Trademark Office published guidelines that made it easier to patent software not involving a hardware device. As a result, the number of software patents has surged in recent years. This has led to concern over whether the USPTO has the resources to evaluate software-patent applications with sufficient care.

In 1998, the Federal Circuit Court of Appeals, in State Street Bank v. Signature Financial Group upheld the issuance of a "business methods" patent. Business-methods patents grant a company the sole right to use a particular method of doing business, typically over the Internet. For example, amazon.com holds a patent on its "1-click" checkout system, which accesses address and credit-card information from the customer's computer. Priceline.com has patented its buyer-driven, "name your price" business model.

Business-methods patents raise several issues, including whether business methods are sufficiently unique to be patentable, whether many innovations would be "obvious" to a software practitioner familiar with a particular business model, and whether the Patent and Trademark Office has sufficient expertise in "prior art" to determine whether a particular technique is in fact new. Concern over these patents has led to moves in Congress to prevent the issuance of patents for conventional business methods that are new only because they use a computer. However, others have noted that some techniques for computerizing existing practices are far from obvious, and do deserve patent protection.

The main advantage of patent protection is the breadth of protection: a patent protects against independent development. Offset against this are several disadvantages: A patent costs money to obtain. In the U.S., the application cost is $6K-$15K, and the total cost may be $30K-$40K. It takes time to obtain; it may take two years for the patent office to respond. Then you may go back and forth with the patent examiner.

Trade-secret protection. The third form of protection for programs is as a trade secret. Trade secrets are governed by contract law, which varies from state to state. They are implemented by nondisclosure agreements. Usually, to hold up in court, a trade secret must be novel, represent an economic interest to the claimant, and have involved some effort in development. Also, the company must show that it made an effort to keep the information a secret.

Trade-secret protection can involve source code, object code--until a program is released, design documentation, and know-how. The advantage of trade-secret protection is its breadth; it can encompass any ideas or information that has economic value for a company. Among the disadvantages are that the laws are not uniform from state to state, so national enforcement is difficult. Unfortunately, it is hard to maintain trade secrets when employees move from job to job so frequently, and when intellectual property is so much more valuable than material assets. Evidence of infringement is rarely found, so it is difficult to prosecute. Finally, if information becomes public by any means, it is in the public domain and unprotectable.

Moral basis for protection. But why, ethically, should software be protected? A person has a moral right to what (s)he produces, and this right should be protected by law. As with any other product, a person acquires a right to ownership of something by laboring to produce it. For example, you have a claim to the crops you grew because your labor produced them. For someone else to take them would therefore be wrong. Similarly, you have a claim to the software you wrote because you labored to write the code. For someone else to make money by selling them instead of you would be wrong. They would essentially be taking your product and using it for their benefit.

One might critique this analysis by saying that one could imagine a "just" world where we did not acquire rights to what we created. You could create things, but that wouldn't give you any right to them. In particular, intangible things couldn't be "owned," because many people can use them at the same time. If I take your car or your computer, for example, you can't use it. But if I copy your music CD or your software, you can continue to use them just as before.

The ownership right that we are talking about, then, turns out to be the right to profit from what you have created. Would it be right for someone else to profit from it, if they did not invest any effort in developing it -- or just a little bit of effort? Allowing ownership of software encourages people to invest time and effort in developing it. Providing "monopoly" protection for innovations is justified on the grounds that it will result in significant breakthroughs which will be immensely beneficial to society. This is an example of utilitarian reasoning.

Now let us look at the consequentialist argument for ownership of software. Unless people get some ownership rights, they will be unwilling to invest the time, energy, and resources to develop software and bring it to market. Why develop a program if the moment you bring it to market, someone will copy it and sell it more cheaply? A critic might say, No, people will develop software because they need it for their own purposes. Then they can share it with others. This is the idea of "shareware," where you can obtain a program freely, but are supposed to pay the developer if you like it and continue to use it.

One can also imagine that individuals would be given credit, like they get for publishing the results of scientific research. This would enhance their reputation and make it easier for them to get grants to write more software -- assuming that there was somebody out there who was giving out grants for software-writing. This is the approach espoused in the Gnu manifesto, which we will consider shortly. A lot of useful software has been produced in this way. But it is mostly functionally equivalent to software that already exists, so it is questionable whether much innovation has been achieved.

Or, hardware manufacturers might develop software so people would buy their computers. In fact, this is how most software was developed until the early 1970s. But this is becoming less of a possibility as the installed software base grows and it becomes more important to have interoperability and platform independence.

So, there is good justification for ownership rights to software on both utilitarian grounds -- most software innovation has occurred in this way -- and deontological grounds -- that one has a right to the fruits of one's labors. However, not everyone believes this. Particularly in Asian cultures, there is an undercurrent that regards intellectual property as public goods for everyone to share freely. As we shall see two weeks from now, this has led to widespread copying of proprietary software in the Far East that is even more widespread than in the United States or Western Europe.

Should software be free? A good exposition of the arguments for free software is the Gnu manifesto, a 1985 treatise by Richard Stallman, the author of the original Emacs editor. He says that the Golden Rule requires that if I like a program, I must share it with others who like it. Software sellers, he says, want to divide and conquer users; he refuses to "break solidarity" with other users in this way. Purchasers of software must usually decide between "friendship" and breaking the law; neither is a good choice. By working on the Gnu project, they can be hospitable and still obey the law.

Since Gnu is free, Stallman continues, people won't be inclined to duplicate the work of producing it for their own system. Schools will be able to use it to provide a better educational environment. The source code will be available, so anyone who needs to change it will be able to.

The concept of free software would remove the overhead of considering who owns it and litigating what one is allowed to do with it. This is similar to the difference between toll roads and free highways; toll roads require toll booths, toll collectors, and toll-authority administrators. Free software, like "free" highways, are still paid for by somebody, but we save the overhead of determining who is using what. Stallman says that only a police state can enforce the intellectual property laws anyway.

If software were tax supported, all sorts of development could be funded with the software tax. The government could give it to an agency like the National Science Foundation to spend on software development. But, by donating software, a manufacturer could be allowed to take a credit against the tax.

Stallman says that free software would still be supported; companies would spring up just to provide support. As to the objection that programmers would make less money writing free software, Stallman says that if anything deserves a reward, it is a social contribution. Creativity is a social contribution only insofar as society is free to use the results. A good citizen doesn't use restrictive means to become wealthier, because if everyone did this, we would all become poorer from the mutual destructiveness. (Note the appeal for actions that can be universalized; he is taking a page from deontological theory.)

Stallman doesn't disavow capitalism; he just says a capitalistic approach is not appropriate everywhere. He says that the argument is that, by rewarding the winner of a race, we encourage everyone to run faster. When capitalism works this way, he says, it does a good job. But it does not always work this way; it may encourage people to become cutthroat. He likens proprietary software to a fistfight during a race; if runners get into the fight, they will all finish late.

In view of Stallman's theory, it is interesting to analyze the impressive growth of the Java programming language over the last several years. From nothing, it has grown to be the one of the two most widely used object-oriented languages. Its growth rate is six times faster than its nearest competitor. Java is available freely from Sun Microsystems, but a charge is made for training and most support services. Java has made very little money for Sun directly, but it has put Sun's speakers and seminars in great demand, and thereby given them an "inside track" to promote purchase of Sun computers. This is a new twist to Stallman's prediction that computer manufacturers might develop software to help sell their computers.

Should user interfaces be copyrightable? While the debate over free software has been mainly of academic interest, another debate over the scope of copyright protection has had enormous commercial implications. At issue is whether user interfaces should be copyrightable: Should it be a violation for two spreadsheets, for example, to have displays with a similar "look and feel"? Under copyright law, the plaintiff can prove a violation by showing that the defendant had access to the plaintiff's work, and that there is a "substantial similarity" between the two works.

In 1984, Apple Computer introduced the Macintosh, which introduced a radical improvement in operating-systems technology, the graphical user interface. Actually, a GUI had been employed in Apple's Lisa, dating back to 1982, and in several experimental systems from Xerox in the 1970s. But the Macintosh was a much less expensive system, and took off commercially. At this time, Apple entered into an agreement with Microsoft to develop applications for the Macintosh.

Not long thereafter, Microsoft released the Windows operating system, with an interface that looked much like the Macintosh's. In 1988, Apple sued Microsoft and its sub-licensee Hewlett-Packard, charging that they had infringed the copyright for the Macintosh user interface. In 1992, the trial court ruled against Apple, and in 1994, an appeals court upheld that decision. The decision was complicated by the agreement between Apple and Microsoft, where Apple gave Microsoft access to the Mac OS. The court ruled that given this agreement, Apple would have to show "virtually identical copying" rather than "substantial similarity."

Two years later, a case was decided that tested the copyrightability of user interfaces more directly. In 1990, Lotus Development sued Borland, charging that the command structure of Borland's Quattro Pro infringed on the copyright for Lotus 1-2-3. Borland had intentionally made the menus similar, and included an alternate "Lotus Emulation Interface" that allowed users to use all Lotus commands on the Borland spreadsheet. In 1992, the trial court ruled that Borland had infringed the Lotus copyright. Borland immediately removed the Lotus Emulation Interface, but retained the similarity of menu structure and commands. In 1995, a Court of Appeals ruled that a menu command hierarchy is not copyrightable subject matter. Lotus appealed to the Supreme Court, which by a tie vote of 4-4, let the Court of Appeals ruling stand. Justice Stevens, who was believed to hold stock in Lotus's parent company IBM, did not take part in the decision. Because the ruling was upheld by a tie vote, the case does not provide much guidance for future claims of user-interface copyright infringement. The Supreme Court could go either way, depending on how the 9th justice votes.

Although the issue has not been decided, there are good reasons for not having user interfaces copyrightable, as Richard Stallman and Simon Garfinklel wrote. User-interface copyright would lead to a diversity of user interfaces, which would not be desirable. If copyright were applied to automobile dashboards, for example, it might prevent different manufacturers from all using steering wheels. Some cars might be steered by joysticks, trackballs, or foot pedals.

Copyrightable user interfaces might also reduce competition in the software industry. It would be harder to change from one company's software to a competitor's product. If a company wanted to change software vendors, it would have to retrain its employees. This would be like having to learn a different keyboard if you bought a different company's computer.

Moreover, copyrightable user interfaces would protect large software companies, because users would know the large company's interfaces. A small company would not have a fighting chance to compete. On the other hand, a large company could steal a small company's software ideas, design a different user interface, and beat the small company through marketing strength.

User-interface copyright could become a tool for extortion. It is hard to design a completely new user interface. There might be a lot of lawsuits. Customers and investors shun businesses that are the target of suits. So a competitor could just threaten to file suit against a small company that used a similar user interface, and the small company would have no choice but to pay whatever royalties were demanded, just to avoid a lawsuit.

In this week's lecture, we have examined the basis for legal protection of computer programs. We have seen that that ethical principles of ownership demand that we respect others' rights to the software that they have developed. Free software and shareware are useful alternatives to commercial software, and can become very successful. The legal system still has not decided the extent to which protection applies to software. We should seek a legal framework that respects property rights but does not prevent meaningful competition.