Intellectual Property and Software Patents

David Golombek December 9, 1997

Contents

1 Introduction 3

2 Existing Software Development Models 3 2.1 The Free Software Model . . . . . . . . . . . . . . . . . . . . . . 3 2.2 The Proprietary Software Model . . . . . . . . . . . . . . . . . . 4

3 What United States Law Says 5

4 Why Proprietary Software is Bad 5

4.1 Problems with Software Patents . . . . . . . . . . . . . . . . . . . 6 4.1.1 Many software patents are for Obvious Work . . . . . . . 6 4.1.2 Problems with Patent Searches . . . . . . . . . . . . . . . 6 4.1.3 Problems with Patent Licensing . . . . . . . . . . . . . . 7 4.1.4 Software Patents last too Long . . . . . . . . . . . . . . . 7

5 Why Proprietary Software Hasn’t Hurt Us Yet 7 5.1 The LPF’s View . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2 Large Software Companies’ View . . . . . . . . . . . . . . . . . . 8 5.3 Why Proprietary Software Will Begin to Hurt More . . . . . . . 9

5.3.1 The Patent Flood is Increasing . . . . . . . . . . . . . . . 9 5.3.2 The Stakes are Increasing . . . . . . . . . . . . . . . . . . 9 5.3.3 The Litigation is Increasing . . . . . . . . . . . . . . . . . 10 5.3.4 The Scope of Software is Increasing . . . . . . . . . . . . 10

6 The Mixed Software Model 10

7 Conclusion 12

1 Introduction

For the last twenty years, Richard Stallman has been fighting a battle against proprietary software and software ownership. Stallman firmly believes in the freedom of software, where freedom is defined as “the users’ freedom to run, copy, distribute, study, change and improve the software.”[3] As anyone walking into a computer store can clearly see, Stallman’s fight has been a losing one, and proprietary code still comprises most of the software running on computers today. Modern capitalistic notions of consumerism mesh nicely with software vendors’ desires to make money, and most people are happy (besides Stallman). However, current software practices are actually slowing software development and providing inferior programs to the public. This paper will explain why current practices are indeed so bad for the public, why the public don’t realize this fact, and then attempt to devise a model for software development and distribution that will address some of the issues brought up by both sides. It will end up concluding that software patents should be abolished before they become an even bigger problem than they are now, and that standardized programming models should be promoted in order to facilitate code sharing.

2 Existing Software Development Models

Up to this point, software development has fallen under one of two general categories, free software or proprietary software. There are minor variations, such as freeware programming, but these all essentially involve some attempt by the author to make some money for himself by restricting use of his program, and thus cannot be classified as free software.

2.1 The Free Software Model

“Free software” is a matter of liberty, not price. To understand the concept, you should think of “free speech”, not “free beer.” [3]

The term “free software” has long been used by Richard Stallman and others to describe the alternative to proprietary software. As indicated in the above quote from Stallman, it has nothing to do with the price charged with the software, but rather what may be done with it. Free software is intended to give absolute power to the user of that software, rather than reserving all rights for its creator. That is, with free software, the user has both the program to run, and the source code to that program, which he may modify if he so desires and distribute to anyone who wants a copy. Furthermore, the user may combine both actions, modifying the program to make improvements (or merely stylistic changes), and then distribute this modified version. All of this is in strict contrast to proprietary software, where the original creator of the software retains near complete rights to that program, and merely grants the user the right to run the program.

The idea of free software has been around since the beginning of programming itself. The companies that built the first computers distributed the source code (initially in assembly language, later in higher level languages) freely with the executable programs, in order to demonstrate how to program their computers. More noticeably in support of free software were the universities who were the largest initial purchasers of computers (aside from the military, which never releases anything), which have always had a policy of sharing and distributing all research results and techniques. This policy certainly helped form the attitudes of the first university computer programmers.

The first large computer culture outside of a computer company developed at MIT at the Artificial Intelligence Laboratory and later at the Tech Model Railroad Club (TMRC). The growth of the computer culture is detailed in Steven Levy’s book \underline{H}ackers[2], and covers the growth of the MIT hacker community, which was the first group to formalize and instituitionalize the practice of making the source code to all programs avaliable. The hackers at MIT wanted all information to be free, especially that information that would help other people work on projects. Writing a tool that would help other hackers and distributing the source code for that tool was considered a highly moral and prestigious activity, one that all hackers should engage in. While these moral standards are certainly rather unique to the group of hackers that developed them, the important lesson to be learned from the early MIT hackers was how quickly they developed software. The cooperative community of hackers produced a tremendous amount of software and advanced the state-of-the-art in software by great leaps by virtue of many smart minds working in collaboration, sharing work and ideas freely.

2.2 The Proprietary Software Model

The original MIT hacker community was splintered heavily when computer companies hired many of the original hackers to work on proprietary code, luring them away with large salaries. Software companies were able to make enormous profit margins, developing software off the effort of a couple hackers and selling it for high prices to large numbers of individuals. Software companies had no manufacturing costs, minimal distribution costs, and comparatively small advertising needs, and thus were able to be among the most profitable of companies, making their owners and employees very rich. A part of this profitability though was keeping company software private to prevent other companies from copying it and redistributing it on their own. Thus each company kept their code under tight lock and key. Some went even further and began to patent their software and ideas, trying to enforce their competitive advantage even further. Both the ideas behind a piece of software and its interface were considered proprietary to the company who created it, and the American legal system backed up the companies in their claims.

Which of these models is more correct is a philosophical judgement and not one that has been definitively answered by any existing doctrine. The next section will examine what current United States law dictates with regards to software patents.

3 What United States Law Says

The founding fathers of the United States included the basis of our current patent and copyright system in the Article 1, Section 8 of the Constitution when they wrote:

The Congress shall have Power [...]

To promote the Progress of Science and useful Arts by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries;

The US Patent and Trademark Office (PTO) was founded to help enforce these ideals and to create a process for the assignment of patents. It is in charge of deciding which claims are original pieces of work and granting patents and trademarks to those claims they find meet the standards set up in 15 U.S.C 1051-1127, 1511, 35 U.S.C, and 44 U.S.C 1337-1338, which form the principal statuatory authorities of the PTO. The PTO’s self-stated interpretation of these laws is to “promote industrial and technological progress in the United States and strenghen the national economy.”[4]

While the basic principle remains of the patent system remains as strong and popular as ever, the exact interpretation of these patent laws has changed over time. The application of patent law to software is particularly volatile and the subject of much controversy. Existing patent and copyright law was initially assumed not to cover software, considering them akin to algorithms, which are not patentable. In a series of patent grants and court cases, including Diamond vs. Deihr, interpretation of patent law was taken to mean that software was patentable, and the rush to patent all new software ideas was on.

4 Why Proprietary Software is Bad

The United States has used the principles set out in the Constitution to govern the administration of patents in the software industry. And up to this point, this policy has worked reasonably well. Many companies have made a lot of money, and advances in computer technology and application have continued to advance, helping the public good. This situation is unlikely to continue much longer. While our current system has worked well up to now, the buildup of software patents and changes in the nature of software engineering are likely to create a future where the public good is no longer served by software patents.

4.1 Problems with Software Patents

Patents and copyrights are the primary means companies use to keep their programs proprietary. They use patents to protect the ideas and processes of their programs, and copyrights to prevent users from reverse engineering the program to determine how it was accomplished. Several ways in which software patents are directly harmful to the advancement of the state-of-the-art in software engineering will be shown below.

4.1.1 Many software patents are for Obvious Work

Many of the software patents granted by the PTO are for ideas and pieces of code that seem obvious to the common member of the computer science community. For example, Cadtrak has patent #4,197,590, which is for the use of exclusive-or (xor) in computer graphics. The use of the xor operation has long been known, and it is the most intuitive way to perform many graphics operations, such as a display of a mouse cursor, image masks, and several forms of shading. Unfortunately, the software patent reviewers at the PTO are not always dedicated computer scientists, and many obvious concepts like the xor patent are let though. This is as much a problem with the administration of the patent system as it is with the patent system in general. The sheer number of software patents being submitted makes it likely that some number of obvious patents will always make it through, no matter how well the PTO is administered.

4.1.2 Problems with Patent Searches

The normal way of avoiding overstepping someone else’s patent is to do a search of all existing patents for any prior work. Unfortunately, as the list of existing patents grows larger, this becomes a more difficult task. Patents are written in a very specific language, one that only trained professionals (read lawyers) can be trusted to fully understand. Thus, to do a patent search effectively, a company needs to hire a specialized patent lawyer to do the search for them, who are extremely expensive. Even these patent lawyers make mistakes, because some patents are so vague as to possibly encompass extremely large areas of software, leaving a company continually uncertain if it is about to be sued for patent infringement.

These patent searches must be performed constantly, because new software patents come out daily (up to one hundred a week in recent years), and because a typical software project will cover an extremely wide range of subjects. A company must continually ensure that every part of every product, both existing and under development, complies with all patents, or face lawsuit from the patent holder, back-dated to the date of the other companies’ patent application. The only ways to escape these lawsuits are to license the patent or to remove the patented material from the program, and even these drastic measures may not satisfy the courts, which can still apply fines for profits made on patented material.

4.1.3 Problems with Patent Licensing

If all patent licenses were cheap and easy to obtain, most of the initial problems with patents could be avoided. A company could simply pay out royalties to whoever had the patents they needed and continue on developing their software if they felt the price was right. This still wouldn’t solve all the problems that we are likely to encounter in the future, but would significantly simplify things. Unfortunately, most companies are eager to make as much money as possible, and thus charge very high fees for patent licensing, knowing the law will tend to support them in court. Some companies will not license their patents at all, trying to maintain exclusivity on their work to guarantee greater sales. Since the company knows their patent is exclusive, they can charge exorbitant amounts, and frequently do.

4.1.4 Software Patents last too Long

In the world of physical devices and mechanical construction, creation of a new process for peforming some task can be an expensive endeavor, and can be expected to be useful for a reasonably long time. The seventeen year length of patents is reasonable, allowing the inventing company to reap full rewards from the invention before other companies are allowed to start utilizing the process. The software industry moves so quickly that seventeen years is an infinity — roughly one third the entire history of computer software. By the time a patent expires, only the most enduring of software will be at all relevant, such as the RSA patent. Rather than a patent still being useful at the end of its stay, most software patents are useless to anyone, and thus their conversion to the Public Domain is meaningless. Instead of merely allowing the inventing company time to recoup its design costs, software patents lock the patented idea up until it is ready to die.

5 Why Proprietary Software Hasn’t Hurt Us Yet

The problems described above with the patent system may not seem too bad, since software has been progressing at a rapid rate despite these problems. Sure, the problems may cause hassles for a lot of software companies, but are they really hurting the software industry? The answer to this question is currently under debate, with the League for Programming Freedom (LPF) taking the side that patents are harmful, and many large software companies claiming that patents are useful and neccessary.

5.1 The LPF’s View

In “Against Software Patents”[1] the LPF states “Software patents threaten to devestate America’s computer industry. ... The problem has only one solution: software patents must be eliminated.” This unequivocal position has won few friends among the big-business friendly American government, but the LPF has has many strong points for its argument. In the above mentioned article and many others, they cover several of the problems with patents mentioned above, as well as others. They additionally argue that programmer efficiency is being stifled by the neccessity of performing constant patent searches and that innovation is being stifled by concerns of overstepping broadly worded patents. They even argue that software patent law extensions may be illegal, that the interpretation of the Supreme Courts 1981 decision in Diamond vs. Deihr used by the PTO is faulty, that the decision supporting a patent on a computer program as part of the rubber curing process was for a specific case and not a general ruling on software patents.

The LPF is specifically interested in abolishing software patents, suggesting a law be passed excluding software from the domain of patents, as was considered to be the case until the 1980’s. They admit there might theoretically be some limitted set of software that might deserver patent protection, but have never seen the existance of such programs, and were they to exist, would need to be handled as a special case. The LPF is not opposed to copyrights on individual programs, but rather these large patents on software ideas and on user-interface protectionism through copyright or patents. To fight for theses views, they write papers explaining their position, petition Congressmen and especially members of relevant committees, give speaches, and run protests.

5.2 Large Software Companies’ View

Many large software companies have taken stands in favor of the existing software patent system. They like the status quo most of the time, finding they can use it to their advantage. Large software companies (IBM is the canonical example) build up large collections of patents and use these to force other companies to pay them royalties on their products. IBM takes its portfolio of over 9000 patents and approaches smaller companies, claiming violation of one or more patents, then asking for a 1% royalty for licensing one patent, or a 5% royalty for licensing the entire portfolio. If the company refuses to license the patents, IBM can threaten to take them to court, a process more lengthy, painful, and expensive than the licensing would ever be. IBM can protect itself from similar extortion schemes by finding a patent that the extorting company has violated and forcing them into a cross-licensing scheme, which costs IBM nothing. Other companies that have similar patent portfolios include Microsoft, AT&T, and DEC.

There are a few large software companies which do not follow this viewpoint, notably Adobe, Oracle, Autodesk, Synopsis, and Wind River Systems. Unfortunately these make up the have-nots, the companies that didn’t have large patent portfolios, and have been on the losing side of software patent battles in the past. Even these companies are forced to patent their software to protect against having someone else claim the patent and force them to pay royalties on their own idea.

The big losers in the software patent model are small companies and individual programmers. These groups are typically unable to afford constant patent searches to determine the legality of their programs and don’t have the deep pockets needed to fight any sort of a patent battle, even when they are right. Thus even when a small company or individual obtains a software patent, they frequently fall victim to the extortion used by larger software companies or are unable to pursue all companies that infringe on their patents.

5.3 Why Proprietary Software Will Begin to Hurt More

5.3.1 The Patent Flood is Increasing

The problems with the current patent system presented by the LPF are not going to get better on their own. In fact, they are going to get much worse. There are currently tens of thousands of software patents in existance, so many that no one can even be certain, because some patents are so vague on the limits of what they claim (example, a claim to all automated Bingo games, which was deemed to include computer bingo games). Tens to hundreds more software patents are granted weekly, in an ever increasing flood, with every company eager to patent every little idea they can. At the same time the number of PTO patent examiners remains roughly constant, and so each patent will receive less attention, letting more trivial or non-original patents fall through the cracks.

5.3.2 The Stakes are Increasing

As the database of existing patents grows larger, patent searches become more difficult and it becomes harder write any software that entirely avoids all patents. If more companies become monopolistic and refuse to license their software, trying to force everyone else to use their program, we could eventually reach a point where making any progress in software engineering became a prohibitively difficult task. Many signs are beginning to point towards the fact that this point is much closer than a lot of programmers, managers, and businessmen want to admit. The number of software patent lawsuits has been rising dramatically, as well as the size of many of these lawsuits. Even industry giants such as Microsoft, Novell, and Oracle have been embroiled is high-stakes lawsuits, such as the Stac Electronics vs Microsoft suit which eventually forced Microsoft to remove part of MS-DOS 6.0.

5.3.3 The Litigation is Increasing

The software industry used to be run by programmers who were forced into management, people who studied computer science in school, not business. These days, most computer companies have CEO’s brought in from big business schools, people with lots of experience, and most importantly for this discussion, are knowledgeable about the law. In particular, they know how to manipulate the law to work for them, and know the right lawyers to talk to in order to twist the law even further. Like the rest of society, the computer industry has become more litigious, prompting the LPF slogan “Innovate, don’t litigate!” This hasn’t helped the software patent problem, and this trend of bringing every issue to court seems to continue to grow.

5.3.4 The Scope of Software is Increasing

Perhaps the most important reason that we need to do something about proprietary software now is that it will be technically necessary for software companies to share more code and advances in the coming years. The scope of software projects has been growing rapidly over the last few decades, as the complexity of what software vendors attempt to do increases. Early software projects were simple affairs usually, involving fairly few programmers, most of whom were doing original work, because there was little prior art to reproduce. Modern software projects involve large groups of programmers, many of whom are reproducing work done by other programmers at other companies. Libraries are being developed and shipped (sometimes free, sometimes not), allowing programmers to avoid rewriting everything from scratch, but due to interface copyrights, these libraries are not interchangeable, and thus many programmers choose to reproduce everything on their own, rather than be trapped into a proprietary solution.

6 The Mixed Software Model

Up to this point, the paper has been pointing out the problems with the existing situation with software. And as important as it is to reiterate the problems to make sure people agree that they do exist (at least to some degree), suggesting solutions to problems is even more important. Thus, the paper turns to finding a new model for software, one that doesn’t rely on patents, but that still allows software companies to profit from their efforts.

The basis for this new model is some technology called Object Brokerages or Object Warehouses. This technology has existed for the last three years, and has been developed in several systems, including CORBA, the Common Object Request Broker Architecture, headed by IBM, what is now called DCOM, the Distributed Common Object Model, headed by Microsoft, and finally OpenDoc, Apple’s now mostly defunct entry into the running. These technologies are all based around the same idea, that there exist “objects”, or blocks of code and data representing something, be it a file on a disk, or a network, or any other computational entity. The Object Brokerages allow for the universal naming and communications between these objects, allowing for a large system of these objects to work together to create a larger program.

But a technology does not a policy make, as we have discussed in class. How does this techology translate into a new model for software? It leads to a model called the mixed programming model, in which companies do not have patents on their code, but still have copyright to protect them, but a programming scheme that encourages effective code sharing is adopted, to gain the benefits of code reuse. Now that the final model has been layed out, lets build up to it in pieces to explain where it came from.

First, software patents need to be eliminated. The LPF has a strong case that software patents are currently hurting the software industry, and this is only going to get worse over time. Even by drastically reducing the time that software patents held to three or fewer years, patents will still dramatically slow down the pace of progress in computer science. Therefore, they must be removed entirely. Software companies will be forced to innovate even faster to distinguish themselves from their competitors.

Second, large software companies, particularly Microsoft, need to be broken up. This is a contentious point, and unfortunately beyond the true scope of this essay. It is not strictly neccessary for the model presented here to work, but makes the explanation of it much easier. The problem with large companies like Microsoft is that they monopolize a realm of applications, such as word processing, and present a single program that everyone uses, and that becomes such a standard that it becomes impossible for other competitors to enter the market. Proving that a company has become a monopoly is difficult however, and it is difficult to gain popular support for breaking up a company in our bigbusiness friendly government. However, positing a breakup of large software companies will make the examples to come easier, and so will be left in.

Third, the government needs to lead a push towards standardizing on one of the object brokerages mentioned above. Each of the contending models has its strengths and weaknesses, but all are workable enough to serve as a good foundation for large software projects. DCOM and CORBA are the two primary proposals, and large projects have in fact already be completed based on both of them. The government needs to force one of these to become a truly open standard, taking it out of the hands of its creator and into the realm of an ANSI (American National Standards Institute) or ISO (International Standards Organization), preventing the creator from continually changing it from preventing “unwanted” others from using the model. Microsoft and other vendors have been guilty of this, publishing a standard, then modifying it too fast for other vendors to use, allowing only internal developers to use the “standard”. Equally importantly, the government cannot allow the object model to stay in standards committees forever, becoming more complex as everyone adds on their favorite features, as has happened with many designs worked on by committee.

Fourth, and finally, there needs to be a strong push towards using this object brokerage very widely in user applications. This is perhaps the hardest step, because it is nearly impossible to legislate, and will not necessarily be of interest to large software companies. Large software firms like Microsoft have been developing these object brokerages, but when it comes to letting other firms create plugins for core parts of their applications, Microsoft suddenly backs off becomes proprietary again. The goal of all of this again is to allow different vendors to create objects that will interoperate cleanly, allowing the user (or a packager) to pick which modules to use in assembling the final application. For example, a user could put together his own document package, picking an editor, a spell-checker, a graphics module, a table manager, and font package, all from different suppliers. Or if the end user didn’t want to do this, a packager could pick these components by default, still allowing the user to replace individual components if he so wished.

This mixed code model contains a bit of the best of both the free and proprietary software worlds. It contains some of the code sharing evolution from the free software model, because companies can use objects from other companies rather than having to reimplement them on their own, if that company is selling the module for a reasonable price. If the price isn’t reasonable, they can create their own replacement, or find one from another vendor. The mixed model also contains much of the proprietary model, in that companies can still profit from their work, and are safe from having people copy their code directly due to copyright law. The public wins most though, because software companies are forced to compete more, but are competing in an advancing manner, rather than fighting to reinvent the wheel over and over again.

7 Conclusion

Intellectual Property laws are currently very strong, protecting the creator of software near complete rights to his code, in the form of software patents and interface copyrights. Unfortunately this protection is beginning to disrupt future software development because of the poor handling of software patents, the sheer number of patents, and problems with patent licensing. Future software development will be greatly hindered by these patents, and thus something drastic needs to be done. By eliminating software patents and and promoting technologies that support code sharing via object brokerages, software development will become unhindered once again, with software companies able to make quick progress once again.

References

[1] League For Programming Freedom. Against software patents. Communications of the ACM, January 1992.

[2] Steven Levy. Hackers. Dell Publishing, New York, New York, 1984.

[3] Richard Stallman. What is Free Software.

http://www.gnu.org/philosophy/free-sw.html.

[4] Various. Our business: An introduction to the pto.

http://www.uspto.gov/web/menu/intro.html.