Source files of,,,,, and Contribute:
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

bsa-letter-analysis.en.xhtml 17KB

  1. <?xml version="1.0" encoding="UTF-8" ?>
  2. <html>
  3. <head>
  4. <meta name="keywords" content="eif,european interoperability framework,open standards,fsfe,open source,commission,europe,standards" />
  5. <meta name="description" content="The Business Software Alliance (BSA) is pressuring the European Commission to remove the last vestiges of support for Open Standards from the latest version of the EU's interoperability recommendations, the European Interoperability Framework (EIF)" />
  6. <title>EIF BSA Letter</title>
  7. </head>
  8. <body>
  9. <p id="category"><a href="/activities/os/os.html">Open Standards</a></p>
  10. <h1>Defending Open Standards: FSFE refutes BSA's false claims to European Commission</h1>
  11. <p id="introduction">The Business Software Alliance (BSA) is pressuring the European Commission to remove the last vestiges of support for Open Standards from the latest version of the EU's interoperability recommendations, the European Interoperability Framework.
  12. <br /><br />
  13. FSFE has obtained a copy of <a href="/activities/os/bsa-letter-ec.pdf">a letter sent to the Commission</a> by the BSA last week. In the following paragraphs we analyse the BSA's arguments and explain why their claims are false, and why Open Standards are key to interoperability and competition in the European software market. We have <a href="/activities/os/bsa-eif-letter-fsfe-response.pdf">shared this analysis</a> with the European Commission.</p>
  14. <ol>
  15. <li><a href="#1">Royalty-free patent licensing opens up participation and promotes innovation</a></li>
  16. <li><a href="#2">The BSA's example standards are irrelevant to the software field</a></li>
  17. <li><a href="#3">(F)RAND licensing in software standards is unfair and discriminatory</a></li>
  18. <li><a href="#4">BSA not representative of even its own membership, much less of software industry as a whole</a></li>
  19. <li><a href="#5">(F)RAND incompatible with most Free Software licenses</a></li>
  20. <li><a href="#6">Recommended preference for Open Standards is entirely unrelated to EU's negotiating position vis-a-vis China</a></li>
  21. <li><a href="#7">Restriction-free specifications will promote standardisation, competition and interoperability</a></li>
  22. <li><a href="#8">Recommendations</a></li>
  23. </ol>
  24. <h2 id="1">Royalty-free patent licensing opens up participation and promotes innovation</h2>
  25. <p>In its letter, the BSA argues that "[I]f the EU adopts a preference for royalty/patent-free specifications, this undermines the incentives that firms have to contribute leading-edge innovations to standardization - resulting in less innovative European specifications, and less competitive European products."</p>
  26. <p>Actually this reflects a gross misconception of standards, their role and their working.</p>
  27. <ol>
  28. <li>Zero-royalty licensing conditions do not prevent patented technologies to be included in standards. Rather the contributor is required to avoid imposing running royalties on implementations.</li>
  29. <li>The single most successful technology platform on Earth, the Internet, is built on standards that have been made fully available under zero-royalty licensing conditions. Indeed the W3C, the standard setting organization (SSO) that governs the web standards has through consensus adopted a zero-royalty "IPR policy", where royalty bearing technologies are allowed to be contributed only on a very exceptional base. Rather than stifling inventive activity, as the BSA claims, this has turned the Internet into a hotbed of innovation. Indeed, it is the very nature of standards that they stabilise a platform on top of which competitors can create innovative and interoperable solutions<a class="fn" href="#refs">1</a>.</li>
  30. <li>Contrary to the BSA's claim, zero-royalty patent licensing policies open up participation in software standard-setting to the widest possible group of market players and implementers. As a result, software standards coming out of standard-setting organisations with zero-royalty patent licensing policies such as the W3C have been widely adopted, with the HTML standard only being the most prominent example.</li>
  31. </ol>
  32. <p>From a broader policy perspective, it is also questionable that innovators, who are already receiving an incentive through a patent, would need to be further incentivised by having that patent included in a standard. A patent does not equal a right to a guaranteed revenue stream.</p>
  33. <h2 id="2">The BSA's example standards are irrelevant to the software field</h2>
  34. <p>The BSA argues that "[m]any of today's most widely-deployed open specifications incorporate patented innovations that were invented by commercial firms...including WiFi, GSM , and MPEG." </p>
  35. <p>This is an attempt to create a false dichotomy between "commercial" companies inventing patented technology, in contrast to "non-commercial" inventions which are not patented. In reality a great wealth of unpatented modern technology originating in commercial companies constitute globally implemented standards (such as HTML5), whilst continuing to provide their creators with revenue.
  36. There is no such divide, either economical or ideological, between hardware and software technologies which are patented, and those which are not. Yet the BSA divisively implies there is a difference between conventional and accepted business methods, which they associate with patents, and un-businesslike non-commercial organisations, which they associate with patent-free technology. Given the increasing prevalence of Free Software in Europe's IT service market, such a claim is plainly false.</p>
  37. <p>The standards which the BSA cites as examples (with the exception of MPEG<a class="fn" href="#refs">2</a>) relate to hardware based technologies. The economics of the hardware market are very different from the software market. While entry into the hardware market requires very substantial investments, software companies can be started with very small amounts of capital. Requiring such software start-up to pay royalties for implementing software standards would significantly raise the barriers to market entry, reduce innovation and hinder competition, as well as raising prices for consumers (including public sector organisations).</p>
  38. <p>For software, however, it is clear that allowing patents to be included in software standards on (F)RAND terms will unduly and unnecessarily increase the barriers to entry into the European software market, making Europe's ICT economy less competitive.</p>
  39. <h2 id="3">(F)RAND licensing in software standards is unfair and discriminatory</h2>
  40. <p>The BSA argues that "[R]equirements that an open specification be "freely implement[able]" and capable of being shared and re-used are ambiguous, and suggest that the standard must be free of intellectual property rights (IPR)".</p>
  41. <p>The BSA further argues that "[FRAND ensures that] implementers of a standard can utilize those innovations on fair terms. It allows inventors to charge a reasonable fee when their technologies are incorporated into specifications[.]"
  42. In software standards, (F)RAND terms in fact discriminate against Free Software and any business model based on it. Most widely used Free Software licenses do not allow for imposing additional conditions upon downstream recipients. Yet (F)RAND would require such conditions to be imposed, usually in the form of running royalties, rendering (F)RAND licensing policies incompatible with Free Software. Where software standards are concerned, this renders the (F)RAND approach neither reasonable nor non-discriminatory.</p>
  43. <p>Conversely, "zero-royalty" does not exclude proprietary (and even heavily patented) implementations. Indeed "Zero-royalty" means that if certain technologies are mandated by a standard, they must be available to everybody without requiring running royalties. Meanwhile the implementations can be distributed under any given license and include any technology, provided that the standard is respected.</p>
  44. <p>The royalty-free HTML standard for example has been implemented in a plethora of browsers, both Free Software and proprietary. This clearly demonstrates that a royalty-free software standard can enable widespread adoption, and drive innovation through competition.</p>
  45. <h2 id="4">BSA not representative of even its own membership, much less of software industry as a whole</h2>
  46. <p>The BSA argues that "[EIF] could be read to mean that the most innovative European and foreign companies are not welcome to participate in standards processes if they own patents in the relevant technologies and seek compensation for their inventions if those patents are made part of the standard."</p>
  47. <p>The BSA further claims that "[S]takeholders [recognize] the important link between IPR and standardization - and also [recognize] that FRAND-based standards are highly flexible and can be implemented in a broad range of solutions, open source and proprietary".</p>
  48. <p>Contrary to the BSA's claim to represent a unified position of the software industry, we note that ECIS, which is formed by important industry stakeholders (some of which are also members of BSA) say the opposite<a class="fn" href="#refs">3</a>. Despite having a large patent portfolio, ECIS' members want standards for software interoperability to remain unencumbered of running patent royalty requirements []. To name just one example, Google has heavily contributed to zero-royalties standards by offering an industry-backed alternative to MPEG.</p>
  49. <h2 id="5">(F)RAND incompatible with most Free Software licenses</h2>
  50. <p>The BSA claims that "most OSS license are entirely compatible with FRAND-based licensing."</p>
  51. <p>By any reasonable metric (whether based upon the quantity of code available or the importance of it, or both) the most relevant Free (open source) Software licenses are:</p>
  52. <ol>
  53. <li>GNU GPL and LGPL</li>
  54. <li>Mozilla Public License</li>
  55. <li>Apache Public License</li>
  56. <li>BSD/MIT and other ultrapermissive licenses</li>
  57. <li>EUPL</li>
  58. </ol>
  59. <p>All of which, with the only arguable but uncertain exception of the ultrapermissive category, are clearly incompatible with a patent royalty bearing regime. According to the statistics released by <a href="">Black Duck Software</a>, more than 85% of Free Software projects are distributed under licenses that are incompatible with patent royalty-bearing regimes. The GNU General Public License (GPL) is demonstrated to be the most widely used Free Software license by far, accounting for almost half of all projects.
  60. Including patented technologies in Free Software products, where it is possible, requires implementers to mix proprietary parts with Free Software in awkward ways. In such cases the resulting code is necessarily proprietary software<a class="fn" href="#refs">5</a>.</p>
  61. <h2 id="6">Recommended preference for Open Standards is entirely unrelated to EU's negotiating position vis-a-vis China</h2>
  62. <p>The BSA claims that "[t]he ambiguity of the EIF's proposed preference will no doubt compromise the Commission's ability to maintain its robust defence of Europe's IPR holders [against Chinese threats]."</p>
  63. <p>Claims that a recommendation to express preference for open specifications will weaken the EU's negotiating position vis-a-vis China are plainly false. Recommendations regarding the use of open software specifications in the public sector have no bearing whatsoever on the Commission's stance. Moreover, it bears repeating that "zero royalty" standards do not contradict any "robust defence" of patents, copyright and trademarks.</p>
  64. <p>We note that in the United States, similar concerns were submitted to the US Trade Representative in the preparation for the 2010 US Special 301 report on obstacles to trade. The US Trade Representative chose not to include those concerns in the report, clearly demonstrating that the government of the United States considers this a non-issue. While such claims may be made during efforts to influence public policy, there is a marked absence of attempts to get such preferences removed by legal means - presumably because those making these claims know full well that they have no backing in fact.</p>
  65. <h2 id="7">Restriction-free specifications will promote standardisation, competition and interoperability</h2>
  66. <p>The BSA claims that "the EIF's proposed preference for IP-free specifications will undermine...standardization, competitiveness and interoperability over the longer term."</p>
  67. <p>We are unable to determine what the BSA means by "IP-free" specifications, although we do believe that such wording suggests an insufficient understanding of the standard-setting process on the BSA's part.</p>
  68. <p>The claim that the current wording of EIF could undermine interoperability is simply unacceptable. It flows from unproven assumptions that we have shown to be false in the above discussion. Currently, lock-in effects resulting from the use of proprietary programs and file formats often prevent public administrations from freely choosing their IT solutions. Instead, they remain tied to a particular vendor. The difficulties of Brighton City Council and the Swiss canton of Solothurn (to name only two examples from recent months) along with numerous other public bodies in migrating from one IT solution to another illustrate how vendor lock-in caused by patent-encumbered software standards ties users to suboptimal solutions, at great cost to taxpayers.</p>
  69. <p>Conversely, software standards which can be implemented without restrictions allow many competing implementations to interoperate with one another. In this setting, monopoly profits for a very limited number of big players are replaced with a vibrant, innovative market driven by fierce competition. This results in better solutions and services at lower prices.</p>
  70. <h2 id="8">Recommendations</h2>
  71. <p>In the light of the above considerations, we urge the Commission to encourage interoperability and competition in the European software market, rather than giving incumbent dominant companies an additional lever to maintain their control of the market. To this end, we ask the Commission not to add an endorsement of (F)RAND licensing policies for software standards.
  72. Instead, we urge the Commission to maintain the recommendation that specifications can be considered only open if they can be implemented and shared under different software licensing models, including Free Software<a class="fn" href="#refs">6</a> licensed under the Gnu GPL.</p>
  73. <p>We also urge the Commission to include in the revised European Interoperability Framework a robust recommendation for public bodies to avail themselves of the advantages of software based on Open Standards<a class="fn" href="#refs">7</a> in terms of choice, competition, freedom from lock-in and long-term access to data.</p>
  74. <h2 id="fn">Footnotes</h2>
  75. <ol id="refs">
  76. <li>See e.g. Rishab Aiyer Ghosh, Philipp Schmidt (2006): United Nations University Policy Brief, Number 1, 2006: "Open standards, properly defined, can have the unique economic effect of allowing "natural" monopolies to form in a given technology, while ensuring full competition among suppliers of that technology." [emphasis added]</li>
  77. <li>MPEG is specifically designed to expressly mandate patented technologies even where they are largely replaceable by (arguably) non patented encumbered alternatives. This is conceivably due to the need to extract as much profits as possible from the use of their peculiar implementation of certain mathematical principles than to the need to create a common and standardized platform for interoperability purposes.
  78. <br />
  79. Moreover, most of the MPEG standards were established in a time when codecs were made in hardware both because the available bandwidth was limited, the generic hardware was not sufficiently powerful and</li>
  80. <li>See <a href="">ECIS' reaction</a> from October 13, 2010 to the BSA's letter</li>
  81. <li>For a discussion on hybrid solutions in network protocols see <a href="/activities/ms-vs-eu/fsfe_art18_reply_published_sourcecode.pdf">FSFE and Samba Team's response to Article 18</a>.</li>
  82. <li>See <a href="">FSFE's definition of Free Software</a></li>
  83. <li>As defined in <a href="/activities/os/def.html">FSFE's definitions of an open standard</a></li>
  84. </ol>
  85. </body>
  86. <timestamp>$Date: 2010-10-05 16:30:51 +0200 (Tue, 05 Oct 2010) $ $Author: samtuke $</timestamp>
  87. <author id="gerloff" />
  88. <author id="piana" />
  89. <author id="tuke" />
  90. <date>
  91. <original content="2010-10-15" />
  92. </date>
  93. <download type="pdf" content="/activities/os/bsa-eif-letter-fsfe-response.pdf" />
  94. </html>