Intellectual Property Rights in Computer Software:

Issues at Stake for Developing Countries

K. Gopinath and M.K. Ravishankar
Computer Science & Automation
Indian Institute of Science
Bangalore, 560 012 INDIA
gopi@csa.iisc.ernet.in
October 9, 1996

Contents

1
2
3
4

Introduction
Background on IPR
Brief History of Software Industry and IPR Issues
Analysis of IPR in Software

4.1 Software Characteristics and Links with IPR :

4.2 Software Components and Corresponding IPR :
4.3 Select Issues and Policy Options in Software : :
4.3.1 Patents : : : : : : : : : : : : : : : : : :
4.3.2 Copyrights : : : : : : : : : : : : : : : :

1
2
3
5

: : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : :

5 Implications of TRIPs for Developing Countries

5.1 Impact on National Economies: A Synoptic View : : : : : : : : : : :

5.2 Impact on Software Production : : : : : : : : : : : : : : : : : : : : :
5.2.1 Negation of Third World Countries' Strengths : : : : : : : : :
5.2.2 Aggravating Technological Backwardness of the Third World
5.2.3 Procedural Impediments : : : : : : : : : : : : : : : : : : : : :
5.2.4 Diculty of Adapting Software to Local Needs : : : : : : : :
5.3 Impact on Issues Concerning IPR Protection : : : : : : : : : : : : :

6
A
B
C

5
6
7
7
9

10
: : : :
: : : :
: : : :
: : : :
: : : :
: : : :
: : : :

10
12
12
12
13
14
14

Conclusions
15
Appendix A: Excerpts from TRIPs
16
Appendix B: Economics of IPR
18
Appendix C: Recommended Changes to Indian Copyright Amendment
Act '92:
20
i

D Appendix D: Recommended Changes to TRIPs in the area of Computer

Software
20

ii

1 Introduction
The recently concluded Trade Related Intellectual Property Rights (TRIPs) / General
Agreement on Taris and Trade (GATT) negotiations are very critical for a country's information economy1. Studies have shown that the information sector has reached at least
25% of the economy in the OECD2 countries, whereas it is only about 12-14% in India[1].
It has also been shown that there is a direct relationship between economic growth and the
size of the information sector[1]. This appears reasonable as additional information input
increases the possibility of more eective use of physical resources in producing various
economic goods.
Since the landmark judgement granting a patent to a software-related invention in 1981
in the US, and the many litigations involving user interface copyrights, the issue of intellectual property in software has become crucial. It has become all the more important since the
beginning of the Uruguay Round of the GATT talks in 1987, where the issue of protection
of intellectual property has been debated in a general setting. In Dec'91, the then Secretary General of GATT, Arthur Dunkel, proposed a draft (the Dunkel Draft Text, or DDT)
for signing by member countries and it was accepted in '93 at Marrakesh. Since the new
TRIPs requires all signatory countries to have patents \in all elds of technology", there is
no special dispensation for software techniques even though this area is quite dierent, as
will be argued in this paper.
While the question of intellectual property in computer software is not well understood,
TRIPs contains many new proposals that aect this area and that may have far reaching
eect in the future. TRIPs systematically extends the rights of patentees[17] well beyond
the provisions in the Paris Convention3. Patent protection has been increased to 20 years,
whereas the Indian Patent Act of '70 has xed it at 14 years except in areas relating to food,
medicines, drugs and chemical processes where it is 7 years. The Indian Act requires that
a patent be worked in this country or else be subject to compulsory licensing after three
years (as in the Paris Convention). TRIPs, on the other hand, considers importation of a
product to be the same as working a patent4 and has no provision for mandatory licensing,
thus making the patent monopoly ripe for abuse. Moreover, the patentee has been extended
the exclusive right of importation of the patented product into any country. Additionally,
the patentee has exclusive marketing rights even while a patent application is pending5 in
one country if a patent is available in another country. In the case of process patents6, the
burden of proof has been shifted to the defendant in litigation concerning infringement.
Many of the provisions in TRIPs run counter to the research on the economics of intellectual property rights (IPR). One of the conclusions of this research is that \easy" inventions
warrant protection only for short duration. In the case of software, most innovations are
As used by an OECD study[2] and Kelkar et. al.[1], information economy includes information technology
and other sectors such as education, broadcasting, publishing, etc., that process information. All these sectors
are likely to be heavily in uenced by advances in information technology in the immediate future.
2
Organization for Economic Cooperation and Development|or \First World"|mostly Western nations
and Japan.
3
Paris Convention is a multilateral economic treaty, begun in 1883, for the protection of industrial
property, dealing with patents, trademarks and designs. India has so far not signed this convention as
it has weakened the bargaining position of developing countries with each revision[36].
4
In software, this does not have the same force as in other industries, there being no manufacturing stage
except making copies.
5
Or 5 years, whichever is shorter.
6
Broadly, process patents do not prevent another party from duplicating an invention as long as a dierent
process is adopted, whereas product patents do.
1

small and incremental but TRIPs has the same duration of protection for all inventions.
See Appendix B for details.
Some of the most vexing issues in IPR are embedded in the area of software technology.
Because of the newness of this industry compared to other well established ones like the
automobile industry, both the legal and patenting establishments in the US have tended to
make ad hoc judgements that have often been confusing or contradictory.
For example, it is argued[37] that \... a patent claiming a pure `algorithm that does x'
would be rejected by the courts, but a patent claiming `a computer running an application
that uses an algorithm that does x' would be accepted as patentable subject matter [in the
US]," and that \... one cannot get a patent on `a oppy disk containing a program that
does x,' but one can get a patent on `a program running on a computer doing x' ". The
customary practices in the US in the software area are important as they are either adapted
in other countries or become de facto positions in multilateral fora.
There is widespread confusion as to what aspects of software technology can be patented
and the extent of rights conferred on copyrights. However, the considerable weakening of
process patents and the systematic extension of the rights of patentees in TRIPs, as well as
some of the judgements that have been delivered by courts in the US are pointers to what
might be future directions.
In this study, we investigate IPR in computer software and their implications for developing countries (sometimes with specic reference to India) with respect to TRIPs. We
rst provide a brief background on IPR in Section 2, and a short history of IPR in software
in Section 3. Section 4 contains detailed analyses of IPR policy issues in software. Finally,
in Section 5, we discuss the impact of TRIPs on developing countries in general, and India
in particular. Appendix A contains some brief excerpts from TRIPs on patents and copyrights and Appendix B has a brief summary of the research so far on the economic impact
of IPR. The last two appendices give some recommendations with respect to copyright law
and TRIPs amendments that may be useful for developing countries.

2 Background on IPR
IPR is a contract between society and inventors and authors to promote science and useful
arts by disclosure. It is an economic tradeo between social benets and private incentives.
Monopoly rights are granted since public goods (including research and development) are
not produced without \incentives" [24]; market forces alone cannot exclude \free riders"
from sharing the fruits of such investment. The economic criterion is that the marginal
cost of greater protection must equal marginal benet to society: availability of more varied
and better products to society versus costs of research and administering IPR, losses due
to monopolistic exploitation and inhibitive eects on inventive activity.
There are three varieties of IPR in the main: trade secrets, copyrights and patents. Trade
secrets do not prevent anyone from rediscovering or reinventing the secrets, as the owner
has not disclosed the intellectual property in his possession to anyone. This approach is
often followed in many high technology areas such as computer packaging, semiconductor
processing and atomic processes (the last by law as a national policy in many countries), as
other forms of IPR require documentation to be led that becomes available to all, including
competitors and unfriendly parties. There is legal protection for prevention of disclosure of
trade secrets to unauthorised persons7 . The practice of reverse engineering can be adopted
7

This is the provision AT&T is using to le a case against BSD Inc. (which is planning to release a version

by competitors as no claim about IPR has been made by the original inventors. However,
since the passing of an act that allows mask copyrights in semiconductor processing in '84
in the US, reverse engineering in chip manufacture has become more dicult. It is very
likely that similar approaches might be adopted in other high technology areas.
Patents give the owner the exclusive right to practice an invention for a specied amount
of time. They can be licensed to others but this is the prerogative of the owner of the patent.
However, the Indian Patents Act of '70 has provision for compulsory licensing in case the
patent is not worked in India (this is similar to the provision in the Paris Convention),
whereas TRIPs allows compulsory licensing only under exceptional circumstances. Patents
do not cover systems8 ; they cover particular techniques used to build systems or particular features that a system oers[5]. Mathematical algorithms, abstract ideas, scientic
principles, etc. are non-patentable.
For a patent to be granted, considerable documentation has to be led (so that others
can practice it after the period of patent protection and also to dene what constitutes infringement) and there should exist no \prior art". It may take considerable time and money
to get a patent but it gives broader powers than, say, copyrights. For example, a patent
is infringed even if the accused is not aware of the patent, whereas a court might accept
ignorance as an excuse in the case of a copyright. The cost of obtaining a domestic patent
in the US is said to be around $10,000, and closer to $50,000 for a broader international
coverage[3]9 . TRIPs goes by the rst-to-le rule for a patent while the current US practice
follows the rst-to-invent rule.
Copyrighting is a simpler procedure for preventing one from copying another's expression of ideas|it does not protect ideas and the subject matter of copyrights need not be
inventions. Copyright law assumes that the same idea can be stated in dierent ways; hence
monopoly over one does not injure public good. Copyrights have been devised to protect
expressions of ideas (e.g., story lines, plots) in books, poetry, novels, lms, plays, paintings,
music and, since the late '70s, to prevent copying of software. It stresses free speech and
self-expression (hence one can reproduce portions for criticism or parody), but this is not
an issue with software[3].
Obtaining copyright registration10 for software is straightforward and quick. In the US
it just involves lling up a form and sending $20 to the Copyright oce along with the
software. In the case of a dispute, it is the responsibility of the copyright owner to prove
that the accused copied the owner's work[3].

3 Brief History of Software Industry and IPR Issues

Software industry is currently an important sector of the information technology industry
and is likely to become a dominant sector in the next decade. Software development between 1950-1980 has had dierent characteristics from the period after 1980. During the
of Unix that is free of AT&T source code but contains some of the underlying ideas), as this company was
formed by individuals who had access to AT&T source code while they were working at the University of
California, Berkeley.
8
This is in the context of pure software systems|patents are allowed on systems that have software as
one component.
9
These costs are suciently high that even US universities have to think carefully before pursuing a
patent application and are lobbying to have a two stage process where a preliminary application at a lower
cost is led and a more comprehensive application within a year (as is the case in some European countries).
10
Under the Berne Convention, registration is not necessary to have a copyright[8].

earlier period, software development was an adjunct to the design and development of hardware. There was little standardization among vendors (except possibly some in the area of
computer languages like Fortran and Algol) and software developed on one machine would
rarely be attempted on other machines. Hence, the craft of programming was essentially a
closed shop in any one company. Third-party software was not much in evidence.
Neither was there much eort towards patenting the developing \computing folklore" as
software was understood to be unpatentable. (For example, in a landmark US judgement
in the Gottschalk vs Benson case in '72, methods that converted BCD to binary without
any reference to any apparatus were held to be unpatentable.) In addition, the techniques
invented were often felt to be too obvious or particular to the hardware. Patents that
were granted almost always were of systems involving software in conjunction with some
hardware. Also, companies like IBM opposed software patents11 in the 60's on the grounds
that there was no way to classify such patents[8]. Additionally, the economic value of
software was not realised as the hardware costs were preponderant at that time. For these
reasons, software had to be protected using the provisions of trade secrets. Copyrights were
not available for software in the US until '78 and in India until '84.
However, with the rise of standards like Unix12 and the IBM PC in the '80's, a signicant
amount of software development is being practiced as a craft by small third-party teams of
programmers. Much of the software sold in the PC market is due to such teams. As more
people have become involved in software development, the issue of intellectual property
rights has become critical. Unfortunately, this has not been due to the invention of new
methods, but primarily due to changes in the legal system in the US and the changes that
took place in its wake in the economic and marketing worlds. Since '81, software patents
have been widely believed to be ocially possible in the US, following an interpretation of
the rulings in a court case (Diamond vs Diehr)13 . This interpretation gave rise to successful
attempts at patenting some well known techniques which had been a part of \folklore",
but had not been written up to constitute \prior art" as they were considered to be either
\obvious" or unpatentable.
Possession of patents helps in the negotiating position of a company both defensively (in
entering into cross-licensing agreements) and oensively (lawsuits claiming infringement).
This has further increased the attractiveness of owning patents. IBM, for example, has
about 9000 patents and this has helped it considerably (through cross-licensing) in getting
access to key software technologies developed elsewhere. In addition, lawyers have had some
success in persuading courts to interpret copyrights in \creative ways", so that they almost
function as if they were \patents" (discussed in more detail in Section 4.3.2). Another
reason for the interest in obtaining IPR protection for software has been the increasing
share of software costs in total system costs. Since software determines the ease with which
a computer can be used, it has recently become a determining factor in choosing between
competing hardware products.
Other changes in the software industry in the late '80s are the explosive growth of packaged software (due to the PC market and the resulting \downsizing"), increased barriers
to the entry of small rms, the maturing of industry with increasing rm size and increas11
The terms \software patent" and \software-related invention" are used interchangeably here, though the
US patent oce uses only the latter (in addition to other categories like computer process and computerrelated inventions that could be implemented in hardware).
12
Unix is a trademark of AT&T.
13
Currently, it is believed that there is no provision for software patents in India but case law is lacking.
TRIPs would necessitate an appropriate amendment to the Indian Patents Act of 1970.

ing concentration and the continuing prominence of hardware manufacturers as software

producers (though not at the same level as before).
Software technology is unusual in that copyright plays a more important role than in
other technologies. However, patents are becoming more important in countries that have
allowed patenting in this area.

4 Analysis of IPR in Software

In this section, we rst consider the behavioural aspects of software over its life-time. These
include features such as the incremental evolution of software, commonplace reinvention of
software techniques, interoperability of various software packages, fast pace of technological
change in software, etc. We examine the implications of these aspects on software IPR.
This is followed by a detailed discussion of the components of software from a technical
angle and their relation to IPR. Contrary to what one might expect, software is not one
single monolithic entity, but can be broken up into several components with varying degrees
of intellectual and innovative content. Dierent forms of IPR protection are appropriate
for the individual components. Furthermore, IPR protection for each of these components
aects software practice in dierent ways. This section can be skipped by the casual reader.
Finally, we examine some selected IPR policy issues in software, indicating the preferred
directions.

4.1 Software Characteristics and Links with IPR

An important feature of software is its incremental evolution over a period of time.

The advances need not be substantial or foundational to result in a better product. It is
neither practical nor appropriate if each of the advances is to be patented. However, if the
inventor does not go in for a patent, but has incorporated an (\obvious") invention in a
product without publishing the technique, considerable legal diculties can ensue if some
one else later patents the technique, as the original inventor has no \prior art" established.
(For example, the technique of backing store was used at MIT in the Lisp machine system
but not published in time before AT&T patented it[5].) This is especially invidious for
software techniques that are reasonably simple for most programmers to discover on their
own but do get patented in course of time14 . Stallman[8] observes that defenders of the
patent system could respond that if the patent system carried out its rules properly, then a
technique that most programmers could discover on their own would be judged \obvious",
and thus unpatentable. However, this requires substantial changes in the workings (i.e.,
stang and procedures) of a patent oce. He further observes that this problem exists
even for techniques that only 1% of programmers working on a certain kind of program
worldwide would discover on their own, as even this 1% is a very large number. Hence, a
technique that is almost certain to get into the public domain in the absence of patents is
likely to become a monopoly for the rst successful party otherwise.
For the above reasons, another important feature of software is the commonplace
and independent reinvention of many concepts[5]. This makes product patenting an
For example, in the Iwahashi case in '89, a patent was granted to Sharp Corp. for eecting multiplication
as the dierence of two squares that are stored in a read-only memory (ROM): a  b = ((a + b)2 ? (a ? b)2 )=4.
This basic idea is often taught to children at school! The US patent oce initially rejected the patent
application on the grounds that it was an algorithm but an appeal against this ruling was successful as the
ROM could be construed as a machine.
14

extremely harmful procedure as it grants an absolute monopoly to the rst party that
registers with the patent oce. The product patenting policy assumes that inventions
are rare and precious and that the inventor has to be given an exclusive privilege as an
encouragement to undertake the dicult and arduous task of invention. However, this policy
is not appropriate in software. The software practitioner works with abstract and ideal
elements[5] at the lowest level. In comparison to inventions in other disciplines, it is therefore
possible for a competent programmer to re-invent many of the techniques independently.
In addition, any reasonable and useful piece of software is likely to use many such
inventions; arranging licensing for each of these inventions is likely to be expensive both in
terms of time and money. This is likely to make software development the preserve of large
companies located in the major OECD countries, as only they would have the resources in
getting the required licenses (either through cross-licensing or by monetary means). Since
the current TRIPs does not support mandatory licensing, it may be necessary to remove
features from a software product so that patent infringement does not occur. This situation
can arise even after product development is complete|if a technique used in the product
is patented by another party subsequently, and it is not possible to get licensing for it at
reasonable rates. This was the case with Xywrite, a company that had to \downgrade" its
software to avoid the use of a popular feature that used command completion to correct
spelling mistakes and expand abbreviations[5].
The real challenge in software is the composition of several individual techniques, taking
into account their various interactions, in developing a product. The crux of the problem
is in modelling some segment of reality consistently at the desired level of abstraction,
not in the invention of new techniques by themselves. For example, the use of software
tools has been pioneered in Unix to build larger software packages. Though each tool is not
substantial in its own right, the ability to compose several of them to build larger structures
has enabled Unix to gain dominance in the technical segment of the marketplace.
Another important aspect of software currently is its technological dynamism and
fast pace of change. If the IPR regime does not take this into account, innovation can
be sti ed. We discuss this further in Section 4.3.1.
Yet another important feature of software is the need for interoperability of various
pieces of software on widely dierent machines. It is quite usual to integrate many software
systems to realise a more useful and more comprehensive software package. Since software
is akin to mathematics in that complete articial universes that have no counterpart in the
real world can be created, the constraints that are present in other physical and biological
sciences are absent. It is not possible to integrate dierent abstractions of various systems
unless they conform to standardised interfaces. The use of standardised interfaces is subject to vagaries of licensing if they are given IPR protection. For example, user-interface
copyrights, as interpreted in the Lotus vs Paperback case15 , may prevent other parties from
incremental innovation or incorporation of the user-interface into larger systems.

4.2 Software Components and Corresponding IPR

A software system generally consists of the following components:

 Program Function, which is the domain of algorithms. Currently patents and trade
secrets are the types of IPR in use.
Paperback used the same user interface as Lotus for its spreadsheet and lost the court case moved against
it by Lotus[4].
15

Program Interface, which covers le formats, application program interface (API) and
OS system calls, communication protocols and specications (for example, very highlevel specications or those in object oriented languages). The issues of compatibility,
inter-operability and openness are very crucial here. User interface is also part of
program interface but this has been separated out below as another category because
of its importance in IPR. Copyrights are mostly used; design patents are used for
ornamental aspects.
 User Interface, which covers programming languages, command languages, menubased dialogs, graphical user interfaces (GUIs), multimedia (colour graphics, sound,
video, animation) and ornamental designs. Same as previous.
 Program code itself, either in binary or text form. Mostly copyrights and licensing
agreements are the rule here.
The impact of TRIPs is not the same on these various components because dierent
forms of IPR protection are either customary now or appropriate to them ideally. Due to
the highly technical nature of the issues involved, we do not discuss this further16.


4.3 Select Issues and Policy Options in Software

In this section, we consider questions such as what qualies for patenting, and what should
be the breadth and duration of patents. We also examine the scope of copyrights in software.
Many of the arguments are illustrated with brief case-studies.

4.3.1 Patents
What is Patentable. As we have discussed earlier, patents are not permissible on math-

ematical algorithms. However, US case law holds that \nonmathematical" ones (especially
computer algorithms) are patentable. This legal distinction does not make any sense to
computer science practitioners yet[22]! In addition, it has been held that a machine system
that employs an algorithm is patentable; the \machine" has been as simple as a read-only
memory (ROM) in the Iwahashi case in '89!
Stallman[9] makes the following clarications and observations about \patents on algorithms" and software patents that are helpful in understanding this confusing area:
Software patents are not, strictly, \patents on algorithms" because no patent
covers just a single algorithm. A claim in a patent describes a combination of
certain steps or elements. If an algorithm involves using all of those steps or
elements, then use of the algorithm is prohibited by the patent. ... As a result, a
single patent can easily make many related algorithms o-limits to programmers.
Sometimes a patent covers so many related algorithms that for practical purposes it covers all possible ways of producing a given result. The well-known case
of LZW data compression (used in the `compress' program and in all modems
that do data compression) is an example of this. Experts on data compression,
the discoverers of other compression techniques, have been unable to nd any
method of computing the same output as the LZW algorithm without infringing
the patents that cover it. This particular case is important in practice because
16

For more details, refer to [23].

a new modem must be able to talk with existing modems; one could conceivably
use a dierent algorithm to produce the output, but it must be the same output.
Another reason software patents are not, strictly, \patents on algorithms"
is because they generally include a statement about what the algorithm is used
for. (This may be narrow or broad.) Thus, you could be permitted to use the
LZW algorithm for something other than data compression.
Patents cover only \mental steps" (computer code) according to law in most countries
but not data (which is typically protected, if appropriate, by copyright). However, according to computer scientists, data and code are interchangable: this follows from one of
the most important insights in computer science. This insight is particularly important
in declarative programming and its applications which arise in many areas including AI
(Articial Intelligence) systems.
Many IPR regimes envision a two-level hierarchy (the \ideas and expressions" dichotomy
which neatly divides intellectual property into patents and copyrights). However, computer
software is typically designed using multiple hierarchies and the two-level hierarchy becomes
completely inappropriate. TRIPs does not address this issue that is important for newer
technologies like software.
Though the patent system is not supposed to grant or uphold patents that are judged
to be obvious[5], many \obvious" patents have been issued in practice. A concrete manifestation of an abstraction is typically considered \obvious". The standard of obviousness
developed in other elds (where even \minor" changes in processing, for example, are considered non-obvious) is inappropriate for software[5]. Some examples of \obvious" techniques
that have been successfully patented are listed below:
 Scrolling on multiple windows. No patent exists on techniques for scrolling a single
window and it is not too dicult to think of how to scroll multiple windows.
 Well known graphics techniques such as airbrushing, stenciling, and combining two
images under control of a third.
 \Natural order recalc" in spreadsheets (recalculation of all spreadsheet entries that
are aected by changes the user makes).
 The technique of \backing store" in window systems.
 Use of exclusive-or to write a cursor.
 Interoperability of machines with various endian formats on a network.
 Verifying at link time that a call on a procedure in a separate compilation unit matches
the procedure's denition[16].
It has been the experience of many system designers that once a decision has been taken
to provide some desired functionality within the constraints of available subsystems, many
situations arise where newer techniques have to be devised for achieving the functionality. These may be suciently constrained by the subsystems that they are \obvious" to
practitioners in that area.

Breadth of Patent Protection. There is a requirement in many patent laws that the

best way of implementing an invention be given in the patent application, but, in practice,
claims are written much more broadly and thus their particular \expression" is diluted. In
addition, the doctrine of equivalents in patent laws makes the scope of a patent broader. If
patent claims are not interpreted broadly, problems with patents like the LZW algorithm,
described above, can be avoided.
It is necessary to interpret claims narrowly as there has been a tendency so far to grant
claims that have wide applicability but little intrinsic novelty. For example, a patent has
been granted to one R.E. Billings in Dec'87 for \Functionally Structured Distributed Data
Processing System", which is, in essence, a client-server system for banking applications. It
is believed that this patent, if vigorously enforced, would cover all banking automation that
uses a central computer (le server) and a client with some processing power (as opposed
to a dumb terminal).

Duration of Patent Protection. Some assumptions behind patenting policies do not

seem to capture today's reality in the area of software.

As argued earlier, software is not like other disciplines because of the ease with which
many inventions can be independently discovered. Hence, it has been argued that it requires
shorter period of protection[29]. Patent policy in the US assumes that technology changes
slowly and that patent protection has to be given for a reasonably long period (17 years).
This may have been appropriate in the 19th century, but denitely not for the last 4
decades in information technology. If the rate of technological change were slow relative
to the time taken for processing a patent application, techniques that have been patented
would be published in time for one to negotiate licenses for patented techniques needed in a
product. However, processing a patent application takes a few years, whereas the marketing
lifetime of a software product is often no more than 6 months to two years17. It therefore
proves dicult or impossible to be on the right side of patenting laws; i.e., avoid infringing
patents. A software developer can be dragged into court for using methods that he did not
even know were being patented. This can eectively kill a software product whose window
of opportunity is short. An additional problem is that patent searches are unreliable as the
classication of patents is not obvious and has serious shortcomings[5].

Conclusions. Given the considerable diculties with the current software patents, it

might be advisable either to do way with software patents altogether, as advocated by

the League of Programming Freedom (LPF)[5], or examine more seriously a sui generis
or hybrid IPR[39] for software. Many practitioners in the software eld do not believe
that software product patents help. It is felt that copyrights might be the right balance
for protection of intellectual property and that user interfaces should be excluded from
copyright protection[8].

4.3.2 Copyrights
Copyrights, though distinct from patents, also require careful consideration as many copyrights are disingenuously being attempted to be defended in courts as \patents"|and some
of the courts have accepted this interpretation[3]. For example, in Apple's suit against
Microsoft, its lawyers invented the theory of \look and feel" and doctrines against copying
17

For example, Windows 3.0 was released in mid-90, Windows 3.1 in mid-92 and NT in mid-93.

of \nonliteral elements" of a program. Even though the case has not yet been resolved,
it has eectively given Apple a near monopoly on one of the most popular graphical user
interfaces|a monopoly that would be characteristic of a patent. If commonly accepted user
interfaces cannot be used due to copyrights on them, interoperability of dierent software
packages cannot be guaranteed.
Another legal device to prove copyright infringement has been to argue that a copyright on a computer program also extends to the computer language that the program uses
or enables. This eectively makes the copyright equivalent to a patent on the computer
language[3]. Such a strategy has succeeded for Lotus against Paperback. Paperback reverse
engineered Lotus 1-2-3 on which Lotus has copyright. Lotus successfully sued Paperback[4]
claiming that they copied the same keystroke commands. Thus, the input command languages and the keystrokes corresponding to commands have been deemed to be covered by
the copyright protection.
In a poll Samuelson[6] conducted at a technical conference in the US around '89, it was
discovered that most programmers are not averse to copyrights not involving user interfaces,
whereas they are opposed to patents in software altogether. The ocial position of organizations like LPF is similar. This form of IPR protection seems judicious for developing
countries as well, since it facilitates the development of software using standardised interfaces without requiring expensive patent searches, and at the same time meeting customer
needs for popular interfaces. It has also been found that without proper enforcement of
copyright protection, many of the software clones developed in India languished due to the
ready availability of unauthorised copies of the original software[21]. In summary, better
enforcement of copyright rules is needed, but not new types of IPR that can constrain the
software industry18 .

5 Implications of TRIPs for Developing Countries

We will explore the implications of TRIPs for developing countries at two levels: one with
a broad sweep and the other at a more technical level. We will discuss the impact of TRIPs
on developing countries in general, and India in particular.

5.1 Impact on National Economies: A Synoptic View

As not much research has been done so far in evaluating the impact of TRIPs on national
economies, we can only make considered judgements at this time. We will look at areas such
as its impact on alleviation of poverty, ecient resource utilization, and the likely impact
of the latter on the environment.
It has been widely understood that ecient resource usage determines many aspects of
a country's life (we use India as an example in the discussion below):
 Growth rate of the economy: Due to inecient resource usage, India's incremental
capital to output ratio (ICOR) is poor. ICOR is a macroeconomic aggregate that has
a critical bearing on the growth rate of an economy.
The growth of the PC industry is due to the \openness" of the architecture and it is likely that a
similar openness in software would not only enlarge the software industry but also help the world economy
in utilizing scarce resources more eectively.
18

10

Sustainability: Owing to environmental abuse and resource mismanagement (typically

resulting from destruction of traditional lifestyles), the food sector in many Saharan
African states has been in a precarious situation for the last few decades.
 International competitiveness: Looking at just one facet, the steel industries in Japan
and Korea are held to be much more energy ecient compared to those in India and
the former Soviet Union. Some commentators have estimated that this factor is as
high as three, and even higher if downstream processing is also considered.
 Pollution load: Poor energy utilization in E. European countries and India has also
resulted in higher levels of pollution.
 Trade balance: India makes heavier and more inecient use of petroleum-based products than warranted, making it very vulnerable to balance of payments problems. It
has been reported that Japan, in contrast, uses less petroleum-based products currently than it did before the '73 oil shock.
Historically, the rst world bootstrapped itself out of poverty by obtaining ready access
to \weakly defended" lands by subjugating native peoples and appropriating resources from
all over the world. Eciency of resource use was not critical at that juncture, but it is of
paramount importance now. Due to the availability of better technology and management
skills, the First World has attained far higher eciency in resource usage|except in aspects
involving \lifestyle". The Third World's chances of bootstrapping itself out of poverty are
small if resource usage is as poor as in India. The pollution load is increasing alarmingly
and sustainable growth of the economy is in doubt due to the destruction of the natural
fertility of soil via waterlogging, desertication, deforestation, monoculture, ground water
misuse, etc.
One possible hope lies in the growth of the information economy which can mediate the
use of physical resources in the economy by creating an awareness of the most eective use
of resources. These may include practices like conserving vegetable matter for composting
instead of burning, careful use of forest resources instead of serial deforestation, careful use
of groundwater and canal water without excessive withdrawals or creating saline conditions,
etc. Primary and other higher levels of education, telecommunication, and even creation
and dissemination of cultural icons that re ect the aspirations and needs of a community
are other aspects of information economy.
For the growth of the information economy, information technology is crucial. If an
IPR regime throttles the growth of information technology|hence, of the information
economy|in the future, Third World countries cannot hope to achieve the desired level
of eciency in resource usage. In addition to hindering the alleviation of poverty in the
Third World, this can also aect the rest of the world by introducing substantial pollution
load and unsustainable growth patterns. For this reason, it is in the interest of all countries to provide for a more favourable IPR regime in information technology for developing
countries like India than TRIPs. (Such a provision already exists in TRIPs for the least
developed countries like Somalia.)
Creative use of information technology is critically needed to make a developing country
like India a meaningfully information-rich society across all economic strata so that scarce
physical resources are more eectively utilized in the economy19. The transition to an


19
As a notorious example of administrative ineciency, World Bank loans worth approximately $24 billion
remain unutilised in India[20] due to its inability to raise internal resources, while the loans continue to incur
interest.

11

information-rich society is possible, especially in a poor country like India, only if the
economy is self-reliant, rather than being dominated by multinational corporations who are
likely to use the developing countries only as auxiliary markets. An information-rich society
requires a competitive domestic software industry to meet its varied and unique needs and
this is not possible with an IPR regime such as TRIPs.

5.2 Impact on Software Production

A self-reliant and eective software industry is congruent with a competitive domestic software industry; this state of aairs has to exist before a large country like India can aspire to
be a global player in the software industry[10], [12], [21]. However, an IPR regime such as
TRIPs can foreclose many options for Third World countries in developing the information
technology sector to the extent necessary, as described below.

5.2.1 Negation of Third World Countries' Strengths

The software industry has a strong appeal for developing countries, as the cost of entry
is low and the only critical bottleneck is manpower training. In the case of India, owing
to various policies pursued since Independence (mostly, highly subsidized higher education
even at the cost of primary education), there is a substantial capability for manpower
training. (Already, India supplies many graduates to the high technology industries in the
OECD countries.)
Software development has another important characteristic that has so far not been
exploited by any of the developing countries20 , namely, the cost of maintenance is high
compared to the development cost. In addition, the development of complex software is
typically an evolutionary process, and staying power is more important than outstanding
innovation. Since manpower costs are low in India, both development and maintenance of
software can be economical.
In this context, any patenting regime that grants monopoly powers for as long as 20
years as in TRIPs (more than the 17 years currently in the US!) cannot but impede or
cripple the growth of indigenous software industry. The above advantages are likely to
be exploited mostly by MNCs that have the legal and nancial resources to engage in
software production. In addition, even patentable techniques developed on-site in Third
World countries by MNCs would become the property of the MNCs.
TRIPs is also inimical to developing countries due to its acceptance of restrictions on
free movement of labour by immigration rules in OECD countries while IPR is expected to
be trans-national. Free movement of labour may be important to third world countries in
providing certain software services; this is currently the bulk of the export monies (about
75% [18]) that accrues to India in the area of software.

5.2.2 Aggravating Technological Backwardness of the Third World

Due to the incremental evolution of software (note, for example, successive revisions of
DOS and Windows, and NT), there exists little opportunity for late entrants to develop
competitive software if they have been thwarted in this evolutionary process. If software
patents become the norm, this problem is likely to be aggravated much further. For example,
a compiler is a basic piece of software that enables a programmer to express algorithms in
20

A beginning has been made by MNCs such as TI and Motorola in Bangalore since the late '80s.

12

a high-level language. However, a class of graph algorithms that accomplishes the crucial
task of mapping program variables to registers in the machine (the problem of register
allocation in a compiler) has been patented in the US. Hence, no compiler can be developed
that uses this important and almost unavoidable step without arranging for a patent license.
This problem might be tolerable if it were one of a few isolated cases. But any worthwhile
software system would need to use a large number of patented techniques, thus making
software production costly.

5.2.3 Procedural Impediments

As TRIPs goes by the rst-to-le rule for a patent21, only those organizations that can
aord the legal infrastructure will be able to succeed in the timely ling of a patent. This
is not in the interest of countries like India whose organizations are not likely to have such
resources.
The Department of Electronics of Govt. of India has placed great emphasis on opening
\Software Technology Parks" at various locations in India, but this policy will be made
ineective if the procedural and nancial aspects of obtaining software patent licenses become prohibitively expensive. Only multinational software companies (which are almost
exclusively American) with subsidiaries in countries like India will have either the IPR or
nancial resources to undertake development of software there under this constraint. This
can permanently tie India into the role of a cheap supplier of software services. This is
extremely unfortunate as India has some of the factor endowments that make software development very attractive. It is true that more sophisticated software tools are being used
for software development with greater productivity by the advanced countries when compared with developing countries, but with appropriate manpower training this deciency
can be bridged[10].
Currently, the software activity in many developing countries can be categorised into
three main areas: on-site services in OECD countries, development of software by subsidiaries of MNCs, and independent native software development. For the rst two categories, the issue of IPR is not critical as the developing countries' role in these cases is that
of a dependent junior partner. However, in the last category, IPR plays a critical role and
native software developers can be hamstrung in their operations if they desire to be independent. It is likely that no independent software developer in India can operate in the future
with a TRIPs patent regime without some tie-up|in a weak negotiating position|with
some MNC.
Even in the US and other First World countries, the implications of patents for software
industry can be deleterious. Expensive legal patent checks have to be conducted before
product design and development can begin. There exist litigation companies like Refac and
Cadtrak in the US which do not carry out any software development but have obtained
an interest in some patents. No procedure is known to avoid being dragged into court
for infringement (in the US) in the case of a patent granted after a software product is
developed. In some European countries, however, anyone already using a technique before it
is patented may continue using it even afterwards[8]. But TRIPs would reduce the situation
in all countries to that prevailing in the US. This would hamper software development in
a peripheral country like India as obtaining details of all patents granted and conducting
needed negotiations to secure licenses is likely to be dicult.
21

This is dierent from the current US practice which favours the rst-to-invent rule.

13

Small software houses in the US are already experiencing the above diculties as they do
not have the clout of larger organizations like IBM to enter into cross-licensing of patents. It
is instructive here to note the experience of Free Software Foundation (FSF), an organization
that believes in making system software like C compilers and Unix available free to everyone
so that users can study, copy, change and improve the software[8]. As FSF uses publicdomain software such as X which employ some patented techniques, they may be subject to
lawsuits for infringing software patents. Others who have used these software have already
been threatened with similar action.

5.2.4 Diculty of Adapting Software to Local Needs

Strong copyright rules, such as protection for program and user interfaces, prevent recustomization and improvement of software, hinder maintenance and subsequent innovation.
They also hinder debugging, detecting viruses, investigating safety, reliability, and systems
integration. These are important issues as the conditions in developing countries may be
dierent from those existing in the developed countries. As an example, many spellcheck
programs can recognise Anglo-Saxon names, but fail to recognise Indian names. It should
be possible to attach auxiliary software to handle such names, in addition to building awareness of alternative spellings for some names. Such additions may be outside the IPR regime
if le structures or the structure of database of names are protected. Though there have
been attempts like the universal character code for representing various language scripts, it
would still be too much to expect all software to be aware of all local variations.

5.3 Impact on Issues Concerning IPR Protection

Productivity software, such as spreadsheets, used widely in developed countries, is too expensive for many developing economies. For example, Lotus 1-2-3 costs around Rs 15,000[19]
or about $500 per machine. (As a comparison, a well paid job in India oers between Rs
4000-Rs 6000/month to a person with a masters degree.) Individuals and small businesses
even in middle income countries, leave alone developing countries, cannot easily aord the
installation of more than a very few such applications (plus Windows 3.1 at approx. $150).
As a result, there is often unauthorised duplication of software in both developed and developing countries22 . If such software is to be reengineered in developing countries for the
above cost reasons, it does have to satisfy standard interfaces while respecting intellectual
property rights extant at the time. These requirements may make this task much more
costly or dicult.
The strategies and options that are being used to control unauthorised duplication is
creating situations where the due process of law is being set aside. For example, an organization called InFAST (Indian Federation Against Software Theft) in India has been seeking
(along with the police) sweeping powers for search, seizure and punishment on suspicion
that unauthorised duplication of software has occurred. Even possession of unauthorised
duplicated software for gain, as opposed to making copies of a copyrighted work, is to be
held as a legal oence leading to mandatory punishment23 . The provisions sought by InFAST are open to abuse and fundamental human rights may be compromised. A similar

It has been estimated that the extent of unauthorised duplication in the US is as much as 50%, and
even higher in developing countries.
23
With literary works, illegal copying of, or trading in, copyright protected works is an oence, but
possession of such illegally produced copies is not[11].
22

14

issue has become important in the US, where the human rights of maintainers of electronic
bulletin boards are under attack on suspicion that condential information has been posted
by users of these bulletin boards[14]. A similar situation has also risen due to raids|without
warrants|by Software Publishers Association in the US to check if system administrators
are complying with legal requirements of how many users can use a package concurrently
and how many spatial copies can coexist in the network[13]. These are known to be dicult
to enforce even with the best of intentions by system administrators. TRIPs also sanctions
such setting aside of the due process of law by its provision for the reversal of burden of
proof in the case of process patents.
There is no doubt that a vigorous enforcement of copyright is not possible in the developing countries unless legitimate copies of imported software are made available at concessional rates commensurate with their ability to pay (say, about a tenth or less of the US
cost, as with textbooks currently). Software is an example of a technology in which a copy
is about two to three or more orders of magnitude cheaper; hence, selling at a lower cost
is denitely feasible. In addition, developing countries can make such a scheme attractive
by reducing the transaction costs for the vendors of imported software by providing for
duplication through well understood means like electronic bulletin boards or the use of le
transfer protocols (ftp), instead of the current costly marketing and distribution channels.
Again, due to the evolutionary nature of much software, such a mechanism is necessary
for updates, bug xes and on-line support. The above proposal is similar (except for the
mandatory registration and payment) to \shareware", which is a cost-eective way of marketing and distributing copyrighted software that some independent software developers
have been using for some time in the OECD countries.

6 Conclusions
In conclusion, it is vitally important that developing economies seek ameliorative reliefs from
TRIPs. The current legal basis for software patents in the US is not sound (among other
reasons, being dependent on the distinction between mathematical and non-mathematical
algorithms, which is not comprehensible to computer scientists). If software patents cannot
be abolished altogether as the League of Programming Freedom has demanded in the US,
a more favourable IPR regime should be made available for developing countries (and not
just for the least developed countries, as provided in TRIPs). Such a regime in OECD
countries would also be in the interest of independent software developers there. It is also
important that if software patents are allowed, their claims should be clearly and narrowly
demarcated instead of being widely interpreted as in the Billings patent (Section 4.3.1).
Another desirable change would be a provision to make important software packages
available to third world countries at substantially lower prices than in the OECD countries;
just as the copyright law (Berne Convention) allows the developing countries to print and
sell textbooks at substantially lower cost, for the exclusive use in those countries.
An IPR regime that a majority of practitioners of software all over the world (including
those in the US) would advocate is roughly the same as what developing countries also would
nd helpful. In summary, this position does not allow patenting in software, but allows
copyrights for all but user-interface software. Without proper enforcement of copyright
protection, development of software becomes unremunerative owing to the ready availability
of unauthorised copies[21].
15

Acknowledgements

Thanks are due to R.M.Stallman, C.E.Veni Madhavan, P.R.Kumar, Matthew Jacob

and Dilip Ahuja for reading and commenting on earlier drafts. Also, thanks are due to
S.Chatterjee and U.Shrinivasa for encouraging KG to look seriously in this area.

A Appendix A: Excerpts from TRIPs

Here are brief excerpts from the TRIPs text[15]; the term PARTY in this text refers to
a contracting nation. The text in square brackets is commentary by R.M.Stallman of the
League of Programming Freedom[7].
PATENT RIGHTS
Article 27: Patentable Subject Matter
1. Subject to the provisions of paragraphs 2 and 3 below, patents shall be available for any
inventions, whether products or processes, in all elds of technology, provided that they are new,
involve an inventive step and are capable of industrial application24...without discrimination as to
the place of invention, the eld of technology and whether products are imported or locally produced.
[Paragraphs 2 and 3 (omitted) provide some exceptions, but none of them applies to software.]
Article 28: Rights Conferred
1. A patent shall confer on its owner the following exclusive rights:
(a) where the subject matter of a patent is a product, to prevent third parties not having his
consent from the acts of: making, using, oering for sale, selling, or importing for these purposes
that product;
(b) where the subject matter of a patent is a process, to prevent third parties not having his
consent from the act of using the process, and from the acts of: using, oering for sale, selling, or
importing for these purposes at least the product obtained directly by that process.
[This rules out any form of mandatory licensing scheme that might mitigate the problem of
patents.]
Article 29: Conditions on Patent Applicants
1. PARTIES shall require that an applicant for a patent shall disclose the invention in a manner
suciently clear and complete for the invention to be carried out by a person skilled in the art and
may require the applicant to indicate the best mode for carrying out the invention known to the
inventor at the lling date or, where priority is claimed, at the priority date of the application.
2. PARTIES may require an applicant for a patent to provide information concerning his corresponding foreign applications and grants.
Article 30: Exceptions to Rights Conferred
PARTIES may provide limited exceptions to the exclusive rights conferred by a patent, provided
that such exceptions do not unreasonably con ict with a normal exploitation of the patent and do not
unreasonably prejudice the legitimate interests of the patent owner, taking account of the legitimate
interests of third parties.
[This would seem to rule out making an exception for software in the scope of patents. Any
exception for a program that would be used widely would enable the patent holder to claim to have
"lost" signicantly.]
24
For the purposes of this Article, the terms \inventive step" and \capable of industrial application" may
be deemed by a PARTY to be synonymous with the terms \non-obvious" and \useful" respectively.

16

Article 31: Other Use Without Authorisation of the Right Holder

Where the law of a PARTY allows for other uses of the subject matter of a patent without the
authorisation of the right holder, including use by the government or third parties authorised by the
government, the following provisions shall be respected:
(a) authorisation of such use shall be considered on its individual merits;
(b) such use may only be permitted if, prior to such use, the proposed user has made eorts to
obtain authorisation from the right holder on reasonable commercial terms and conditions and that
such eorts have not been successful within a reasonable period of time. This requirement may be
waived by a PARTY in the case of a national emergency or other circumstances of extreme urgency
or in cases of public non-commercial use...
[Exceptions in accord with these provisions will be very few.]
(h) the right holder shall be paid adequate remuneration in the circumstances of each case,
taking into account the economic value of the authorisation;
[So it will be expensive for a government to make any sort of exception.]
Article 32: Revocation/Forfeiture
An opportunity for judicial review of any decision to revoke or forfeit a patent shall be available.
Article 33: Term of Protection
The term of protection available shall not end before the expiration of a period of twenty years
counted from the ling date.
[This requires an increase in the term of a US patent in many cases. It also rules out the idea
of making patents for software last for a shorter term commensurate with the rate of progress.]
Article 34: Process patents: Burden of proof
1. For the purposes of civil proceedings in respect of the infringement of the rights of the owner
referred to in Article 28.1(b), if the subject matter of a patent is a process for obtaining a product,
the judicial authorities shall have the authority to order the defendant to prove that the process
to obtain an identical product is dierent from the patented process. Therefore, PARTIES shall
provide, in at least one of the following circumstances, that any identical product when produced
without the consent of the patent owner shall, in the absence of proof to the contrary, be deemed
to have been obtained by the patented process:
(a) if the product obtained by the patented process is new;
(b) if there is a substantial likelihood that the identical product was made by the process and
the owner of the patent has been unable through reasonable eorts to determine the process actually
used.
2. Any PARTY shall be free to provide that the burden of proof indicated in paragraph 1 shall
be on the alleged infringer only if the condition refered to in sub-paragraph (a) is fullled or only if
the condition refered to in sub-paragraph (b) is fullled.
3. In the adduction of proof to the contrary, the legitimate interests of the defendant in protecting
his manufacturing and business secrets shall be taken into account.
COPYRIGHT AND RELATED RIGHTS
Article 9: Relation to Berne Convention
1. PARTIES shall comply with Articles 1-21 and the Appendix of the Berne Convention (1971).
However, PARTIES shall not have rights or obligations under this Agreement in respect of the rights
conferred under Article 6bis of that Convention or of the rights derived therefrom.
2. Copyright protection shall extend to expressions and not to ideas, procedures, methods of
operation or mathematical concepts as such.

17

Article 10: Computer Programs and Compilations of Data

1. Computer programs, whether in source or object code, shall be protected as literary works
under the Berne Convention (1971).
2. Compilations of data or other material, whether in machine readable or other form, which
by reason of the selection or arrangement of their contents constitute intellectual creations shall be
protected as such. Such protection, which shall not extend to the data or material itself, shall be
without prejudice to any copyright subsisting in the data or material itself.
Article 11: Rental rights
In respect of at least computer programs and cinematographic works, a PARTY shall provide
authors and their successors in title the right to authorize or to prohibit the commercial rental to
the public of originals or copies of their copyright works...In respect of computer programs, this
obligation does not apply to rentals where the program itself is not the essential object of the rental.
Article 12: Term of protection
Whenever the term of protection of a work, other than a photographic work or a work of applied
art, is calculated on a basis other than the life of a natural person, such term shall be no less than
fty years from the authorized publication, or, failing such authorized publication within fty years
from the making of the work, fty years from the end of the calendar year of making.

B Appendix B: Economics of IPR

A brief summary of the work in economic theory regarding IPR is given here; for a detailed
discussion refer to [23].
Research in this area has typically concentrated only on patents. Models have taken into
account process/product dichotomy, patent term, breadth of protection and static/dynamic
models of innovation.
Monopoly rights are known to have adverse eects (such as higher cost, fewer number
of products, administrative costs, litigation) and may have unintended spillover eects (for
example, bundling of software may be an anti-competitive strategy) and adverse impact
on diusion of technology, skills, etc. In addition, grave distortions of the market may
take place through pioneer patents, fencing-in a eld of technology through systematic
patenting and strategic licensing to structure industry with \weak" competitors|resulting
in an eective protection longer than the patent term.
There is no clear consensus on the strength of protection needed for securing maximal
social benets. Industries vary in giving competitive advantages to IPR holders: private
returns are typically lower than benets to society unless IPR holders also happen to control
complementary assets. With a weak IPR regime, inventions typically end up in public
domain, especially if there are multiple inventors. With a strong IPR regime and multiple
inventors, immature technologies may be patented as there is a race to patent.
According to some[26], there is no reason for strong IPR protection since leadtime
advantages in an industry, licensing and service agreements, anticopying technologies and
secrecy help the innovator. Similarly, tuning of government policies regarding monopoly,
standards and research support can decrease the need for strong IPR protection. US IPR
mix currently favours an inventor much more than Japan's or EC's [27].
With respect to ecacy of IPR, it should be borne in mind that public disclosure is not
the same as knowledge needed to make economic use of an invention. Empirical studies (for
18

example, at Yale in the '70's) have shown that 60% of patents have only 4 years of useful
life. However, these studies have investigated this aspect only with respect to the OECD
countries. This observation is not valid if developing countries are also considered as the
useful life of a patent may not overlap in developed and developing countries.
Patents impose higher barriers than copyrights. If product variety is not critical to
consumers, higher barriers (i.e., patents) are better, otherwise copyrights are better. If
consumers regard products with similar features to be important, the value of copyrights
increases and a monopoly ensues. This is particularly true for user interfaces.
Investigations concerning multiple inventors and cumulative research show[35] that with
broad patent protection, outside rms do not have incentives to produce second-generation
products. Narrow patent protection, on the other hand, results in greater reliance on
trade secrecy. Furthermore, rst-generation products are held o the markets till secondgeneration products have been developed.
Research concerning cumulative progress and novelty indicates that an IPR regime
favouring high novelty makes patents dicult to displace. As minor incremental innovations cannot be patented, weaker parties cannot compete. However, duplication of research
is avoided. If the IPR regime grants patents for low novelty inventions, there is a strong
incentive to stay in the patent race. \Easy" inventions (those yielding big cost savings with
respect to R&D expenses) warrant shorter protection [29]. In addition, the same study
shows that there should be provision for compulsory licensing or open licensing after 3-5
years unless the patent holder shows existence of special conditions.
Research concerning patent breadth and term has shown [28] that it should be narrow
and long if there is a stable environment and a single product. With multiple products
and cumulative innovation, however, such a policy blocks subsequent innovation. Dynamic
models that have incorporated multiple inventors, cumulative innovation, network externalities, etc. support shorter terms of protection[25]. The latter study also concludes that
if consumers have similar costs of substituting rival products but vary in cost of switching
out of the product class, patent protection should be very narrow and long, and it should
be broad and short in the opposite case.
Research concerning compatibility, network externalities and installed base shows that,
in certain cases, if a product becomes more popular, there is more customer satisfaction (e.g.,
telephones, fax, e-mail, user interfaces, workstations, programs, etc.). A large installed base
also gives some information about the quality of a product. Also, the information needed
to use a product eciently is more easily available.
IPR regime determines strategy: If patent protection is broad and enforcement is strict,
industry standards tend to get adopted widely. Otherwise, unilateral actions of adapters
prevail. If user interfaces are granted copyright protection, rms with brand name recognition would be inclined to introduce proprietary standards [30]. Hence a copyright regime
without protection for user interfaces is needed in software to promote compatibility [31].
Software is an unusual technology (compared to other industries) in that copyright has
so far been crucial and authorship constitutes \progress". Attempts to apply traditional
copyright protection may restrict ecient technology development [33]. In particular, copyright protection for user-interfaces is virtually equivalent to patent protection with a longer
term and without the criteria of novelty and nonobviousness of patents[32]. Also, stronger
copyright rules prevent recustomization of software, improvement and subsequent innovation.
19

C Appendix C: Recommended Changes to Indian Copyright Amendment Act '92:

Software piracy in India is indeed a serious problem. One cannot hope to develop a productive computer industry without good copyright protection of software. While endorsing
the broad eorts underway to strengthen the Copyright Act to aord protection of software in India, we also recommend specic changes to the pending amendments in light of
some technical nuances in computer software. Note that most of these recommendations
are based on international precedents in this arena. Some of the following recommendations
have been distilled from Karjala's excellent article[34].
1. Explicitly introduce the following changes to avoid expensive litigation:
(a) No copyright protection for structural elements of programs (Upheld in US courts
in '92: Saga vs Accolade; Atari vs Nintendo)
(b) No copyright protection for programming languages, rules, or algorithms used to
create program works (as in Japan).
(c) No copyright protection for communication protocols, software-software and hardwaresoftware interfaces (application program interfaces, application binary interfaces)
(d) No copyright protection for functional aspects of user-interface. (Apple vs Microsoft has been almost thrown out.)
2. Explicit permission to allow a small number of copies to be made to study a program
for possible use of its unprotected elements (Possible in US due to fair use provisions
in Copyright law; Opinion of a group of 10 US copyright law professors '89)
3. Seek permission for low-cost copies for educational institutions/ charitable organizations/NGOs/small businesses. (Similar to provisions in Berne convention for textbooks).

D Appendix D: Recommended Changes to TRIPs in the

area of Computer Software
As TRIPs bases itself on the Berne Convention for copyright protection for software, there
is not much controversy here as long as the national legislation has the above recommended
changes. In the case of patents, there are some fundamental problems for computer software
that remain in the IPR regime implicitly advocated by TRIPs.
The real challenge in software is the composition of several individual techniques, taking into account their various interactions, in developing a product. The product patenting
regime assumes that inventions are rare and precious and this assumption is simply inappropriate in software. Some other problems are listed below.
1. US courts make the dubious distinction between mathematical and non-mathematical
(computer) algorithms: this position has serious diculties from the viewpoint of
computer scientists. TRIPs does not clarify this issue.
2. Patents cover only \mental steps" (computer code) according to law in most countries
but not data (which is typically protected, if appropriate, by copyright). However,
20

according to computer scientists, data and code are interchangable: this follows from
one of the most important insights in computer science. This insight is particularly
important in declarative programming and its applications which arise in many areas
including AI (Articial Intelligence) systems.
3. Many IPR regimes envision a two-level hierarchy (the \ideas and expressions" dichotomy which neatly divides intellectual property into patents and copyrights). However, computer software is typically designed using multiple hierarchies and the twolevel hierarchy becomes completely inappropriate. TRIPs does not address this issue
that is important for newer technologies like software.

Recommendations:
1. Disallow software patents.
2. Failing the disallowal of software patents:
(a) Make the criterion for awarding patents more stringent.
(b) Patent protection for 5 or at worst 10 years, not 20!
(c) Provide for mandatory licensing.
(d) Pardon inadvertant use of other's patents if independently reinvented- failing
which, eliminate at least the possibility of "landmine" patents (ie., independent
invention and use of a software technique by a party A that gets patented by
some party B after independent invention by A but before A gets the patent or
A does not apply for it at all). In these situations, the reversal of burden of proof
as present for process patents in TRIPs should not apply.
(e) The cost of introducing the patent system for software in the Third World should
be borne by GATT and/or countries that are insisting on it.

References
[1] V.L.Kelkar, D.N. Chaturvedi, M.K.Dar, \India's information economy: Role, size and
scope," Economic and Political Weekly, Sep 14, '91.
[2] OECD (Paris), \Information Activities, Electronics and Telecommunication Technologies," '81.
[3] R. H. Stern, Micro law column, IEEE Micro, Jun '91.
[4] R. H. Stern, Micro law columns, IEEE Micro, '89 - '91.
[5] The League of Programming Freedom, \Against Software patents," CACM, Jan'92.
[6] Pamela Samuelson, Legally Speaking columns, CACM, '89-'92.
[7] R.M.Stallman, \GATT Treaty Excerpts - commentary," Programming Freedom, Jan
92.
[8] R.M.Stallman, Personal communication.
[9] R.M.Stallman, \Patenting Algorithms and Mathematics".
21

[10] R. Narasimhan, \Is Globalization the Answer to our problems? The case of the Indian
Software Industry," CMC National Fellowship Lecture, Feb 3, '92.
[11] R. Narasimhan, \TRIPs: The case of software and India," Platinum Jubilee Lecture,
80th Indian Science Congress, Jan'93.
[12] M.E. Porter, \The competitive advantage of Nations," McMillan, '90.
[13] Data Communications Magazine, Nov'92.
[14] Mitchell Kapor, \Civil Liberties in Cyberspace," Scientic American, Sep'91.
[15] GATT Secretariat, \Draft Final Act Embodying the Results of the Uruguay Round of
Multilateral Trade Negotiations," Dec 20, '91.
[16] Paul W. Abrahams, \Software Patents: An example of the threat," ACM Sigplan
Notices, Aug'92.
[17] Biswajit Dhar, C. Niranjan Rao, \Dunkel Draft on TRIPS: Complete Denial of Developing Countries' Interests," Economic and Political Weekly, Feb 8, '92.
[18] NASSCOM, \Indian Software Industry," Nov'91.
[19] Advertisement in Economic Times, Dec'92.
[20] Editorial in Economic Times, 23 Jan'92.
[21] Robert Schware, \Software Industry Entry Strategies for Developing Countries: A
`walking on two legs' Proposition," World Development, Vol. 20, No.2, '92.
[22] Allan Newell, \The Models Are Broken, The Models Are Broken," Univ. Pitts. Law
Review, summer '86.
[23] Oce of Technology Assessment (US Congress), \Finding a balance: Computer Software, Intellectual Property and the Challenge of Technological Change," May'92.
[24] Kenneth J.Arrow, \Economic Welfare and the Allocation of Resources for Invention",
in National Bureau of Economic Research, The Rate and Direction of Inventive Activity:
Economic and Social Factors, Princeton, NJ: Princeton University Press, 1962.
[25] Sidney G.Winter, \Patents in Complex Contexts: Incentives and Eectiveness", in
Vivian Weil and John W.Snapper (eds.), Owning Scientic and Technical Information,
New Brunswick, NJ: Rutgers University Press, 1989.
[26] Peter S.Menell, \Tailoring Legal Protection for Computer Software", Stanford Law
Review, Vol 39, No.6, July 1987.
[27] Janusz A.Ordover, \A Patent System for Both Diusion and Exclusion", Journal of
Economic Perspectives, Vol.5, No.1, winter 1991.
[28] Paul Klemperer, \How Broad should the Scope of a Patent Be?" RAND Journal of
Economics, Vol.21, No.1, spring 1990, pp. 113-130.
[29] F.M. Scherer, \Nordhaus' Theory of Optimal Patent Life : A Geometric Reinterpretation," The American Economic Review, vol.62, June 1972, pp.422-427.
22

[30] Peter Menell,\An Analysis of the Scope of Copyright Protection for Application Programs," Stanford Law Review, vol. 41, No.5, May 1989, pp. 1045-1104.
[31] Joseph Farrell, \Standardization and Intellectual Property," Jurimetrics Journal,
vol.30, No.1, fall 1989, pp. 35-50.
[32] Pamela Samuelson, \Why the Look and Feel of Software User Interfaces Should Not Be
Protected by Copyright Law," Communications of the ACM, vol.23, No.5, May 1989,
pp. 563-572.
[33] Dennis S. Karjala, \Copyright, Computer Software, and the New Protectionism," Jurimetrics Journal, fall 1987, pp. 33-96.
[34] Dennis S. Karjala, \Theoretical Foundations for the Protection of Computer Programs
in Developing Countries," Proceedings of the IFIP International Conference on Intellectual Property Rights in Computer Software and their Impact on Developing Countries
(IPRS-93), ed. K. Gopinath, Indian Institute of Science, Aug 1993
[35] Suzanne Scotchmer, \Standing on the shoulders of giants: Cumulative research and
the Patent law," Journal of Economic Perspectives, winter'91.
[36] K. Balasubramaniam, \Pharmaceutical Patents in Developing Countries: Policy Options," Economic and Political Weekly, Annual Number, '87.
[37] Paul Heckel, \Patent War Continues," ACM Forum, CACM, Nov'92.
[38] Paul Heckel, \Debunking Software Patent Myths," CACM, Jun'92.
[39] J.H. Reichman, \Legal Hybrids Between the Patent and Copyright Paradigms," monograph presented to ATRIP and tenth annual Conference on Information Law Toward
the 21st Century (Amsterdam, June, l992).

23