Source files of fsfe.org, pdfreaders.org, freeyourandroid.org, ilovefs.org, drm.info, and test.fsfe.org. Contribute: https://fsfe.org/contribute/web/ https://fsfe.org
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.

311 lines
18KB

  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <html>
  3. <version>1</version>
  4. <head>
  5. <title>Why is FRAND bad for Free Software?</title>
  6. </head>
  7. <body class="article" microformats="h-entry">
  8. <p id="category"><a href="/activities/os/os.html">Open Standards</a></p>
  9. <h1 id="why-is-frand-bad-for-free-software">Why is FRAND bad for Free Software?</h1>
  10. <p>FRAND ("fair, reasonable, and non-discriminatory") is an acronym
  11. used to refer to a wide array of patent licensing practices
  12. developed in the context of industry standards.</p>
  13. <p>Despite a technology being standardised, it is still possible
  14. for someone to hold a patent over it in some jurisdictions. Since
  15. commerce is global, this forces everyone to ask the patent holder
  16. for a licence before implementing the invention, thus granting
  17. her a broad power over her competitors. To reduce such power,
  18. the industry resorted to agreements to bind patent holders to
  19. certain licensing conditions, usually referred as the "fair,
  20. reasonable and non-discriminatory" (FRAND) terms.</p>
  21. <p>In most cases, such licences make a proper Free Software implementation
  22. of the standard impossible, due to numerous incompatibilities
  23. with the way Free Software functions and is distributed. As a
  24. consequence, FRAND licences cannot be considered fair, reasonable
  25. nor non-discriminatory.</p>
  26. <h3 id="what-is-frand">What is FRAND?</h3>
  27. <p>A major challenge of FRAND is it is a fuzzy concept, involving
  28. subjective judgment that can often only be made firm by legal
  29. action. For example, there is no consensus on what are "fair",
  30. "reasonable" and "non-discriminatory" terms:</p>
  31. <ul>
  32. <li><p><strong>Fair</strong> primarily relates to the underlying
  33. licensing terms, which should not be anti-competitive nor would
  34. be considered unlawful if imposed by a dominant firm in their
  35. relative market.</p></li>
  36. <li><p><strong>Reasonable</strong> refers mainly to licensing rates.</p></li>
  37. <li><p><strong>Non-discriminatory</strong> relates to both
  38. the terms and the rates, requiring similar treatment for each
  39. licensee.</p></li>
  40. </ul>
  41. <h3 id="why-is-frand-incompatible-with-free-software">Why is FRAND incompatible with Free Software?</h3>
  42. <p>FRAND licence terms are usually negotiated in secret and kept
  43. confidential by the parties involved. However, FRAND terms seem
  44. to often require a payment of royalties based on the volume of
  45. distribution (such as the number of distributed copies). They
  46. also rarely allow sublicensing to the third parties, in a way
  47. that requires no further action from the sublicensee to obtain
  48. the same rights to implement the standard. It is a well established
  49. fact that such requirements are incompatible with some of the
  50. most common terms under which Free Software is developed and
  51. distributed <a href="#fn1" class="fn" id="fnref1">1</a>.</p>
  52. <p>Free Software gives its user a high level of control over the
  53. software by granting far-reaching freedoms to inspect the source
  54. code, and to study and innovate upon that software. It is based
  55. on the principle that everyone, whether an individual or a company,
  56. can be a user, developer, distributor, or any combination of the
  57. above. Only the terms that permit technology to be implemented
  58. and distributed without violating these conditions will be in
  59. practice compatible with Free Software <a href="#fn2" class="fn" id="fnref2">2</a>.</p>
  60. <p>For example, Section 7 of the GPL v2, which is one of the most
  61. widely used Free Software licences, ensures that the presence of
  62. any extra restriction preventing users from exercising the freedoms
  63. in the license -i.e. imposing patent royalties or the requirement
  64. to obtain an individual licence- revokes the right to continue
  65. distribution of the software.</p>
  66. <p>As Free Software gives each user the freedom to redistribute
  67. the software itself, keeping track and collecting royalties based
  68. on distributed copies is also, in practice, impossible. This is
  69. not just a matter of source code licenses; any terms which require
  70. a developer to seek additional permission beyond the licence in
  71. order to use, improve or share the software are incompatible with
  72. the norms of open communities developing Free Software.</p>
  73. <p>Another incompatibility of FRAND with Free Software lies in
  74. the requirement of the individual licence that usually cannot be
  75. automatically transferred to the third parties. This is contradictory
  76. to Free Software that automatically grants the same rights and
  77. freedoms to downstream recipients without the necessity to
  78. sublicense.</p>
  79. <p>Consequently, it has been estimated that due to modern near-universal
  80. software development practices, hardly any new product on the
  81. software market is built without containing easily accessible
  82. Free Software code<a href="#fn3" class="fn" id="fnref3">3</a>,
  83. which makes Free Software indispensable for innovation and the
  84. economic growth.</p>
  85. <p>In this respect, the "non-discriminatory" criterion cannot be
  86. met, as it excludes substantial number of actors and innovative
  87. force that work with Free Software from implementing the FRAND
  88. licensed technology. Subsequently, it follows that a FRAND-licensed
  89. Standard Essential Patent (SEP) is neither "fair" nor "reasonable".</p>
  90. <h3 id="can-frand-be-really-frand-for-free-software">Can FRAND be really FRAND for Free Software?</h3>
  91. <p>Some rare FRAND terms allow payment of a lump sum amount, so
  92. that the developers can avoid keeping track of the distributed
  93. copies. This practice might seem like a viable option, but only
  94. big corporations with a dedicated legal department are capable
  95. of negotiating such terms, thus excluding individual programmers
  96. and small and medium enterprises (SMEs). It is essential to
  97. ensure that different actors can enter the market, especially in
  98. the ICT sector, where it is not unusual to go from being a start-up
  99. to a leader company in less than a decade.</p>
  100. <p>Easier access to standardised technologies will instead contribute
  101. to competition, as more new players will be allowed to emerge on
  102. the market and base their ideas on the existing technologies.</p>
  103. <p>The requirement of royalties-per-copy in FRAND is not the only
  104. obstacle between standard's implementation in Free Software.
  105. The inherent incompatibility lies within the fact that FRAND
  106. completely neutralises the collaborative open model behind Free
  107. Software, by restricting the exercise of freedoms granted by the
  108. latter.</p>
  109. <p>For example, it is common for FRAND to include the requirement
  110. to contact the SEP holder to obtain an individual licence. This
  111. is also discriminatory against Free Software, because it would
  112. require any user willing to redistribute modified versions to
  113. contact the SEP holder, wasting time and resources and seriously
  114. impairing the collaborative model that drives Free Software.
  115. History shows developers avoid technologies licensed in this way.</p>
  116. <p>The appropriate licensing scheme for Free Software would be
  117. the one that places no restrictions in exercising rights granted
  118. by Free Software, so-called "Restrcition free" terms. Similar
  119. licence terms can be achieved by forcing FRAND to be compatible
  120. with the GPL by definition. Standard setting organisations (SSOs)
  121. can require participants to the standardisation process to explicitly
  122. agree that a licence is FRAND only if it allows the use and distribution
  123. of the essential patented technology under terms that are not less
  124. restrictive than the GNU GPL v.2 or any later version.</p>
  125. <p>Furthermore, to ensure that such a policy is not circumvented,
  126. SSOs should carefully consider the status of all the components
  127. of any new standard. It is not uncommon for a new standard to be
  128. built upon a previous one. If the latter was drafted under
  129. different rules (e.g. allowing royalty-based FRAND or
  130. unrestricted patents), the full implementation of the new standard
  131. may depend on the licensing terms of SEPs included in the older
  132. standard. Such a situation will undermine the efforts that were
  133. made to properly address the problem of SEPs.</p>
  134. <p>It is also not uncommon for companies to place so-called
  135. "blanket claims", that is to declare that they own SEP without
  136. specifying any details of such patents.<a href="#fn4" class="fn" id="fnref4">4</a>
  137. This practice in addition to the policies adopted in several SSOs
  138. that do not guarantee the accuracy of the information provided,
  139. place unnecessary and burdensome barriers for the standard implementation
  140. by any developer wishing to do so. Hence, the final necessary
  141. complement to this setup is an adequate enforcement system to
  142. ensure that patent holders are kept to their obligations.</p>
  143. <h3 id="why-frand-is-not-good-for-software">Why FRAND is not good for software?</h3>
  144. <p>In the field of standards governing software, internet and web,
  145. there is a distinct absence of SEPs<a href="#fn5" class="fn" id="fnref5">5</a>.</p>
  146. <p>This is particularly evident in the policies of several SSOs
  147. working in these fields: for example the vast majority of standards
  148. recognised by the Organisation for the Advancement of Structured
  149. Information Standards (OASIS) requires royalty free terms<a href="#fn6" class="fn" id="fnref6">6</a>
  150. and although the option of FRAND is included in their policy, OASIS
  151. recognises its trend towards royalty-free standards<a href="#fn7" class="fn" id="fnref7">7</a>.
  152. The Internet Engineering Task Force (IETF) discourages encumbered
  153. patent standards in the general instructions to their working
  154. groups<a href="#fn8" class="fn" id="fnref8">8</a>. Even better,
  155. the W3C requires any SEP to be licenced to everyone on royalty
  156. free basis<a href="#fn9" class="fn" id="fnref9">9</a>.</p>
  157. <p>SEP and FRAND emanated from telecommunications sector and through
  158. traditional SSOs, while software, internet and web standards have
  159. developed in a more collaborative way, i.e. through fora and
  160. consortia<a href="#fn10" class="fn" id="fnref10">10</a>. This
  161. difference has to be taken into account while regulating the work
  162. of SSOs. Applying the model that has been developed for one sector
  163. to another, which has practically and historically developed in a
  164. different way, can lead to consequences opposite to the aim of
  165. standardisation. As such, the approach of 'one size fits all' is
  166. inappropriate and can stifle innovation instead of encouraging it.</p>
  167. <h3 id="the-alternative-to-frand">The alternative to FRAND</h3>
  168. <p>The way to achieve the widest interoperability and competition
  169. on the market is to adopt Open Standards that are compatible with
  170. Free Software.<a href="#fn11" class="fn" id="fnref11">11</a></p>
  171. <p>The rapid development of software, web and internet technology
  172. has been largely based on Open Standards, which are available
  173. free of restrictions and royalties. This shows that restriction-free
  174. standards are crucial in an environment where innovation is rapid
  175. and accumulative, and where most actors are small and lack the
  176. resources to engage in sophisticated patent licensing transactions.
  177. Licensing conditions that pose barriers for such actors to enter
  178. the market or compete with their large counterparts are
  179. significantly hampering the competition and as such cannot be
  180. called fair, reasonable or non-discriminatory. Therefore, only
  181. licences that are truly Restriction free allow the standard to be
  182. an Open Standard, i.e. "free from legal or technical clauses
  183. that limit its utilisation by any party or in any business
  184. model"<a href="#fn12" class="fn" id="fnref12">12</a>.</p>
  185. <p>Furthermore, drafting such standards in a minimalistic<a href="#fn13" class="fn" id="fnref13">13</a>
  186. way will ensure that companies of different size are actually in
  187. the position to implement them, which will achieve true non-discrimination
  188. across different business sizes and models. This will also contribute
  189. to the wider and more effective adoption of standards across industries.
  190. Non-minimalistic standards are instead cumbersome and require huge
  191. investments of time and resources to be implemented.</p>
  192. <p>In addition to Open Standards, the widest adoption of standards
  193. can be in practice achieved by allowing software to act as as reference
  194. implementation too. This is particularly important because for
  195. most software standards the formal specification is insufficient,
  196. and the actual standard is defined both through the written
  197. specification and actual implementations. For the implementer
  198. the reference implementation is more valuable because it allows
  199. her to avoid the extended phase of trial-and-error in order to
  200. resolve specification ambiguities. Hence publishing software under
  201. Free Software licences will contribute to the widest adoption of
  202. standards in practice.</p>
  203. <h2 id="conclusion">Conclusion</h2>
  204. <p>FRAND is not only incompatible with most of Free Software, but
  205. is not designed to govern software at all.</p>
  206. <p>In order to overcome this contradiction, it is necessary to
  207. ensure that SEPs are licensed under terms that are compatible with
  208. Free Software, e.g. Restriction free. However, this option might
  209. still place additional obstacles to the implementation of
  210. innovative technology in Free Software, depending on the actual
  211. content of the SEP licence and on the enforcing capabilities of
  212. the standard setting organisation.</p>
  213. <p>The widest adoption of standards, which is in principle the aim
  214. of FRAND, can be achieved by developing them as open and minimalistic
  215. and by requiring a reference implementation released as Free Software.
  216. These standards will ensure the widest competition of different
  217. Free Software and proprietary actors on the market, without excluding
  218. one or the other.</p>
  219. <h2 id="fn">Footnotes</h2>
  220. <ol>
  221. <li id="fn1"><p>Ian Mitchell, Stephen Mason, <a href="http://www.ifosslr.org/ifosslr/article/view/57">"Compatibility Of The Licensing Of Embedded Patents With Open Source Licensing Terms""</a>, IFOSSLR, 2011.<a href="#fnref1" class="ref">↩</a></p></li>
  222. <li id="fn2"><p>Georg Greve, <a href="/activities/os/ps.en.html">"Analysis on balance: Standardisation and Patents"</a>, 2008.<a href="#fnref2" class="ref">↩</a></p></li>
  223. <li id="fn3"><p>Björn Lundell et al., <a href="http://his.diva-portal.org/smash/get/diva2:925474/FULLTEXT01.pdf">"On Implementation of Open Standards in Software: To What Extent Can ISO Standards be Implemented in Open Source Software"</a>, International Journal of Standardization Research,Vol. 13, no 1, 47-73 p, 2015.<a href="#fnref3" class="ref">↩</a></p></li>
  224. <li id="fn4"><p>Rudi Bekkers, Joel West, <a href="http://home.tm.tue.nl/rbekkers/Bekkers%20West%20%28forthcoming%20Jan%2009%29%20Telecommunications%20Policy.pdf">"The Limits to IPR Standardization Policies as Evidenced by Strategic Patenting in UMTS"</a>,Telecommunications Policy, 2009.<a href="#fnref4" class="ref">↩</a></p></li>
  225. <li id="fn5"><p>Mark Bohhanon, <a href="http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2477533">"Out of the Murky Lagoon and into… Is there a Emerging Consistent US Government Policy on Standard Essential Patents?"</a>, 2014.<a href="#fnref5" class="ref">↩</a></p></li>
  226. <li id="fn6"><p>OASIS, <a href="https://www.oasis-open.org/org/faq">FAQ section</a>, question No. 7. “What are the IPR Policies of OASIS?”.<a href="#fnref6" class="ref">↩</a></p></li>
  227. <li id="fn7"><p><a href="http://www.nist.gov/standardsgov/upload/OASIS.pdf">“OASIS response to NSTC request for feedback on standard practices”</a>, 75 FR 76397 (2011).<a href="#fnref7" class="ref">↩</a></p></li>
  228. <li id="fn8"><p>IETF, <a href="https://tools.ietf.org/html/rfc3979">RFC 3979</a>.<a href="#fnref8" class="ref">↩</a></p></li>
  229. <li id="fn9"><p><a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Requirements">W3C patent policy</a>.<a href="#fnref9" class="ref">↩</a></p></li>
  230. <li id="fn10"><p>Mark Bohhanon, <a href="http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2477533">“Out of the Murky Lagoon and into… Is there a Emerging Consistent US Government Policy on Standard Essential Patents?”</a>, 2014-08-08.<a href="#fnref10" class="ref">↩</a></p></li>
  231. <li id="fn11"><p>Rishab Gosh, <a href="http://www.flosspols.org/deliverables/FLOSSPOLS-D04-openstandards-v6.pdf">“An Economic Basis for Open Standards”</a>, Policy Report of FLOSSPOLS Project managed by the European Commission, University of Maastricht, 2005.<a href="#fnref11" class="ref">↩</a></p></li>
  232. <li id="fn12"><p><a href="/activities/os/def.en.html">Open standard definition</a>.<a href="#fnref12" class="ref">↩</a></p></li>
  233. <li id="fn13"><p>Bernhard Reiter, <a href="/activities/os/minimalisticstandards.en.html">“The minimal principle: because being an open standard is not enough”</a>.<a href="#fnref13" class="ref">↩</a></p></li>
  234. </ol>
  235. </body>
  236. <date>
  237. <original content="2016-06-20"/>
  238. </date>
  239. <sidebar promo="our-work">
  240. <h2>Table of Contents</h2>
  241. <ul>
  242. <li><a href="#what-is-frand">What is FRAND?</a></li>
  243. <li><a href="#why-is-frand-incompatible-with-free-software">Why is FRAND incompatible with Free Software?</a></li>
  244. <li><a href="#can-frand-be-really-frand-for-free-software">Can FRAND be really FRAND for Free Software?</a></li>
  245. <li><a href="#why-frand-is-not-good-for-software">Why FRAND is not good for software?</a></li>
  246. <li><a href="#the-alternative-to-frand">The alternative to FRAND</a></li>
  247. <li><a href="#conclusion">Conclusion</a></li>
  248. </ul>
  249. <h2>Related links</h2>
  250. <ul>
  251. <li><a href="/activities/os/os.en.html">More on Open Standards</a></li>
  252. <li><a href="/campaigns/swpat/swpat.en.html">Software patents in Europe</a></li>
  253. </ul>
  254. </sidebar>
  255. <tags>
  256. <tag content="Open Standards">OpenStandards</tag>
  257. </tags>
  258. </html>