6. Drawing some preliminary conclusions
6.4. Legislative developments taking into account some of the arguments of this paper
As already hinted when discussing the basic economic model of decompilation, there are several analogies between software and semiconductors. From the technical point of view, there is a significant degree of equivalence between these two tools.253 Also from the economic point of view, both fields are characterized
by similar paths of incremental innovation, economies of scaled and network effects. In fact, also the legal protection of innovations in the field of software and of semiconductors is similar. In fact – despite the fact that semiconductors are governed by an ad hoc regime – this legal tool is largely inspired by copyright. The legal protection of software and semiconductors differs, in particular, in the rules governing reverse engineering. In fact, not only is reverse engineering always allowed, but competitors supporting both the cost of reverse engineering and the cost of developing an improved product receive the possibility of reproducing also the topographies and mask works (i.e. the external form/expression) of the preexisting analyzed semiconductors. (For more details, I remand to Samuelson and Scotchmer254 and/or Guglielmetti255). Such a
legal provision makes perfect sense if reverse engineering is costly, incremental innovation is crucial, dominant positions absent or shaky and it legislators want to promote a vibrant competitive market. In fact, as shown by the reasoning about the reverse engineering of software, it is far from sure that decompilation or similar activities lead to market failure (even if, in fact, it could be argued that software reverse engineering is even more difficult than semiconductors reverse engineering and if one should remember that – in the field of software – I always assumed that copyright would, in any case, prevent the literal copying of existing expression, unless technically strictly necessary).
To conclude this brief parenthesis about semiconductors, it must be noted that, according to some commentators, the different legal rules governing software and these products have not been generated by different economic principles governing innovation in these fields. On the contrary, these differences would have been generated by a different timing for the introduction of this legal protection and by the different industrial structures at the time of drafting (in particular in the United States, while the rest of the world followed their leadership both in terms of technological advances and dimension of the market).256 In my
opinion the main difference is not so much that there was more concentration in the software market when copyright was established as a tool to protect computer programs (likely, it was the opposite), but the fact that the “competitive fringe” had very different characteristics in the two markets. On the one hand, in the semiconductors industry, the “fringe” was formed by firms that were relatively small with respect to the market leaders, but of medium average size according to absolute measures. On the other hand, the competitive fringe in the software market was really formed by very small (if not individual) firms. Basic arguments of public choice suggest that the group formed by more individuals with more disperse interests will be the less effective in influencing the choices of legislators. And apparently this is what has happened, giving rise to legal settings in which software incumbents enjoy a much higher level of legal protection of their market power than incumbents in the field of semiconductors. Interestingly enough, today the open source movement, adding ideological (or even philosophical, according to somebody) arguments to the debate, has been able to better represent the interest of a part of this software market competitive fringe. Thus, several instances of the movement have been taken into account by law, and by European legislators in particular (and that is not likely to be completely independent from the fact that the big commercial software houses are mainly based in the US).
252 Article 54, 2, b L.I.. According to several interpretation (see GHIDINI, IP and Competition Law, ) the “economic relevance” may
concern either the profits of the wanna-be licensee and/or the society at large.
253 In principle, there is an almost complete technical equivalent among the two. See GUGLIELMETTI, Le topografie dei semiconduttori
for more comments and references.
254 SAMUELSON & SCOTCHMER, The L&E of Reverse Engineering. 255 GUGLIELMETTI, Le topografie dei semiconduttori.
6.4.1. Failure of the directive proposal on software implemented inventions
One of the first legislative developments that surely took into account the reality of the open source software model, and in a quite spectacular(ized) way, is actually a failed reform: the rejected EU Directive on the patentability of computer-implemented inventions.257 The legislative history is quite well known, for
having been intensively reported by mass media and unprecedently monitored from the Internet.258 In a few
words, the draft Directive experimented several years of debate and numerous conflicting amendments. The final proposal was rejected on 6th July 2005 by the European Parliament by an overwhelming majority (648 to
14 votes, 18 abstentions).259 Indeed, both sides of the dispute had the possibility of claiming a victory: on the
one hand, the EU did not impose on member states any rule concerning the patentability of software; on the other hand, the European Patent Office could continue to issue quasi-software-patents undisturbed. It is interesting to compare the legislative history of this Directive with the one of the decompilation exception of the Software Directive. For the latter, a compromise solution (entailing purpose-bound decompilation under the conditions discussed at length in this paper) has been preferred to either clear-cut solution (i.e. a complete safe harbour for decompilation or a complete ban on it). In the case of the patentability of software implemented inventions, the complete rejection of the draft has been preferred to any compromise solution, considered as inadequate by both sides. Unfortunately, both approaches are prone to legal uncertainty and likely deter innovation and/or competition.260 For the purpose of the paper at hand, I mention the failure of
the Directive in order to stress the new and growing relevance of the open source movement in decisions concerning innovation policy and software in particular. A relevance that was still inexistent at the time of the drafting of the Software Directive, but which is today explicitly recognized:
The common position, if approved, would have allowed patenting of computer-implemented inventions. This outcome was advocated by big software firms, which argued that patents would encourage research spending and defend European inventions from US competition. On the contrary, the directive was criticised by supporters of ‘open source’ software, mainly smaller companies, who claimed copyright already protects their inventions and were afraid that patenting would raise legal costs.261
Despite the fact of being slightly off-topic in the paper at hand, I want to briefly comment on the issue of software implemented inventions. In fact, there are sound reasons to propose some kind of patent-like protection for software, and highly sophisticated legal reasoning that could be used in order to make this protection coherent not only with the European Patent Convention262 abound, and are essentially based on
the distinction between pure software patents (making no “technical contribution”263) and computer
implemented inventions.264 However, there are also significant arguments suggesting that it would be
irresponsible to reinforce software patents and make them a main legal tool in this field of technology. Indeed, the main problem of patent protection is that it is not a very friendly tool for small (or even individual) developers, while there is some evidence suggesting that even major players find it more useful as a strategic tool in dealing with other big players and as a barrier to entry and/or legal threats in dealing with the small ones. And, differently from what happened in other technological fields (I am not sure whether without any responsibility for IP law) individual innovators still play a major role in the software field. And
257 2002/0047/COD.
258 In particular, several blogs and more traditional websites kept activists and the general public informed about the background
of the draft directive and its progresses. Some examples (and additional links) can be found here: http://ciaran.compsoc.com/software-patents.html or http://eupat.ffii.org/ (both last visited August 11, 2008).
259 Note (06/07/2005 - EP: position, 2nd reading) from the European Parliament’s “Legislative Observatory” website, available
at: http://www.europarl.europa.eu/oeil/file.jsp?id=219592 (last visited August 11, 2008).
260 About the cost of uncertainty in the patent system, see JOSHUA S.GANS, et al., The Impact Of Uncertain Intellectual Property Rights On The Market For Ideas: Evidence From Patent Grant Delays, NBER Working Paper 13234 (July, 2007).
261 Note (06/07/2005 - EP: position, 2nd reading) from the European Parliament’s “Legislative Observatory” website, available
at: http://www.europarl.europa.eu/oeil/file.jsp?id=219592 (last visited August 11, 2008).
262 See GUGLIELMETTI, L'invenzione di software (2nd ed.), p. 188 (and 166—190 in general).
263 It is quite telling that in the EPO’s brochure “Patents for software? European law and practice” (available at
http://www.epo.org/topics/issues/computer-implemented-inventions.html; last visited July 20, 2008) the terms “technical contribution” and “technical character” are mentioned several times, but never defined. Obviously, the definition of these terms is left to the EPO itself and to national courts, but this did not satisfy the European Parliament, which – during the debate and the works preceding the rejecting of the Directive – repeatedly asked for “a clearer definition of ‘technical contribution’” (see the note of the European Parliament’s Legislative Observatory mentioned in footnote 267).
264 Ibid.: “[A] computer-implemented invention is an invention whose implementation involves the use of a computer, computer
network or other programmable apparatus, the invention having one or more features which are realised wholly or partly by means of a computer program.”
favoring concentration is a move that could hardly be reversed, hence one should carefully think about damaging the high level of “diversity” existing in this field. The empirically most relevant argument against software patents is precisely the fact that software innovation is thriving even without them. Unfortunately, nobody has ever suggested a convincing way to measure the “optimal” level of software innovation; hence, it is not possible to say whether the current level – despite being high – is “high enough”. However, introducing an additional level of law-backed monopoly in a market where competition – helped by quite weak rules against pure free-riding, in the form of technology copyright – seems to work would likely be irresponsible. In absence of additional convincing evidence, Fritz Machlup’s old (but still valid) suggestion seems to go against the introduction of software patents:
If one does not know whether a system ‘as a whole’ (in contrast to certain features of it) is good or bad, the safest ‘policy conclusion’ is to ‘muddle through’ - either with it, if one has long lived with it, or without it, if one has lived without it. If we did not have a patent system, it would be irresponsible, on the basis of our present knowledge of its economic consequences, to recommend instituting one. But since we have had a patent system for a long time, it would be irresponsible, on the basis of our present knowledge, to recommend abolishing it.265
Indeed, a system where “software implemented inventions” are a normal legal tool in the field of software innovation is a completely new system. Instead, making some legal clarity about the impossibility of patenting software in Europe would likely not change any in the existing equilibria in software markets.266
As a final note, concerning interoperability, one of the Parliament amendments concerned the introduction of a new article (6a), requiring
Member States to ensure that licences are available to use a patented computer-implemented invention ‘on reasonable and non-discriminatory terms and conditions’ when such use is indispensable for achieving interoperability between computer programs and is in the public interest.267
Hence, it is reasonable to argue that interoperability was one of the crucial worries of the members of the Parliament opposed to the Directive.268 And it is similarly reasonable (even if slightly more stretched) to argue
that the impossibility of preventing interoperability eliminated much of the appeal of software patents for the coalition favoring them, so that maintaining the status quo of legal uncertainty (allowing some room for legal threats of uncertain strength) was preferred to a Directive clearly allowing patents on software implemented inventions, but also clearly mandating software interoperability under the patent system.
6.4.2. The Loi DADVSI (interoperability among DRM systems)
The failure of the Directive on the patentability of computer implemented inventions was acclaimed as a great victory by the open source community (despite the awareness that patents on software implemented inventions were – and still are – regularly granted by the European Patent Office). But the lobbying of the
265 Machlup, Fritz (1958), An Economic Review of the Patent System, Study no. 15 of the Subcommittee on Patents, Trademarks,
and Copyrights of the Committee on the Judiciary, United States Senate, 85th Congress, Second Session (Washington, D.C.: Government Printing Office).
266 That having been said, the European Patent Convention (EPC) is already quite explicit. It puts “programs for computers” in
the same category of non-patentable subject matters as “schemes, rules and methods for performing mental acts, playing games or doing business” and also “discoveries, scientific theories and mathematical methods”. In fact, it is well known that the exclusion of all these subject matters just concerns “such subject-matter or activities as such”. Hence, it is possible to patent a specific technical solution, with industrial applicability, even if it applies a “scientific theory” or a “mathematical method”, or a “computer program”. But it should be clear that the patentability of computer programs, simply used to run computers without any industrial application, is excluded by the Convention.
267 Note (COD/2002/0047 : 20/06/2005 - EP: decision of the committee responsible, 2nd reading) from the European
Parliament’s “Legislative Observatory” website, available at: http://www.europarl.europa.eu/oeil/resume.jsp?id=219592&eventId=904553&backToCaller=NO&language=en; last visited
August 11, 2008). See also RICOLFI, Antitrust Antidote, who noticed also that a broad, sector-specific interoperability exception (for
the purpose of reverse engineering and to achieve interoperability) could be used to limit the rights conferred by patent law, likely remaining compliant with Articles 27 and 30 of TRIPs.
268 As a quasi-humoristic, but quite telling note, consider that the main repository of open source projects, SourceForge.net
awarded to Wine its 2008 Community Choice Award in the category “Most Likely to Be Ambiguously and Baselessly Accused of Patent Violation”. (See http://sourceforge.net/community/cca08-finalists; last visited July 28, 2008). Other finalist projects were frequently related to interoperability and/or reimplementation of commercial technologies, including ReactOS and Mono (open source reimplementation of the .NET client and server applications under Unix-like systems).
open source movement and of small software developers had an even more proactive effect in the context of the French Loi DADVSI.269
The law “2006-961 du 1er aout 2006”270 has been discussed by the French Parliament in a moment in which
interoperability was an issue at the centre of the political debate, largely as an effect of the opinion movement created by the rejected Directive on software implemented inventions. For this reason, the main innovations introduced by that law particular concern interoperability271 between DRM systems. According to the French
law, technological measures of protection (TMPs) must not hinder ‘the effective application of interoperability’, understood as in the Software Directive:272
“Consequently, providers of technological measures must communicate the information essential for interoperability under specified conditions. Technological measures may not go further than what the law permits, namely protecting and guaranteeing an intellectual property right. The Intellectual Property Code seeks to prevent the application of controls restricting access to a work or other protected subject matter beyond the framework of intellectual rights, that is to say the regime of exclusive rights accompanied by exceptions. The law has entrusted a body called the Technological Measures Regulatory Authority with the task of ensuring that this is the case.”273
Clearly, the law tries to avoid interoperability being used as a pretext in order to circumvent DRM systems. But, at the same time, it is also aimed at preventing any use of the legal protection of TMPs to foreclose competition and interoperability, more than to safeguard intellectual property rights. Indeed, the authority established by the Loi DADVSI, has to coordinate with the Competition Council (and both authorities could refer cases to the other body or seek opinions). In any case there are differences between the scope and goals of the activity of the two bodies, since the Competition Council restrains itself to cases in which technological measures may have the effect of strengthening a dominant position (or otherwise violating competition law), while the new law has a much broader application (in a much more specialized field).
In case the information necessary to achieve interoperability (interface and file format specifications) is not disclosed by the manufacturer of the TMP, the Law also establishes a procedure for requesting the disclosure of the source code of the digital rights management system:
any software publisher, manufacturer of a technical system or owner of an internet service may, in the event of being refused access to information essential for interoperability, ask that the Authority […] [ensure] the interoperability of the systems and existing services […] and obtain from TPM rights holders the information required for [interoperability]. The Authority may compel disclosure of source code and inflict a monetary penalty that is proportional to the damage caused by non-disclosure if the DRM owner refuses to comply.274
Obviously, the source code has to be maintained confidential and the French Constitutional Council also ruled275 that companies must be granted a fair compensation if such a disclosure is required. As far as I have
been able to ascertain, no practical application of this norm take place yet.
The Loi DADVSI explicitly treats a special kind of interoperability and does not prevent the ordinary application of norms granting a decompilation exception in light of the Software Directive (in France, Article L.122-6.1). This approach has been criticized by some scholars:276
This cumulative application may lead to a reduction in the situations in which the interoperability introduced by the Law of 1 August 2006 could operate and, above all, it may lead to difficulties. Thus one
269 See SOBEL, A Bite out of Apple?.
270 The final version of the law has been significantly modified by the French Senate with respect to the original one, even more
innovative, initially approved by the National Assembly. See YVES GAUBIAC, Interopérabilité et Droit de Propriété Intellectuelle (with en.
translation: Interoperability in Intellectual Property Law), 211 Revu Internationale du Droit d’Auteur, 91--139 (2007).
271 The word interoperability is not defined in the law: the reason is likely to be the that defining such a technical concept would
have led to rapid obsolescence of the law, but also the fact that the French legislator was approving a law implementing a European Directive and the Software Directive provides a (more or less explicit) definition of interoperability. This definition has been interpreted – according to some commentators (See HART, Interoperability Information, ) in an expansive way – by the European
Commission in its Microsoft Decision (2004) and this interpretation has been fully backed by the CFI in the very recent Microsoft verdict of September (17th) 2007.
272 There is no explicit definition of the concept of “interoperability” in the Loi DADVSI, hence this concept must be interpreted
directly recurring to the Software Directive.
273 GAUBIAC, Interopérabilité et Droit de Propriété Intellectuelle.
274 Loi DADVSI, Article 14. English translation from SOBEL, A Bite out of Apple?, p. 275—276. 275 French Constitutional Council decision no. 2006-540DC, July 27 2006, J.O. 178, para. 41. 276 GAUBIAC, Interopérabilité et Droit de Propriété Intellectuelle, pp. 111-113.
such case could arise in connection with the communication of information to others, since Article L.