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.

why-frand-is-bad-for-free-software.en.xhtml 18KB

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