Open Enterprise
Glyn Moody
Subscribe to this blog
About Author
Glyn Moody's look at all levels of the enterprise open source stack. The blog will look at the organisations that are embracing open source, old and new alike (start-ups welcome), and the communities of users and developers that have formed around them (or not, as the case may be).
Contact Author
Email : Glyn
Red Hat Makes its Position Patent
Published 11:37, 05 May 09
Six months ago I noted that the European Patent Office had embarked upon a fairly abstruse process:
a referral of a “point of law” concerning software patents by the President of the European Patent Office (EPO) to the EPO “Enlarged Board of Appeal”, something that seems to happen quite rarely. Now, you do not have to be a genius to see the problem with this; essentially, the EPO is asking itself whether it wants to widen its own jurisdiction, increase its power and boost its income by allowing software patents. Unless the Enlarged Board of Appeal consists entirely of self-denying, altruistic masochists, I think we can all guess what the answer will be.
The comments period ended last week, and just before the deadline passed I was wrestling with the issue of whether I should send something in. As regular readers of this blog will know, I am not particularly shy and retiring when it comes to offering my opinions on matter dear to me, but on this occasion, I decided not to send anything.
My reasoning was that this was an extremely technical consideration of the issue of software patents, and that the people pondering the matter would not be interested in vague philosophical waffle about why software patents were a bad thing. They would be looking for keenly-argued, legalistic comments of the kind I was manifestly unable to provide.
Instead, I thought it better to leave this one to those better able to obtain some heavy legal advice on what should be written, and how. Among those doing precisely that, was Red Hat:
Today Red Hat took its efforts to confront the problem of software patents to new ground by filing a brief with the European Patent Office. The brief explains that software patents hinder software innovation, and that there is a sound legal basis not to expand availability of such patents in Europe.
Now, a little while back I wrote a piece called “A Question Red Hat Must Answer” - the question being where exactly it stood on software patents. Happily, this present submission to the EPO leaves us in no doubt. But it goes well beyond establishing Red Hat's bona fides: it presents one of the best introductions to why software patents are so harmful to free software.
It begins by presenting a short history of software patents:
The historical record of innovation in software shows that, both for open source and proprietary software, remarkable progress in the U.S. and Europe occurred prior to the time that software patents became generally available. Innovative open source software projects began to appear by the early 1980s.
At that time, software patents were relatively few in number and case law was interpreted to limit their availability. See Diamond v. Diehr, 450 U.S. 175, 185-86 (1981). By contrast, it was already settled that copyright law covered software. Thus the early innovators of open source software had no reason even to consider obtaining patents on their work, and in fact opposed software patents.
Such opposition is not surprising, because the open, collaborative activity at the heart of the open source model is fundamentally at odds with the patent system. Patents exclude the public from making, using, or selling patented inventions. An open source developer seeks to contribute code to the community -- not to exclude others from using the code. The exclusionary objectives of the patent system are inherently in conflict with the collaborative objectives of open source.
It then pinpoints the problem with software patents:
Software patents are generally claimed in relatively abstract language, compared with patents concerning other subject matter, and as a result their boundaries typically are vague and ill-defined. Therefore it is often not possible to be confident that a particular patent does not read on a particular new product.
Moreover, there is no reliable, economical method for searching the hundreds of thousands of existing software patents that would allow a developer to rule out the possibility that a new product (which may have hundreds or thousands of separate components and features) infringes one or more patents. Thus simply by virtue of producing and marketing an innovative software product, a software developer assumes an unmeasurable risk of a costly patent infringement lawsuit.
It concludes its historical discussion thus:
In sum, legal changes in the U.S. that have allowed software patents have not served the purpose of promoting innovation. Experience has shown that such patents are not only unnecessary but actually detrimental.
They discourage innovation, by imposing costs and risks on software development that would not otherwise exist. As discussed below, however, the U.S. Court of Appeals for the Federal Circuit recently appeared to recognize that the existing system must be substantially modified, and it has provided an approach for repairing the system.
The last point being a reference to In re Bilski, which many believe could substantially change the US position on software patents.
Red Hat's submission then goes on to interpret the main definition concerning software patents in Europe, Article 52 of the European Patent Convention, and proposes doing so “According to Its Plain Language”, particularly with reference to the vexed issue of what on earth the famous “as such” included there means:
Under the approach here proposed, Article 52 should be read according to its plain language. "As such," as used in Article 52(3), is properly interpreted according to its ordinary meaning of "in and of itself or themselves, separate and apart from other things or processes." Under this approach, a computer program could be part of a larger patentable invention, even though it could not in and of itself be a patentable invention.
This possibility is noted in T 0204i93 AT&T, where the Board said that "a computer may control, under control of a program, a technical process and, in accordance with the Board's case law, such a technical process may be patentable." The Board inT 0204/93 further noted that "computer programs as such, independent of such an application, are not patentable irrespective of their content, i.e. even if that content happened to be such as to make it useful, when run for controlling a technical process."
Having done this, it then finishes by addressing the particular points of the EPO's questions (also discussed in my original post last year). It summarises its views as follows:
For the reasons set forth above, Article 52 should be read according to its plain language. "As such," as used in Article 52(3), is properly interpreted according to its ordinary meaning of "in and of itself or themselves, separate and apart from other things or processes."
Under this approach, a computer program could be part of a larger patentable invention, but it could not in and of itself be a patentable invention. Reading extraneous distinctions concerning the technical character of computer programs into the words "as such" has created a set of intractable interpretive problems. We therefore respectfully request that the Enlarged Board reaffirm the plain language of the computer program exclusion. This approach is consistent both with the language of the EPC and sound policy promoting innovation in software development.
Red Hat is to be commended not only for calling for software patents to be judged against a literalistic – and hence minimalist - interpretation of the European Patent Convention, but also for producing such a clear introduction to what is a hideously complex area. Its submission is well worth reading by anyone who wants to get their head round the subject without guaranteeing themselves a serious headache along the way.
Follow me on Twitter @glynmoody.
Print