According to my thesis, the European Software Directive poses some obstacles to open source or other distributed decompilation projects. Also the favor of US courts for clean-room reverse engineering is mainly problematic for open source decompilation projects. However, one could argue, I did not demonstrate that these obstacles are major and make software reverse engineering impossible. Moreover, I did not show that they are a major concern for commercial software houses. Even though I tried to demonstrate that these obstacles are not coherent with the general philosophy of intellectual property protection of software, and I also tried to show that eliminating them would not have major negative effect on incentives to innovate, one could still legitimately ask himself, “should I really care about these details about intellectual property in a very specific field?”. I argue that we should care, and quite a lot, about these obstacles to the obtainment of horizontal interoperability by free software and/or open source (FLOSS) projects, because they are probably the only, and surely the most credible, threats to established commercial incumbent in the field of operating systems and similar software platforms.
In software markets, there are only a few undertakings that may have an incentive to realize a substitute for a very successful and established product, unless they are able to provide an extremely improved piece of software (something that is unlikely, in a field characterized by incremental innovation). An exception (as I will discuss in the third paper) are software platforms wanting to mitigate the market power of some producers of complements (or simply wanting to leverage their power in adjacent markets) and having the possibility of leveraging market power to generate network effects through bundling. However, holding some market power is a prerequisite of this strategy. Thus, and even though one may hope that dominant incumbents in different markets will try to threat dominant firms in other markets, a scenario in which Google bets its financial resources to start a war against Microsoft in the field of PC operating systems does not seem particularly likely to me. Especially because the most likely effect of this kind of strategy would be a lowering of the profits of both Google and Microsoft. A tacitly collusive equilibrium, in which market leaders keep and safeguard their own quasi-monopolies appears to be more likely, and it is in doing so that bundling strategies are especially “helpful” (as I will show in the next paper). Luckily for competition (and, I submit, for consumers), another potential exception are FLOSS developers, because they are among the few that may want to pursue a “me too” competition, even in cases in which the chances of the projectbeing successful are low (or maybe precisely because of that, in order to receive reputational recognition). In fact, open source developers do not need to break even on costs from the financial/accounting point of view. They may be perfectly happy with a project not making any money, but representing a viable alternative to an existing dominant product (even if, maybe, just for a limited share of quite sophisticated users liking to install their own software and having a special awareness of existing alternative to the most widespread products). Indeed, there is a high likelihood that a functional clone of an existing product will never run a significant profit and a similarly high likelihood that horizontal interoperability will never be perfect (so that significant indirect network effects will always protect products like Windows). Hence, the effect of successful open source projects may just be that their developers improve their reputation (and, maybe, get hired by some commercial software house, possibly even Microsoft), while – at the same time – dominant players will remain dominant, but will have some more difficulties in exercising their market power. But such an outcome may be quite positive, from the point of view of social welfare.
The relevance of open source as a competitive threat to dominant player in several software markets that were almost completely uncontested until some years ago did not escape the attention of other commercial software houses. So Sun Microsystems joined with the open source community to develop a real competitor of Microsoft Office: Open Office, which was based of the “opened” source code of Sun’s project Star Office, which – as a commercial product – looked highly unlikely to represent a competitive threat for Microsoft. Similarly, several commercial software house, like Google281 (but also IBM or Intel), help the open source
community in various ways, and surely in their own interest. Indeed, FLOSS seems to be increasingly
280 A point deserving a comment is the fact that the French legislator – despite its attention to the theme of interoperability –
excluded software from the “contents” to which the interoperability provisions of the Loi DADVSI apply. Apparently, that has been done because the French legislator considered that the issue of software interoperability was already regulated by the Software Directive (and its French implementation).
perceived as a powerful tool to compete against dominant incumbent in markets characterized by very high network effects282. And this perception seems to be shared also by the software house that is considered –
and probably considers itself – the very nemesis of the FLOSS software movement, Microsoft, the CEO of which asserted that:
We’ve been competing against free alternatives for years; Star Office to Open Office, da-deet, da-deet, da- deet. I’m not saying it’s not a real competition. Maybe the world has exactly what it wants. It has us moving fast and hard, keeping our prices down. And even if the other guy doesn’t get any traction or momentum, the other guy has no cost structure. So they are not going away either. Maybe that is what the world wants. Put the courts aside, we have a lot of competition. We have to outrun this phenomenon. And I think we’re doing a good job of it. But if we let up for a minute, I think there are issues. You would say to me, if we stop, if we’re no longer more functional, if we’re no longer a time saver, if we’re no longer compatible, then that other stuff will gain traction.283
Hence, open source does represent a competitive threat for commercial software houses, and in particular for the dominant ones, which no other traditional commercial developer would likely threaten, simply because an years-long “competitive siege” would be needed, and commercial software houses, ad Steve Ballmer puts it do have a “cost structure” and frequently binding financial constraints.
Another recent hint at the relevance of the open source threat for Microsoft – if needed – are the significant efforts of the software house in order to have its MS-OOXML format for office suites documents approved as an ISO standard, after that the open source supported ODF format received the same approval and was hence officially supported by several national and international institutions.284 In an official document
addressed to the US Security and Exchange Commission, Microsoft recently confirmed – in a less colorful way – the concepts expressed by its CEP, starting its description of the main risk factor it faces with the following words:
Challenges to our business model may reduce our revenues and operating margins. Our business model has been based upon customers paying a fee to license software that we develop and distribute. Under this license-based software model, software developers bear the costs of converting original ideas into software products through investments in research and development, offsetting these costs with the revenue received from the distribution of their products. Certain ‘open source’ software business models challenge our license-based software model. […] A number of commercial firms compete with us using an open source business model by modifying and then distributing open source software to end users at nominal cost and earning revenue on complementary services and products. These firms do not bear the full costs of research and development for the software. Some of these firms may build upon Microsoft ideas that we provide to them free or at low royalties in connection with our interoperability initiatives. To the extent open source software gains increasing market acceptance, our sales, revenue and operating margins may decline.285 […]
Open source software vendors are devoting considerable efforts to developing software that mimics the features and functionality of our products, in some cases on the basis of technical specifications for Microsoft technologies that we make available. In response to competition, we are developing versions of our products with basic functionality that are sold at lower prices than the standard versions. These competitive pressures may result in decreased sales volumes, price reductions, and/or increased operating costs, such as for marketing and sales incentives, resulting in lower revenue, gross margins and operating income.286
The aforementioned quotation comes from the heading of the section “Risk Factors” in Microsoft’s report to SEC. Hence it is reasonable to suggest that Microsoft – the most powerful incumbent in the consumer
282 Both direct and indirect, but the latter case seems to be the more relevant (OpenOffice – Linux). An interesting example is
provided by Nokia, which recently bought the smart-phone operating system Symbian (see, among many, Nokia to Open Access to
Mobile Software, by Kevin O’Brien, June 25, 2008 http://www.nytimes.com/2008/06/25/technology/25nokia.html), precisely in order to open it and compete against Microsoft and possibly Apple, which is adopting an opposite and very “close” strategy… See
also EVANS, et al., Invisible Engines.
283 Steve Ballmer interviewed by Forbes.com. Daniel Lyons, Ballmer, Bemused, Forbes.com – Computer Hardware & Software,
March 23, 2006, available at http://www.forbes.com/2006/03/22/ballmer-microsoft-linux-cz_df_0322microsoft.html (last visited July 21, 2008).
284 See http://en.wikipedia.org/wiki/Office_Open_XML.
285 Microsoft Corporation, Annual Report to SEC on Form 10-K, Commission file number 0-14278 (hereinafter, Microsoft
Report to SEC), page 12, heading of Item 1A. Risk Factors. (Available at http://www.sec.gov/Archives/edgar/data/789019/000119312508162768/d10k.htm; last visited August 4, 2008.)
software industry, arguably extending its market power to low-end servers287 – considers that the open source
model of software development, in combination with the investments of potential or actual commercial competitors, is the most credible threat to its quasi-monopolistic competition in several markets (in particular, one may think about personal computer operating systems and office suites). Moreover, Microsoft argues that – even in the absence of an appreciable decrease in its market shares – this competitive threat prevents the software house from fully exploiting profit opportunities in these markets and forces the firm to make available low cost versions of its products. Obviously Microsoft also suggests that this competition may decrease incentives to innovate and not only Microsoft’s profits. However, no evidence to support this possibility is provided and the self-interest of Microsoft in arguing in this sense is plainly evident. In fact, nothing in the report suggest that Microsoft is not able to recoup its research costs or that research and development investments had to be reduced, despite various statements suggesting that this may be the case (which are normal in a report that is supposed to show possible risks for stake holders). Actually, in the trend of Microsoft’s investments, one can find no evidence that investments in R&D are severely adversely affected by competition:
During fiscal years 2008, 2007, and 2006, research and development expense was $8.2 billion, $7.1 billion, and $6.6 billion, respectively. These amounts represented 14%, 14%, and 15%, respectively, of revenue in each of those years. We plan to continue to make significant investments in a broad range of research and product development efforts.288
8. Conclusions
The detailed limits and conditions necessary to enjoy the decompilation exception of article 6 of the Software Directive; the favor of US courts for clean-room reverse engineering and their caution in applying the fair use test the decompilation cases; the purpose-bound decompilation exception of the DMCA; all these legal norms share a significant level of prudence, in order to prevent possible future risks. However, as Spoor puts it, “the reverse engineering provisions in the Directive [as, I would add, all the aforementioned norms] can probably be characterized as a rare instance of ‘legislation ahead of its time’.”289 The problem is that “[i]t
must be doubted whether that time will ever come.”290 Legislating in this way in the high-tech software
industry is not wise: being prudent could simply mean being irresponsible, if this prudence goes in the direction of limiting one of the few tools that could be used to (try to) compete with powerful dominant incumbents, reinforcing their dominant positions. Notice that I am not simply forgetting the fact that reverse engineering could be used also “against” other – non-dominant – competitors. Indeed, decompilation is so costly and time consuming that it could be reasonably used only when issues at stake are huge, when the competition is for the control of a market, where an established incumbent looks unchallengeable. When competitors are on a substantially plain competitive field, then it is cheaper for each of them to develop software from scratch, instead of starting from the decompilation of their opponent’s programs. Technologists confirm that “[i]t is probably easier and almost certainly much more attractive for competitors to develop completely new software, rather than to reverse engineer existing code.”291 Hence, it is only when
something else is at stake that decompilation is normally performed. And this “something else” is typically represented by the possibility of accessing the “rent” represented by very significant indirect and direct network effects, created by the existence of third parties’ compatible applications and user created data (the value of which grows with the market share of the incumbent software house, and the existence of which increases the incumbent’s market power).
When the Software Directive was adopted, several commentators292 pretended that the European legislators
were being too bold in favoring interoperability. Actually, article 6 of the Software Directive was needed, in civil law countries, to reach the same results that – in the US – was possible to reach through jurisprudential
287 See Microsoft IV Decision (supra note 228). 288 Microsoft Report to SEC, p.8
289 Ibidem. 290 Ibidem.
291 See JOHNSON-LAIRD, Software Reverse Engineering, , but see also SPOOR, Copyright Protection and Reverse Engineering, p. 1078. 292 See, in particular, the debate hosted by the European Intellectual Property Review in 1989-1991. CORNISH, Inter-operable Systems, and WILLIAM T.LAKE, Seeking Compatibility or Avoiding Development Costs? A Reply on Software Copyright in the EC, 11 European
Intellectual Property Review, 431--434 (1989), but also CAROLINE MEYER & MICHEL COLOMBE, Seeking Interoperability: An Industry
Response, 12 European Intellectual Property Review, 79--83 (1990); CAROLINE MEYER & MICHEL COLOMBE, Interoperability still
Threatened by EC Software Directive: A Status Report, 12 European Intellectual Property Review, 325--329 (1990); ROBERT J.HART,
interpretation (and this need was present also in the UK, where the fair dealing exceptions are far from being as flexible as US fair use). However, the Directive implemented the narrowest possible decompilation exception. And did that myopically thinking only of the two interest groups, which were facing each other in Brussels at the time, both consisting of commercial software houses, even if of different dimensions. It is just because of the civil law nature of the majority of European legal systems that, in Europe, support for reverse engineering and interoperability is more explicit than in the US. European legal systems just needed a higher level of codification, but these activities are likely not much easier or safer in Europe than in the US. Quite to the contrary, several kinds of decompilation projects may arguably be performed under the fair use doctrine, but not under article 6 of the Software Directive. Maybe, the degree of legal uncertainty concerning reverse engineering to achieve interoperability is slightly lower in Europe than in the US, but in both countries commercial software house have nothing to fear, as long as they do not infringe copyright re-implementing discovered interfaces.
What is more important, on both sides of the Atlantic, open source developers – likely the only (or, at least, the most) credible competitive threat to established incumbents in several software markets, and in particular in that of operating systems – face particular difficulties. These obstacles arise from the fact that reverse engineering and interoperability exceptions have been established in the narrowest possible way, obviously thinking about traditional commercial software houses. The reason for these “exceptions” being so narrow is that US Courts were careful in not setting excessively wide precedents (and – after all – they were just facing cases concerning traditional software houses). Similarly, the European legislators (when drafting the Directive) were faced by the lobbying of big US commercial software houses confronted by the lobbying of smaller (but still traditional) European software houses. Indeed, a balance was struck between the positions of these undertakings, but likely did not take into consideration enough theoretical and technical reasoning, that was already present and quite clear in the literature,293 but not yet represented by a significant opinion
movement.
As this paper showed, software reverse engineering is completely free only in the form of black box analysis,294 the results of which may be freely disclosed.295 It also showed that decompilation in order to
obtain interoperability is allowed both in the EU and in the US, but it argued that several specific qualifications with respect to the freedom to decompile are not strictly necessary and – what is more worrying – may have some especially harmful unintended consequences, in particular hindering open source decompilation projects. Furthermore, it showed that a clear-cut safe harbor would likely not create major costs in terms of reduced incentives to innovate and would go in the direction of making feasible big reverse engineering projects performed in a decentralized way, as in the context of an open source community.
Among the reasons in favor of a generic safe harbor there are: technical reasons (in many cases, you don’t really know what you are decompiling, until you actually start to analyze a software, typically making intermediate copies and derivative works, and hence potentially violating copyright); difficulties of monitoring and enforcement (in a traditional firm, a decompilation project may be kept secret, especially if the goal is not to realize an interoperable software program, but just to learn other kinds of information); actual violations of copyright – apart from the literal violation concerning intermediate copies for “studying purposes” during decompilation – arise during the reimplementation phase (and since evidence for “illegal” decompilation should frequently be looked for in code that is actually released, there are even less advantages in discussing the legality of decompilation in itself).
In the EU, purpose-bound decompilation (i.e. decompilation allowed only to attain interoperability) prohibits some kinds of interoperability for legitimate purposes (e.g. for error detection, to investigate suspect copyright violations) and – more generally – impedes an economically healthy means to discover unprotected ideas, resulting in an unprecedented reinforcement of trade secret. Fortunately, since interoperability remains the main goal of economically relevant decompilation projects, article 6 of the Software Directive seemed to allow firms to perform the crucial form of decompilation; in fact, the second paper also showed that –
293 See CORNISH, Inter-operable Systems.
294 See GUGLIELMETTI, L'invenzione di software (2nd ed.), p. 256 (fn 116), where the author argues that “black box analysis” is