http://www.ffii.org

The Danger of Software Patents to Innovation

* Threat to competition
* Threat to SMEs
* Threat to open source
* Threat to personal creative freedom

Underlying them all is the notion that copyrights are a good way to protect software, which reflect the work and real investment that has gone in to it. But patents don't, and aren't.



Also good:

A good summary of some of the key arguments
 http://elis.ugent.be/~jmaebe/swpat/why.html#ecommerce

Comments of leading economists:
 http://www.researchineurope.org/policy/patentdirltr.htm

Petition by leading computer scientists:
 http://www.greens-efa.org/pdf/documents/SoftwarePatenting/petitiontoEP_EN.pdf



Statement by the European small business organisation CEA-PME:

 http://swpat.ffii.org/papers/eubsa-swpat0202/ceapme0309/index.en.html

"E-patents and financial investing", by Laura Creighton, a software venture-capitalist.
 http://www.vrijschrift.org/swpat/030508_1/


===========================================================================================





** Threat to Competition:

Software patents are more about control than investment.

(a1) Patents hurt competition.

Software is already protected by copyright. This spurs competition, giving innovators a breathing space to get established, before competitors can develop their own implementations.

But patents grant monopoly rights on an invention for twenty years. This kills competition dead.


(a2) Network effects make software patents especially dangerous.

"Winner takes all" is especially prevalent in software. If a piece of software cannot interoperate with a market leader, it is effectively out of that market.

A typical modern piece of software has thousands of functions, and thousands of subroutines, each of which could be the subject of patents. If this is the case a market leader can "tie in" a much larger
market monopoly than just the functionality covered by the patent.

The danger is especially acute with regard to communication protocols, for example file formats or web-service specifications. Patents in such areas can allow market leaders to leverage on their dominance in one sphere, to dictate who they will permit to compete with them in another sphere.


** Threat to SMEs

(b1) Patents are out of step with the investment needs of the software market.

According to venture capitalists, a typical time horizon from investment to product for a new pharmaceutical may be 15 years and a cost of $400m; for software, 6 months and a few tens or hundreds of thousands.

Software R&D is relatively cheap; and being first to market is a big advantage and incentive to innovate. Software SMEs have not needed patents to flourish and grow.

The hard work in software development is the actual expression and the debugging of the program. Copyright is a good fit because it directly rewards this hard work of implementing the program, and debugging the program to get it right. The more work that is, the more the copyright is worth.

On the other hand the sweeping 20 year protection granted by patents (geological time in the software industry) is entirely out of scale to the creative input required (a mere sketch of how it /might/ be implemented).



(b2) Patents are expensive, and uncertain to rely on.

Copyright is automatic, and free. Copyright cases are much cheaper to fight; and copyright infringement is much easier to prove (or disprove), because it relates to an explicit taking.

On the other hand, software patents are also risky to rely on in court: because it is impossible for patent offices to effectively search all of the computer programs ever written, it is very hard to guarantee whether or not a patent is sound, or whether it will be overturned in court. There is also ample scope for lawyers to debate the patentability of the subject matter itself; the obviousness (or not) of the inventive step; and even the patent's relevance, whether the alleged infringement is actually covered by the language of the patent claim.

The scale of these uncertainties can be judged by the fact that the few companies in Europe which offer patent insurance specifically exclude software patents, because "it would just not be possible to offer a premium that would be economic".

This uncertainty plays into the hands of the biggest companies, with the best lawyers and the deepest pockets. But in any case, to fight a patent case through all its stages costs about £1m in the UK, and about $2m in the USA. If you cannot credibly spend this to enforce your patent, it is worthless. Similarly, if you cannot credibly spend this to defend yourself against somebody else's patent, you had better fold.

SMEs therefore overwhelmingly see patents as a threat rather than an opportunity. The push for software patentability is being led by the largest companies, and their corporate lawyers.

(b3) A minefield for developers

As Richard Stallman has put it:

"Software patents are like landmines for programmers. At each design decision, there is a chance you will step on a patent and it will destroy your project. Considering the large number of ideas that must be combined in a modern program, the danger becomes very large."

Unlike copyright, you cannot be sure that you are not infringing a patent just because a program is all your own independent work. You do not need to have known about a software patent in order for your work to infringe it, you do not even need to have known that the patent owner or their product ever existed. The patent applies to all-comers, regardless.

But independent reinvention is very common in software, with innovations very often 'of their time', as a particular challenge become apparent. Such steps may not be "obvious" in the patent-law sense (ie an unimaginative combination of existing elements), but they are entirely routine in an activity where creative problem solving is a daily requirement.
Certainty that you are not infringing anybody else's patent in a program is almost impossible, because the patent database is so large, and with so many subroutines in a program it is entirely impractical to search the database for every one.


** Threat to Open Source

(c1) The importance of Open Source

Open source software has become a tremendous enabler for SMEs and for innovative projects, because it provides a well-tested inexpensive platform to build on, which can be adapted to suit particular needs.

Thus, for example, the Public Whip is possible because it is running an Open Source content language (PHP) on top of an Open Source web server (Apache), accessing an Open Source database (MySQL), all running on an Open Source operating system (Linux), and able to talk to the world through an open standard, royalty-free protocol (the Internet, specifically TCP/IP).

Similarly, the thriving UK set-top box industry almost entirely built on Linux, because its ease of availability and open source nature made it easy to adapt to new hardware, which made it possible to develop fast.

Government too is waking up to the opportunities of Open Source. Freedom to re-use and adapt the code means that different organisations (eg local authorities) can adapt software to suit changing needs and new opportunities, pool the enhancements, and access all the improvements made by others. And the open availability and re-usability of the source code guarantees that an "open standard" does not hijacked into a "single vendor lock-in" by the need to communicate with that vendor's idiosyncratic interpretation.

(c2) The threat of lock out.

It is sometimes argued that because someone has the right to choose whether to keep their source code secret as closed source, or to publish it as open source, that similarly they should be allowed to choose whether to patent it, or not to patent it.

The difference is that copyright does not prevent anybody else creating their own version and making it open source. So open source can, with enough time and trouble, eventually catch up. But a patent locks down the functionality for twenty years. Since the point of open source is that it is freely available for copying and redistribution, it is impossible for open source to licence the functionality unless the patent owner offers to make it available royalty-free. If this functionality is essential for compatibility (eg a web-services protocol; or eg the ability to implement some function in a spreadsheet), then effect is to shut open-source out of a market which is vastly wider than just the scope of the patent.

Open source is a useful resource, which is made possible by the zero marginal cost of redistributing an intangible good. The costs of allowing shutting off avenue after avenue to open source should be carefully weighed.
(c3) Open source as a target

Companies in the most actively competitive markets seem to be largely unafraid of Open Source. In such markets, where most of the proceeds of software sales are having to be actively re-invested to keep ahead of the competition, open source has its work cut out to keep up.
But open source is seen as an ever more real threat by companies living off ongoing monopolistic rents in mature markets. The competition posed by open source could be just what is needed to shake these markets up, and create an environment which would reward real innovation.

But such entrenched companies have an incentive to try to stop open source by any means available, and software patents put a very powerful weapon in their hands.


** Threat to personal creative freedom

(d) Many programmers feel that writing a computer program is a creative act, most like writing a book, painting a picture or composing music. They feel that this is most appropriately protected by copyright, which prevents wholesale taking of the whole work.

But patents take away the abstract tools of their trade, just as if a novelist were no longer allowed to arrange words in a particular form of clause, or a lawyer no longer allowed to use a particular form of provision in a contract, because somebody else owned it.




There are three key issues at issue about the Directive on Tuesday:
* program claims (freedom of discussion)
* interoperability
* most importantly, the meaning of the word "technical" (ie what is patentable, and what isn't).

Our understanding is that there is increasing concern from ministers all across Europe about these issues, with a move to take more time to look at them again and try to get wider agreement.


Politically, the most important argument may be that the Directive in its current form just won't pass the European Parliament, because it gives *nothing at all* in all the three of these most important areas where the Parliament expressed concern:

1. Program Claims (article 5.2). Software patents are to be able to cover publication of program content in machine-readable form, as well as its actual executing it on a computer.

But programmers find the natural and most explicit way to discuss algorithms is through code fragments. There is *nothing* to give explicit reassurance that ordinary discussion of algorithms in the form of code fragments will not be silenced by program claims. Websites with archives of such discussions could be subject to take-down orders. This is surely wholly contrary to the idea of patents spreading understanding.

A provision that such discussion should be considered 'fair use' would at least offer an olive branch here. It would also be useful to clarify the conditions code on such websites would be covered by the 'experimental use' exemption.


2. Interoperability (article 6a)

There is *nothing* in the proposed draft, short of a full-scale EU Competition commission investigation, to prevent dominant patent owners locking out specific competitors from interoperating by refusing patent licences.

The European Parliament wanted to allow automatic unfettered use.

As a compromise Denmark has suggested creating new fast-track procedures to allow courts to demand compulsory RAND licensing (ie a paid licence rather than a free one, but made available to all, and everyone pays the same).

This would still be difficult for Open Source, but would at least open the doors for commercial competition. However the Irish draft rejects it.


3. Technical (articles 2, 3a and 4)

According to the European Patent Convention, computer programs are excluded from patentability, to the extent that the claimed invention relates to the computer program "as such".

The directive legislates for a framework is whether the crucial test for patentability is whether the claimed "computer-implemented invention" has a "technical effect".

This has given supporters of patentability a figleaf that "pure software as such will not be patentable".

But what is "pure software", and what is "technical" ?


There are essentially three positions.

(a) There is general agreement that newly invented physical processes should be patentable, regardless of whether software control is needed for the process to be achievable. The classic example is an anti-lock braking system, if a particular non-obvious process of applying the brakes has a particular physical benefit.

This was the European Parliament's view, and is supported by Germany -- specifically that "control of the forces of nature" is technical, but improvements that relate only to the internal processing of data are not technical.

It is the line taken by those most concerned about software patents.



(b) Past UK case law goes further than this, that methods which merely address generic data relate to "computer programs as such", and are therefore not patentable, but that the claimed invention becomes technical if the data has a specific technological relevance beyond this. Thus the current Patent Office manual states:

"1.26.4 The reference in Merrill Lynch to Vicom involving an increase in speed (see 1.26.2) does not mean that an increase in speed of itself is enough. This point was considered in Options Clearing Corpn Inc's Application (unreported) when the hearing officer concluded that Vicom was allowable because it produced an advance, namely an increase in speed, in a technical field, namely the technical field of image
enhancement, and not simply because of the advance itself".


(c) However since about 1997 the EPO has gone further than this, and now takes the line that all computing, by its nature, has "technical character", and so any new technique which has a practical usefulness makes a "technical contribution".

Thus a new algorithm "as such" is not patentable; but an algorithm with any identifiable practical usefulness (eg runs faster, uses less memory) is patentable; and so (under program claims) is any record of the algorithm in machine readable format.


This third option is what the draft text proposes, and what ministers are backing (despite statements that "nothing shall be patentable which is not patentable already).

Examples of what the EPO has already decided is 'technical':
- using the same data without retyping to update both a sales ledger and stock control (Sohei)
- emailing the recipient of a gift, to ask where they would like their gift sent to (Amazon Gift Ordering)
- tabbed windows, making more efficient use of limited screen real-estate (Adobe)
- using wireless links to exchange pupil data in schools between computers (Bromcom)

... etc (the list, unfortunately, is almost endless).

This definition of "technical" is the heart of the matter: without something a lot more concrete in the text, it opens the gates to almost anything being technical, and therefore patentable.


For many programmers, this is the most heartfelt reason for opposing software patents of all.