Brandon Evenson is a JD candidate at Osgoode Hall Law School and is taking the Patent Law course.
A patent system is a balancing act. On one hand, a patent system provides incentives to innovate, commercialize, and disclose innovations to society. On the other hand, a patent system discourages the proliferation of innovations in society by giving a monopoly on disclosed inventions. Opponents have long argued that the deleterious effects of a patent system on society outweigh the beneficial effects. Indeed, there was a period in the 1860s and 1870s when patent systems all around the world were abolished. Prussia abolished their patent system in 1863, the Netherlands abolished their system in 1869, and Japan in 1873. The US’s attempt to abolish their system barely failed at the Senate by 3 votes.
Attitudes towards patent systems have since changed. Today, there is a generally held belief by most modern states that the benefits of a patent system outweigh the deleterious effects. This is no doubt due to the refinement of patent law as well as the maturation of industrialization. Yet despite the return of patent systems, some subject-matter continues to remain un-patentable or subject to significant limitations. Many countries are still reluctant to grant patents for software fearing that technological progress in this volatile industry would be impeded. But, what is so unique to software that, should patenting be allowed, it tips the scale in favour of the deleterious effects and impedes technological progress instead of promoting it as in other patentable subject-matters? Has not the software industry matured significantly?
A recent post by Ciaran O’Riordan on the PatentlyO blog canvasses some of software’s material differences as compared to other subject-matter. Based on these differences, O’Riordan advances arguments on why the patenting of software should not be allowed. O’Riordan observes that there are a small number of large companies with well-known products, and there is a mass of small companies. He attributes this structure to the low cost of entry for software development firms. Research and development resources are inexpensive and the skills required can be self-taught. All that is required is a computer, an operating system, a compiler, and a programming book/resource. Most, if not all, of these tools can be found for cheap or free. But how does low entry cost and industry structure have any effect on whether the patenting of software should be allowed? O’Riordan fails to explain how this supports his position. He does seem to imply, however, that small firms will be discouraged from patenting their software because of the prohibitive costs, and large firms will patent all of their software thus restricting and discouraging smaller firms from entering the market and developing. This would prima facie be undesirable since small software firms can make some very innovative and useful products. Perhaps the software industry differs from other industries where it is predominantly the large companies that make the truly innovative products due to research and development costs.
It is doubtful, however, whether other industries are really so different from the current software industry. Basement inventors still innovate and create inventions with very little resources (eg. Kick Spike). The better counterargument, however, may be that the current industry structure may actually be caused by the lack of software patentability. Without software patents large companies have been able to copy the innovations of smaller firms. The most recent example of this has occurred with individual application developers for mobile devices such as Apple’s IPhone. Why should small companies invest significant time and resources in developing truly innovative software if a larger company is able to copy without consequence? This also impacts the ability for a small company to grow as investors will not invest money to commercialize a product if there is no guarantee of protection. The i4i story is a good example of how a software patent was able to secure the necessary venture capital funding for expansion. The i4i story also supports the contention that large software companies do copy the innovations of small software firms.
O’Riordan goes on to argue that software patents will be too restrictive on software developers that sit in IT departments of medium sized companies. These developers are responsible for keeping email flowing, making internal software, and extending existing software. “The timelines and budget for patenting are out of sync with the speed and costs of writing software.” There are two problems with this argument. First, it is doubtful whether IT departments are really developing sophisticated pieces of software that would merit patent protection or would infringe existing software patents. Furthermore, software development is not as frenzied as O’Riordan seems to suggest. For example, many companies still maintain legacy mainframe systems that house core business applications. Software may undergo slight modification to accommodate unique business requirement, however, the core functionality and framework typically remains unchanged for many years. The number of slight software modifications that may merit or infringe a patent is probably quite low. The second problem is that if, in-fact, a truly innovative piece of software was developed in-house, then a patent system would allow that company to recoup the costs of the development. If the time and effort is invested in developing an application that may outlast the hardware upon which it runs, why should not the time and effort be invested to patent the software? This would also provide a much-needed incentive for companies to disseminate their in-house innovations. Without this incentive companies are not likely to disclose for fear of giving away competitive advantages.
Lastly, O’Riordan argues that software patents will discourage and inhibit user communities of open source software from developing free or cheap software. Should a portion of that free software be subject to a patent then the patentee would effectively have a veto over its distribution. O’Riordan cites Linux as an example of the impact open source software can have and how patents could impede such important developments. These difficulties are not unique to the software industry however. For example, generic pharmaceutical companies are restricted from selling their imitation drugs at substantially discounted prices because of the monopoly granted to brand name companies. This is the price that is paid for all the other benefits that come along with a patent system. Furthermore, if innovation is truly what is desired, then duplication of already existing software should be avoided. Patent protection will encourage open source developers to develop software that is innovative, not imitative. Despite the lack of Canadian cases concerning software patents, the Canadian Intellectual Property Office has provided guidance on the filing of software patents. Other jurisdictions are also taking a closer look at the merits of software patents. The European Patent Office held a conference in 2007 specifically examining the issues. If volatility and maturity of the software industry were the initial justification for disallowing software patents, certainly it is about time the subject-matter be re-examined in light of the progress achieved to-date and the structure of the industry.