The Proposed Software Directive: A User's Comments
Simon Davies
Patent Attorney, D Young and Company
Please note that views expressed here are purely those of the author, and do not represent those of the author's employer or any other organisation he is associated with.
This is a Commentary published on 4 July 2003.
Citation : Davies, S,'The Proposed Software Directive: A User's Comments', 2003 (1) The Journal of Information, Law and Technology (JILT).<http://elj.warwick.ac.uk/jilt/03-1/davies.html>. New Citation (as at 1/1/04: <http://www2.warwick.ac.uk/fac/soc/law/elj/jilt/2003_1/davies/>.
1. Introduction
I have been asked to comment from the perspective of a user (i.e. industry) on the papers by Christian Koboldt and Robert Gehring. However, before doing so, I would like spend a little time discussing the background of the proposed Software Directive. This is important because one of the problems surrounding the Directive is that its purpose and intentions have been frequently confused. This is perhaps not entirely surprising, in that patents are a highly specialised field, and software patents a specialisation within this specialisation. It is therefore important to level set, in order to ensure that everyone is assessing the situation on the basis of the same (correct) factual matrix.
The legal provisions governing the patentability of computer program inventions in Europe are set out in the 1973 European Patent Convention (EPC). In particular, statutory subject matter is determined by Article 52 EPC as follows:
Article 52 EPC
Patentable Inventions
1. European patents shall be granted for any inventions which are susceptible of industrial application which are new and which involve an inventive step.
2. The following in particular shall not be regarded as inventions within the meaning of paragraph 1:
a) discoveries, scientific theories, and mathematical methods;
b) aesthetic creations;
c) schemes, rules and methods for performing mental acts, playing games or doing business, and programs for computers;
d) presentations of information;
3. The provisions of paragraph 2 shall exclude the patentability of the subject matter or activities referred to in that provision only to the extent to which a European patent application or European patent relates to such subject matter or activities as such.
Article 52 EPC therefore provides some form of exclusion of patentability in relation to computer programs, but the qualification of Article 52(3) makes the scope of this exclusion difficult to determine. The practice of the European Patent Office (EPO) has developed in a way that is generally quite favourable to software inventions. The tone of this approach was originally set by the Vicom decision regarding a method of two-dimensional data convolution, which was initially rejected as being a mathematical method and a computer program. On appeal however, the Board of Appeal held that claims restricted to the convolution of digital images pertained to real world physical entities, and so the invention could no longer be regarded as purely an abstract mathematical method. In addition, it would not be appropriate to deny patentability merely because the processing method happened to be implemented on modern equipment, namely a computer system.
The general practice following Vicom and other subsequent EPO decisions has broadly treated computer program inventions as patentable subject matter, provided that they have some technical character/contribution/effect. This meant that all inventions that might reasonably be considered as within the realm of computer science, for example procedures at the operating system level to improve machine operation, or generic algorithms, techniques and functionality at the application level, would normally be regarded as outside the exclusion of Article 52(2) EPC. Such inventions could then be patented, provided of course that they meet the normal conditions for novelty and for inventive step, and also provided that they are claimed as a system and/or a method. Indeed, many thousands of software inventions have already been patented in Europe.
Another important milestone in the treatment of software inventions was a pair of IBM cases. In these cases the underlying inventions were clearly patentable according to the above criteria established by the EPO. However, the claims here were specifically directed to a computer program, rather than to a system or to a method. The Board held that such computer program claims were indeed allowable.
Note that a computer program claim may be expressed simply as a computer program for implementing the method of a preceding claim. If such a method claim is already regarded as patentable, then it is hard to see that also allowing the corresponding computer program claim represents a substantive difference in the fundamental nature of the invention being patented. However, superficially at least, it may be surprising that although the EPC clearly includes some form of exclusion for computer programs, it is now possible to obtain a patent with a claim that begins 'A computer program....'.
This is not meant to suggest that the IBM decisions are incorrect, or that the general treatment of computer program inventions by the EPO is wrong. Rather, the EPC itself is unclear, and alternative interpretations are plausible. The EPO have adopted one particular interpretation, which is certainly a very reasonable one, but it is perhaps now impossible to know whether or not this was the approach that was originally intended when the EPC was first created.
The Commission became involved in the treatment of software patents back in 1997, with the Green Paper on the Community Patent and the Patent System in Europe. This document was primarily focused on the stalled Community Patent, but also addressed a couple of other issues. One of these was the need for harmonisation (often a prerequisite for the Commission to act), and the other was the rapid development of the so-called Information Society, triggered by the explosive growth of the Internet. The Green Paper posed two main questions in relation to software patentability. Firstly, it asked whether there was a need for harmonisation, in other words, was there any evidence for a lack of harmonisation. The second question was whether the exceptions to patentability in Article 52(2) EPC should be deleted.
In the subsequent Follow-Up to the Green Paper, the Commission appeared to have reached some firm conclusions. They noted the success of the US software industry, in conjunction with the strong patent protection that had become available for software inventions in the US. The Follow-Up document stated that: 'the European Parliament supported the patentability of computer programs ... the Commission shares this analysis'.
The Commission also recognised that there was a problem due to the lack of transparency of the EPC. Thus as previously indicated, the treatment of software inventions by the EPO is not uniquely or unambiguously derivable from the EPC itself, but rather only one of several possible interpretations. They pointed out that this could cause problems if national Courts adopted a very different interpretation, since this would lead to a lack of harmonisation. In addition, the situation was clearly confusing to SMEs, who might naively interpret the EPC as simply prohibiting the patentability of all software inventions.
The Follow-Up document therefore proposed two 'urgent' actions. The first of these was for the Commission to prepare a Directive to ensure the uniform treatment of computer program inventions throughout the Community. The second proposal was that 'the Contracting States to the Munich Convention will … abolish computer programs from the list of non-patentable inventions'.
A diplomatic conference to revise the EPC was duly scheduled for November 2000. The Basic Proposal for revision going into the conference was to drop the computer program exclusion from Article 52(2) EPC. However, this turned out to be one of the few significant provisions of the Basic Proposal that was not incorporated into the final Revision Act adopted by the conference. It was indicated that this should not be regarded as a criticism of current EPO practice in relation to software inventions. Indeed, a decision not to amend a law is generally regarded as a confirmation of existing practice under the law.
There are probably two main factors behind why the Basic Proposal was not carried at the Diplomatic Conference. The first was lobbying by the Open Source movement, which is strongly opposed to software patents. Unfortunately, this lobbying is perhaps based on the mistaken premise that deleting the computer program exclusion would open the flood-gates to software patents (rather than simply represent a clarification of existing practice).
The second important factor was the significant change in practice in the United States regarding business method inventions. Thus in 1998, the Court of Appeal for the Federal Circuit (CAFC) in the State Street Bank case comprehensively rejected the notion that there was any prohibition on the patenting of business method inventions in the United States. This triggered a rapid expansion of activity in this field in the USA, and naturally led to discussion as to whether Europe should follow suit. Since many business method inventions are implemented on a computer, unfortunately this debate rapidly became mixed up with that on software patents.
The above factors led the Commission and the UK Patent Office to launch consultation exercises in late 2000 to try to determine what should be the policy towards both software inventions and business method inventions. It will be noted that the timing of these consultations overlapped the Diplomatic Conference to revise the EPC. This is probably the primary reason why the amendment to Article 52(2) EPC was dropped from the Basic Proposal, since it was felt that it was premature to act pending the results of the consultations.
In fact it is debatable whether the consultation process threw up anything that was not readily predictable. There was broad support for software patents from industry, particularly from larger companies. The position of smaller firms was less clear, but this can easily be attributed to the confusion surrounding the debate. Typically such firms are uneasy at the (supposed) prospect of introducing software patents, but quite happy to continue with existing practice. In contrast to industry, software patents were strongly opposed by the Open Source movement. Perhaps the most useful conclusion to come out of the consultation was that no one in Europe was particularly supportive of the patentability of (non-technical) business methods. In other words, there was little or no pressure to move Europe in the same direction that the State Street Bank decision had taken the United States.
In the same time frame an important case went through the EPO, namely Pension Benefits, concerning an invention related to running a pension scheme using a computer. Although the method claims were rejected by the Board of Appeal as falling within the exclusion of Article 52(2)(c) EPC, the analogous apparatus claims for a system for implementing the business method were regarded as acceptable under Article 52(2) EPC, as being directed to a physical machine (i.e. a computer). However the apparatus claims were then rejected on the basis that the only advance was in an excluded area, in other words in a non-technical area, and so (apparently) could not contribute to inventive step. Accordingly, these claims were then rejected under Article 56 EPC as lacking an inventive step.
In February of this year, and after much internal wrangling (so it is believed), the Commission finally put forward the draft Directive. The Directive itself is rather short but is accompanied by a substantial amount of explanatory material. There were no great surprises in the proposals, which generally conformed to current EPO practice in terms of the treatment of software inventions. This included the adoption of the rationale of the Pensions Benefits decision as the basis for the treatment of (non-technical) business method inventions - these were to stay unpatentable (in line with the results of the consultation process). Perhaps the most worrying thing in the draft Directive from a user's perspective was the potential prohibition of computer program claims. Such claims provide a sensible and straightforward way to enforce patents for computer-implemented inventions, whereas their absence detracts from legal certainty. The adoption in the draft Directive of the rationale of the Pension Benefits case to reject system claims for business method inventions is also controversial, but beyond the scope of this paper .
2. Comments on 'Much Pain for Little Gain? A Critical View of Software Patents' by Christian Koboldt
This paper attempts an economic analysis of software patentability. Although the general approach seems sensible and reasonable, I think that there is confusion at both the beginning and the end of the paper, which rather undermines its conclusions.
Thus the author initially complains that the Commissions proposals are 'a whimper rather than a bang', despite the Commission 'having identified a considerable need for action'. However, there is no indication of what form of 'bang' the author was expecting. Certainly, the Commission has never suggested that the planned Directive would take drastic action, and the proposals to confirm existing EPO practice were widely predictable, in view of the background discussed above. Indeed, the Commission generally had little choice in this regard, given the lack of compelling evidence to depart from existing practice, and to adopt a more liberal or more restrictive approach to software patentability.
Mr Koboldt then provides a general discussion of Intellectual Property Rights (IPRs) from an economic perspective. It has long been understood that these cut both ways. Thus if we go back to the inception of the patent system in Britain, namely the Statute of Monopolies of 1623, it will be appreciated that the general purpose of this Statute was to prohibit monopolies, since these were seen as detrimental to economic well-being. Nevertheless, a special exception was made in respect of granting a limited monopoly (i.e. a patent) to an inventor, on the basis that the disadvantage of such a restriction on third parties was outweighed by the benefit to society of encouraging innovation.
Mr Koboldt raises an interesting point regarding the application of existing IPRs, such as the patent system, to new technologies, for example, computer software. At a broad level we can identify two possible approaches to new technology:
(a) create an original, sui generis, right particularly directed to the new form of technology; or
(b) accommodate the new technology within existing IPRs.
I am tempted to say that the former approach is beloved of certain academics, who try to formulate IP schemes almost as an intellectual exercise. However, in practice there is no doubt that industry prefers the latter option. Thus it is generally far simpler to have a common approach across different technologies, since by utilising existing, well-understood IPR systems, a much high degree of legal certainty can be obtained (which is of paramount concern for industry). Naturally, this can sometimes lead to tensions within the patent system, as different technologies pull in different directions, but there is no sign yet of any major rifts appearing. The alternative, of creating a plethora of different IP rights for different technologies, is deeply unattractive. In the present instance, Mr Koboldt talks about trying to shoehorn computer software into the patent system. However, having worked with both computer hardware and computer software technology, my practical experience is very strongly that the patent system is just as appropriate and useful to the latter as to the former.
Mr Koboldt then goes on to discuss network effects in the software industry. It is important here to properly differentiate between the following two situations:
(i) the innovator obtains marketplace dominance simply by being the first entrant into the marketplace;
(ii) the innovator is unable to resist competition from an established company that is able to exploit existing marketplace dominance.
It is a frequent contention that Microsoft Corporation, because of its dominance of the client platform, is now able to stifle innovation in this market sector. However, the patent system may in fact provide the ideal mechanism to encourage and reward the innovator in this situation, by providing them with a legal defence for their invention. Thus a patent can then be utilised to resist the marketplace control of a dominant player, and so ensure a fair commercial return for the innovator.
Under the heading, 'Is there a case for software patents ?', Mr Koboldt then postulates two main justifications for such patents:
(a) they provide a more effective form of protection than other IPRs (at least in some circumstances), and/or
(b) patent protection encourages more disclosure of technology than trade secret protection, and this in turn stimulates further innovation.
I think that most people would accept that these are indeed two of the main benefits of the patent system. However, as Mr Koboldt recognises, factor (b) by itself is insufficient, since unless it is attractive for a developer to patent his or her advance (i.e. unless factor (a) applies), such information will never be published to encourage innovation by others. In other words, the patent system is only useful where factor (a) holds.
Unfortunately, it is in the assessment of factor (a) that I feel Mr Koboldt goes somewhat astray. He acknowledges that 'seeking patent protection would appear to be attractive for those ideas where disclosure does not ultimately matter because they are obvious for all to see'. However, obvious in this context (i.e. not hidden within the product) does not equate to obviousness in the patent sense (i.e. whether or not a new idea is inventive).
Another area of confusion concerns interfaces. Mr Koboldt writes that 'ideas, principles and algorithms that are not obvious might still be better protected as trade secrets, in particular, if an effective regime for the compulsory licensing of interface information for patented innovations were in place'. I'm not aware that any such 'regime' is being considered, so the relevance of this observation is rather unclear.
The final conclusion of Mr Koboldt seems to be that patents are not an attractive option to developers, yet at the same time there could be a lot of them about, which would then act as a hindrance to further innovation ('much pain for little gain'). I'm not sure that this is a logically consistent position (why would they proliferate if they were not attractive?).
Crucially however, Mr Koboldt does not acknowledge that there are already thousands of granted software patents. Thus the simple and unavoidable truth is that for many developers, patent protection is indeed more attractive than a combination of copyright and trade secrets (in other words factor (a) applies). Moreover, these patents are not limited just to user interface inventions, or other areas where trade secret protection is not viable (although this clearly is one consideration in opting for patent protection). Rather, such patents embrace the whole range of computer technology.
There are a variety of reasons behind the attraction of patent protection. For example, it is unwise to place too much reliance on trade secret protection in an industry notorious for high staff turnover. In addition, technology licensing is very common in the computer industry, and patents provide a very efficient vehicle for enabling such licensing. (The presence of a patent reassures the licensor that its technology will not be stolen, and the licensee that it is obtaining something of genuine value).
In summary therefore, software patents are already woven into the fabric of the computer industry, and the proposed Directive does little more than confirm existing practice. This must surely be the sensible course, absent significant and compelling evidence to the contrary, and certainly there is nothing in Mr Koboldt's paper that could lead to a different conclusion.
3. Comments on 'Software Development, Intellectual Property, and IT Security', by Robert Gehring
In this paper, Mr Gehring argues that security and (to a lesser extent) reliability weaknesses in existing programs can only be successfully countered via an Open Source approach. The patenting of software inventions then enters from two directions. It is argued firstly that the availability of software patents contributes directly to the initial existence of security problems. Secondly, such patents are a barrier to Open Source, and hence may prevent a solution of these security problems.
Mr Gehring starts by presenting a rather alarming portrait of the software industry - bugs and security holes everywhere. My initial rather cynical reaction to this is that if programmers have made such a mess of their own business, the last thing we want to do is to let them tell us how to run the patent system.
More seriously, in focussing on the issue of security, Mr Gehring has certainly (and no doubt deliberately) selected an issue of very significant concern. However, having adopted this as a problem to be solved, my impression is that Mr Gehring proceeds to advocate what appears to be a preordained solution (Open Source). Unfortunately, I remain sceptical that the desired nexus really exists. In other words, is there really good evidence that Open Source code will provide a cure for current security problems?
There are many reasons for taking this position. Firstly, Mr Gehring is perhaps rather selective in his discussion of conventional software development technology, since security concerns do in fact already receive considerable attention. For example, a security model is integrated into the heart of the Java platform from Sun Microsystems, Inc., which represents probably the most important and pervasive advance in software technology in the last decade. In addition, program vendors frequently advertise the security features of their products, and moreover, some independent certification procedures exist. - Accordingly, users are already able to make an informed judgement regarding the security capabilities of various solutions available in the marketplace.
I am not aware of any strong empirical evidence that the Open Source development process is able to consistently develop more secure software than conventional processes. If you scan the Web you will find some Open Source code of the highest professional quality, but equally there is code that was probably put together by students after a long night drinking beer. Ultimately, the quality of code depends on its authors, and this is true irrespective of the development process.
Mr Gehring's paper does not contain anything to convince me to the contrary. Rather, the paper adopts what is perhaps an idealistic argument that Open Source code will have improved security due to the review and feedback of a multitude of users. However, the vast majority of commercial users have more urgent things to do with their business and/or lives than pore over the inner details of third party code. Instead, most people simply want code that provides the desired functionality out-of-the box. Ideally, if something does break down, they want to know that the supplier has a contractual obligation to fix it (not that they have to hack into it themselves).
This brings us to the heart of the problem, in that the two most important factors that compromise security are:
(i) the laxity of users in applying security updates, even where freely available, to their current systems, this being compounded by the fact that a network is only as secure as its most vulnerable component, and
(ii) a widespread homogeneity of software platforms (e.g. the pervasiveness of Microsoft products on the desktop), so that a single virus or other form of attack can disable a very high proportion of systems.
It is immediately apparent that Open Source cannot help address the first factor. Regarding the second, unfortunately Open Source programs are subject to the same homogenising pressures as conventional programs. If you have an Open Source operating system on your desktop, it is almost certainly Linux, while if you run an Open Source Web server it is almost certainly Apache. Of course, in theory the Open Source licensing does permit greater diversity, with each user customising their own system. However, bearing in mind the evidence from the first factor, namely that most users are too busy/unconcerned to apply even simple, readily available security patches, the prospect of them modifying their own source code for this purpose is exceedingly slim.
I should emphasise at this point that I do accept that Open Source code has important advantages from a customer perspective. For example, it provides some very high quality code, available at low or zero cost. In addition, major industry players back it. At the same time the customer avoids the risk of becoming locked into a single supplier. Unfortunately however, I just don't see improved security as one of its major selling points.
If Open Source code cannot resolve current security problems, then Mr Gehring's arguments against patent rights, as listed above, become largely redundant. Nevertheless, I would still like to review these arguments, since they do bring out some useful issues.
Thus Mr Gehring identifies two main problems with patent rights from a security perspective, in particular:
(a) secure technology itself may be patented, thereby limiting its use; and
(b) binary distribution will be preferred, preventing proper understanding of security issues.
It should be realised that the first of these is simply part of the time-honoured balance of the patent process. In other words, third party rights are restricted (for a limited period) in order to improve innovation and progress for the overall benefit of society. Unfortunately, Mr Gehring does not seem to acknowledge the existence of this balance. Moreover, absent evidence to the contrary (and Mr Gehring does not provide any), the only logical assumption is that this balance falls the same way for security invention as for the rest of technology, in other words in favour of the patent system.
As regards the second point, this is split up into two factors: (i) trade secret protection is sustained, and (ii) the possibility of infringing third party rights makes it better to distribute in binary form. I do not understand the first of these, because the patent system in fact operates in exactly the opposite way to that suggested by Mr Gehring. In other words, as recognised by Mr Koboldt, patents are generally regarded as an alternative to trade secrets, and indeed it is a prerequisite of obtaining patent protection that the invention is publicly disclosed and described. Certainly therefore the patent system does nothing to encourage the use of trade secret protection, but rather would tend to reduce reliance upon it. A very large amount of technical information is published through the patent system.
Regarding the second factor, I accept that this could, in principle, motivate in favour of binary code. However, its influence is surely very weak, since distribution of binary code has been established as standard industry practice for very many years, and certainly pre-dates the widespread availability of software patents.
Turning now to section 6.2 of the paper, Mr Gehring talks more generally here about 'the patent threat'. I'm afraid that this section repeats many common misconceptions about the current patent environment, such as that there has been 'uninhibited patenting of nearly every trivial idea'. Thus quite apart from the standard tests of novelty and inventive step, patents are expensive, and this financial perspective is a powerful deterrent against over-patenting.
If we take a more general viewpoint for a general software developer, there is typically a choice between:
(i) in-house code development, which requires time and investment, but retains full IP rights; and
(ii) use of existing Open Source code (possibly with some modification). Here the investment is greatly reduced, and probably also time to market, but no IP is available (sometimes not even for the modifications).
It is not generally possible to run a development business on the basis of option (ii) alone (i.e. the Open Source process), since the lack of IP rights prevents the creation of a revenue stream. Nevertheless, this can still be attractive in some circumstances, for example where the Open Source code may assist the sale of another product (for example, it allows the other product to interoperate with a new platform).
The key point is that industry wants both options to be available. Thus it does not want to be forced to always go down the second (Open Source) option, by undermining IP rights for software. On the other hand, it does not want IP rights to stifle Open Source development and creativity. It is clear therefore that a balance is required - and it also seems clear that the current balance is about correct. Thus the rather alarmist predictions from the Open Source community about the dangers of software patent rights are becoming increasingly untenable. Rather, it will be apparent to the impartial observer that, in practice, software patents and Open Source code are actually co-existing rather well.
Considering now the Conclusions and Recommendations of Mr Gehring, I find myself surprisingly untroubled by these (despite having disputed much of the rest of his paper). Thus the creation of a source code privilege, dependent upon the code in question being (i) in source form, rather than directly executable, and (ii) available free, with the right to distribute further, may indeed be workable. Such a source code privilege might then provide reassurance to Open Source developers, without undermining the commercial utilisation and exploitation of conventional IP rights. In summary therefore, although I disagree with how Mr Gehring arrived at the concept of a source code privilege, nevertheless I think that the idea is potentially meritorious, and certainly merits further consideration.
Notes and References
1. T208/84
2. The claims are the portion of the patent that formally defines the monopoly that is being granted in respect of the invention.
3. According to the Explanatory Memorandum accompanying the proposed Directive, the EPO has granted over 20,000 patents for computer-implemented inventions in Europe, and additional such patents will have been granted by the various national Patent offices.
4. T935/97 and T1173/97.
5. COM(1997) 314 final, 24 June 1997.
6. COM(1999) 42 final, 5 February 1999.
7. Available from: <http://www.european-patent-office.org/epo/dipl_conf/documents.htm>.
8. See the statement by Dr Roland Grossenbacher, Chairman of the Administrative Council of the EPO, available from: <http://www.european-patent-office.org/epo/dipl_conf/documents.htm>.
9. The Open Source anti-patent lobby is led by the Eurolinux movement, whose home page, www.eurolinux.org, opens with the following: 'Currently a powerful network of patent lawyers is pushing the European Commission to follow the USA in legalising the patenting of computer-implementable rules of organisation and calculation (programs for computers). Instead of current copyright protection, legal security and easy market access, we expect an unproductive regime of monopolistic concentration and informatic censorship to gradually unfold, leading to less R&D investment and a huge blood transfer from the European software industry to the patent litigation business'. This ignores the fact that the patenting of software inventions is already legal in Europe, and has been going on for many years without the dire consequences prophesied.
10. 927 F. Supp. 502.
11. Business methods are another excluded category within Article 52(2), see above.
12. Details of the consultation by the Commission, including an analysis of the responses (and the various responses themselves) are available at: <http://europa.eu.int/comm/internal_market/en/indprop/comp/index.htm>.
The consultation process from the UK Patent Office is described at: <http://www.patent.gov.uk/about/ippd/consultation/closed/index.htm>, with the Government's conclusions at: <http://www.patent.gov.uk/about/consultations/conclusions.htm>.
13. T931/95.
14. The draft Directive and accompanying materials are available at: <http://europa.eu.int/comm/internal_market/en/indprop/comp/index.htm>.
15. Article 5 of the draft Directive indicates that system and method claims are to be allowable for computer-implemented inventions. According to the comments in the Explanatory Memorandum, the intention for Article 5 is that it does not permit computer program claims. However, the actual wording of Article 5 seems to be indeterminate on this point.
16. This aspect of Pension Benefits contradicts the treatment of such claims in the UK, as stemming from the decision of the Court of Appeal in Merrill Lynch ([1989] RPC 561). Note that the UK Patent Office has continued to follow Merrill Lynch, see for example Pintos Global Services Ltd's Application (SRIS O/171/01). However, this practice would have to change if the Directive goes through (as currently worded).
17. Note also that the Commission has no power to amend the EPC itself.
18. 21 Jac. 2, c. 3. This statute applied to all patents granted in the UK until the introduction of the 1977 Patent Act.
19. See for example, 'U.S. v. Microsoft: The Inside Story of the Landmark Case' by Joel Brinkley and Steve Lohr, 2000, McGraw-Hill, ISBN 0-07-135588-X.
20. On the other hand, assuming that factor (a) does apply, then it is legitimate to also consider factor (b) in the overall assessment of whether the patent system as a whole is beneficial to society.
21. Article 6 of the planned Directive indicates that patent protection shall not prevent the exercise of rights provided in the previous software directive, Directive 91/250, which included interoperability provisions. However, such rights exist irrespective of whether patent protection is obtained, and so can hardly represent an incentive to rely on trade secret protection as opposed to patents.
22. See <http://developer.java.sun.com/developer/technicalArticles/Security/> for a listing of some articles on Java security.
23. See for example the focus that Oracle gives to security aspects, as indicated by: <http://www.oracle.com/features/9i/index.html?t1db_sec.html>, or their advertising on the back cover of Scientific American, such as for the April 2002 issue.
24. See for example the US Department of Defense Trusted Computer System Evaluation Criteria (DOD 5200.28-STD).
25. As an example, Linux was attacked by the 1i0n worm through its use of raw sockets, see 'Code Red for the Web' by Carolyn Meinel, p36-43, Scientific American, October 2001.
26. Supporters include IBM, Sun Microsystems, and Hewlett-Packard, see for example the report on the 2002. Linuxworld Expo available at: <http://news.bbc.co.uk/1/hi/technology/2190602.stm>.
27. Mr Gehring makes a vague reference to RSA encryption technology at this point. Although I don't know the details of the invention of public key technology by Rivest, Shamir, and Adelman, my impression has always been that this is a very positive example of the patent system in operation. The invention was certainly a fundamental breakthrough, and has been widely licensed. For example, it now underpins many parts of the banking system and also secure Internet transactions. The basic patent (US 4405829) expired in September 2000.
28. Some clarification is needed here to maintain consistency. Accepting that the general public disclosure of technical information is beneficial does not necessarily imply that a particular software development process (Open Source) is necessarily better than another development process.
29. This sort of sentiment is widespread (it is also apparent in the paper by Mr Koboldt), but no-one provides the evidence to substantiate it. For example, in the article 'Stolen Code' by Wendy Grossman (p36-39, New Scientist, 28 September 2002), the author proposes that the grant of bad patents is one of the major arguments against software patents. However, she then fails to identify a single one of the many thousands of European software patents that might fall into this category. (Not even I would accuse the EPO of being this accurate).
30. People frequently over-estimate the rate of patenting. Consider for example IBM, which in the year 2000 was granted 2886 US patents (more than any other company). In this same year it had 316,000 employees and spent $5.2 billion on R+D (figures from IBM 2000 Annual Report). This corresponds to 1 patent per 110 employees or $1.8 million R+D spend, hardly the patenting of every trivial idea. (The quoted ratios are only broadly indicative, since they include hardware and services technology as well as software, and are also affected by the pendency of patent applications).
31. Open Source pioneer Richard Stallman advocates that its supporters find consultancy work (see <http://www.gnu.org/gnu/thegnuproject.html>). A cynical view (not one I subscribe to) of the Open Source movement would therefore see it is a crude attempt to wrest economic power away from successful program developers, towards those whose efforts have found less favour in the marketplace.
32. The interplay with aspects like contributory infringement and the requirements of Article 27 TRIPS would need to be carefully considered.
|
