<?xml version="1.0" encoding="UTF-8"?><rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>SEPD &amp;mdash; Webmink In Draft</title>
    <link>https://the.webm.ink/tag:SEPD</link>
    <description>Things cooking in the Minkiverse. They move elsewhere when the oven pings.</description>
    <pubDate>Sun, 26 Apr 2026 15:42:01 +0100</pubDate>
    <item>
      <title>SEPs Cut Both Ways</title>
      <link>https://the.webm.ink/seps-cut-both-ways</link>
      <description>&lt;![CDATA[I just read a news story about how Chinese tech companies are threatening Europe by registering so many patents. Turns out it&#39;s in the context of &#34;open standards&#34; and is actually Chinese companies copying what European multinationals have done for years with patents embedded in standards. That Sword of Damocles cuts both ways.&#xA;&#xA;The handles of three gigantic sword statues seen against a blue sky&#xA;!--more--&#xA;I still meet people who think that implementing an &#34;open standard&#34; is something anyone can do freely. But it&#39;s unfortunately not so - the word &#34;open&#34; in standards is not used the same way as &#34;open&#34; in software. This difference exists for a reason, resisting even clarification by the European Interoperability Framework (EIF) v1 where pro-patent lobbyists managed to get the clarification removed in the subsequent version. Even if you can get the specification without having to pay a significant sum for the privilege, chances are a standard from a body like ETSI will have a high aggregate patent royalty associated with any implementation. &#xA;&#xA;Why? For years, cartel-like behaviour by technology companies has used patents they have embedded in formal standards to control the markets they monetise. They do this not just legally but with the encouragement of market authorities, who regard it as a reasonable compromise despite the obviously anti-competitive nature of the practice (which they freely admit). So they describe as &#34;open&#34; any standard created under a standards-body process that is theoretically equally open to all, which thus circumvents the anti-trust rules. &#xA;&#xA;Once embedded in the specification, &#34;standard-essential patents&#34; (SEPs) must then be licensed in order to implement technologies the companies include in core standards for mobile phones, media playback, consumer device functions and more. The terms are almost always based on per-unit royalties. This has proved extremely profitable, allowing companies to continue to harvest revenues from markets they may have been unable to monetise fairly via superior products. They are supposed to license on &#34;Fair, Reasonable and Non-Discriminatory&#34; (FRAND) terms, but recent research shows securing licenses can be extremely difficult, if not impossible. The European Commission is now legislating to partially address that in the upcoming SEP Directive, which is also perhaps motivated by a desire to address the use of the same system by China.&#xA;&#xA;But in some ways the royalties are the least issue. By creating SEPs, the corporations also gain market control, again in a way that amazingly does not break any anti-trust laws. The presence of SEPs ensures that all newcomers who are attempting to enter or disrupt a market are forced into NDA-secret negotiations with their incumbent competitors to get licenses. Controlling who can compete is just as valuable to the incumbents.&#xA;&#xA; It is not unknown for incumbents to use the covert control point of terms negotiation to disrupt market access by offering unreasonable terms regardless of commitments to FRAND licensing. This raises the barrier to entry in their markets and keeps costs -- and thus consumer prices -- high, while the market controllers are able to privately cross-license to each other to keep their own costs controlled and their margins high. The power asymmetry is also a valuable asset; courts start out assuming the supplicant is evading their responsibilities and may well intervene for the plaintiff while the case is running. Even without these extremes, it&#39;s common for patent owners to drag their feet to disadvantage licensees.&#xA;&#xA;But what if vendors in China behaved in a similar cartel-like manner and then gained control of a critical mass of SEPs needed to implement critical technologies? What if they also used their patents to block foreign companies from the Chinese market and to tax their products when they are finally allowed? Seemingly with little sense of irony, representatives of the incumbents interviewed by the Financial Times complained of just those scenarios starting to appear because of the single-minded intensity of patenting activities by Chinese companies. &#xA;&#xA;There&#39;s no doubt this is a threat to the livelihood of the incumbent companies. But perhaps the problem is not China but the practice of tolerating patents in standards itself? The lesson here is to carefully consider the privileges you exploit, lest others do the same. Live by the SEP, die by the SEP.&#xA;&#xA;---&#xA;Notes, Tags and Mentions&#xA;&#xA;#FRAND #RAND #SEP #Patents #SoftwarePatents #Standards #SEPD #OpenSource &#xA;If the story is paywalled try a longer ladder for fair use.&#xA;The two papers linked above are worth reading independently of the story as they document the creeping regulatory capture of &#34;FRAND&#34; and the near-impossibility securing licenses for a SEP-encumbered standard:&#xA;   Pocknell, Robert &amp; Djavaherian, Dave, The History of the ETSI IPR Policy: Using the Historical Record to Inform Application of the ETSI FRAND Obligation (September 27, 2022). http://dx.doi.org/10.2139/ssrn.4231645&#xA;   Lundell, Björn; Gamalielsson, Jonas &amp; Katz, Andrew, Implementing the HEVC standard in software: Challenges and Recommendations for organisations planning development and deployment of software (February 3, 2023). https://doi.org/10.18757/jos.2022.6695&#xA;&#xA;Follow @webmink@the.webm.ink to be informed of new posts. To discuss this post please reply from Mastodon etc. (search for the URL) &amp; include @webmink@meshed.cloud as WriteFreely still doesn&#39;t display replies. a href=&#34;/About&#34;More/a.]]&gt;</description>
      <content:encoded><![CDATA[<p>I just read a <a href="https://www.ft.com/content/57c16db1-023a-4c81-8507-7ccec851232e">news story</a> about how Chinese tech companies are threatening Europe by registering so many patents. Turns out it&#39;s in the context of “open standards” and is actually Chinese companies copying what European multinationals have done for years with patents embedded in standards. That Sword of Damocles cuts both ways.</p>

<p><a href="https://www.flickr.com/photos/webmink/4574073617/"><img src="https://live.staticflickr.com/4002/4574073617_b79e8e6dc7_h.jpg" alt="The handles of three gigantic sword statues seen against a blue sky" title="Scandinavian Swords"></a>

I still meet people who think that implementing an “open standard” is something anyone can do freely. But it&#39;s unfortunately not so – the word <a href="https://meshedinsights.com/2021/02/11/chalk-and-cheese/">“open” in standards is not used the same way as “open” in software</a>. This difference exists for a reason, resisting even clarification by the <a href="http://web.archive.org/web/20120710134922/https://ec.europa.eu/idabc/servlets/Docd552.pdf">European Interoperability Framework (EIF) v1</a> where pro-patent lobbyists managed to <a href="https://arstechnica.com/information-technology/2009/11/eu-waffles-on-open-standards-in-interoperability-guideline/">get the clarification removed</a> in the subsequent version. Even if you can get the specification without having to pay a significant sum for the privilege, chances are a standard from a body like <a href="https://etsi.org">ETSI</a> will have a high aggregate patent royalty associated with any implementation.</p>

<p>Why? For years, cartel-like behaviour by technology companies has <a href="https://dx.doi.org/10.2139/ssrn.4231645">used patents</a> they have embedded in formal standards to control the markets they monetise. They do this not just legally but with the encouragement of market authorities, who regard it as a reasonable compromise despite the obviously anti-competitive nature of the practice (which they freely admit). So they describe as “open” any standard created under a standards-body process that is theoretically equally open to all, which thus circumvents the anti-trust rules.</p>

<p>Once embedded in the specification, “standard-essential patents” (SEPs) must then be licensed in order to implement technologies the companies include in core standards for mobile phones, media playback, consumer device functions and more. The terms are almost always based on per-unit royalties. This has proved extremely profitable, allowing companies to continue to harvest revenues from markets they may have been unable to monetise fairly via superior products. They are supposed to license on “Fair, Reasonable and Non-Discriminatory” (FRAND) terms, but <a href="https://doi.org/10.18757/jos.2022.6695">recent research</a> shows securing licenses can be extremely difficult, if not impossible. The European Commission is now legislating to partially address that in the upcoming SEP Directive, which is also perhaps motivated by a desire to address the use of the same system by China.</p>

<p>But in some ways the royalties are the least issue. By creating SEPs, the corporations also gain market control, again in a way that amazingly does not break any anti-trust laws. The presence of SEPs ensures that all newcomers who are attempting to enter or disrupt a market are forced into NDA-secret negotiations with their incumbent competitors to get licenses. Controlling who can compete is just as valuable to the incumbents.</p>

<p> It is not unknown for incumbents to use the covert control point of terms negotiation to disrupt market access by offering unreasonable terms regardless of commitments to FRAND licensing. This raises the barrier to entry in their markets and keeps costs — and thus consumer prices — high, while the market controllers are able to privately cross-license to each other to keep their own costs controlled and their margins high. The power asymmetry is also a valuable asset; courts start out assuming the supplicant is evading their responsibilities and may well intervene for the plaintiff while the case is running. Even without these extremes, it&#39;s common for patent owners to drag their feet to disadvantage licensees.</p>

<p>But what if vendors in China behaved in a similar cartel-like manner and then gained control of a critical mass of SEPs needed to implement critical technologies? What if they also used their patents to block foreign companies from the Chinese market and to tax their products when they are finally allowed? Seemingly with little sense of irony, representatives of the incumbents interviewed by <a href="https://www.ft.com/content/57c16db1-023a-4c81-8507-7ccec851232e">the Financial Times</a> complained of just those scenarios starting to appear because of the single-minded intensity of patenting activities by Chinese companies.</p>

<p>There&#39;s no doubt this is a threat to the livelihood of the incumbent companies. But perhaps the problem is not China but the practice of tolerating patents in standards itself? The lesson here is to carefully consider the privileges you exploit, lest others do the same. Live by the SEP, die by the SEP.</p>

<hr>

<h3 id="notes-tags-and-mentions">Notes, Tags and Mentions</h3>
<ul><li><a href="https://the.webm.ink/tag:FRAND" class="hashtag"><span>#</span><span class="p-category">FRAND</span></a> <a href="https://the.webm.ink/tag:RAND" class="hashtag"><span>#</span><span class="p-category">RAND</span></a> <a href="https://the.webm.ink/tag:SEP" class="hashtag"><span>#</span><span class="p-category">SEP</span></a> <a href="https://the.webm.ink/tag:Patents" class="hashtag"><span>#</span><span class="p-category">Patents</span></a> <a href="https://the.webm.ink/tag:SoftwarePatents" class="hashtag"><span>#</span><span class="p-category">SoftwarePatents</span></a> <a href="https://the.webm.ink/tag:Standards" class="hashtag"><span>#</span><span class="p-category">Standards</span></a> <a href="https://the.webm.ink/tag:SEPD" class="hashtag"><span>#</span><span class="p-category">SEPD</span></a> <a href="https://the.webm.ink/tag:OpenSource" class="hashtag"><span>#</span><span class="p-category">OpenSource</span></a></li>
<li>If the story is paywalled try <a href="https://12ft.io/">a longer ladder</a> for fair use.</li>
<li>The two papers linked above are worth reading independently of the story as they document the creeping regulatory capture of “FRAND” and the near-impossibility securing licenses for a SEP-encumbered standard:
<ul><li>Pocknell, Robert &amp; Djavaherian, Dave, The History of the ETSI IPR Policy: Using the Historical Record to Inform Application of the ETSI FRAND Obligation (September 27, 2022). <a href="http://dx.doi.org/10.2139/ssrn.4231645">http://dx.doi.org/10.2139/ssrn.4231645</a></li>
<li>Lundell, Björn; Gamalielsson, Jonas &amp; Katz, Andrew, Implementing the HEVC standard in software: Challenges and Recommendations for organisations planning development and deployment of software (February 3, 2023). <a href="https://doi.org/10.18757/jos.2022.6695">https://doi.org/10.18757/jos.2022.6695</a></li></ul></li></ul>

<p><em>Follow <code><a href="https://the.webm.ink/@/webmink@the.webm.ink" class="u-url mention">@<span>webmink@the.webm.ink</span></a></code> to be informed of new posts. To discuss this post please reply from Mastodon etc. (search for the URL) &amp; include <code><a href="https://the.webm.ink/@/webmink@meshed.cloud" class="u-url mention">@<span>webmink@meshed.cloud</span></a></code> as WriteFreely still doesn&#39;t display replies. <a href="/About">More</a>.</em></p>
]]></content:encoded>
      <guid>https://the.webm.ink/seps-cut-both-ways</guid>
      <pubDate>Wed, 03 May 2023 10:28:46 +0100</pubDate>
    </item>
    <item>
      <title>Exempting Open Source From SEPs</title>
      <link>https://the.webm.ink/exempting-open-source-from-seps</link>
      <description>&lt;![CDATA[Update: Graduated to the OSI Blog.&#xA;!--more--&#xA;&#xA;With the European Commission soon to offer the Parliament a bill relating to Standard-Essential Patents (SEPs), it is worth taking time to understand exactly why vendors requiring negotiations to use the patents they have embedded in &#34;open&#34; standards is antithetical to open source practice.&#xA;&#xA;Yellow buoy with white radar reflector beacon on top, floating in aquamarine water and with a navy blue flash down the side stating WRECK in white letters&#xA;&#xA;The value and prosperity generated from open source arises from open source software licences seamlessly and frictionlessly permitting anyone to use, modify, and redistribute the software for any purpose including monetisation. When SEPs are licensed in such a way that bilateral negotiation with the licensors is a necessary element of software use, open source projects must necessarily avoid implementation of the associated standards to the extent that it is possible for them to do so. A requirement for bilateral, after-the-fact patent licensing is by definition not open source due to this introduction of licensing friction.  &#xA;&#xA;This is not a matter of ideology but of pragmatics. Open source developer communities operate on the assumption that the intellectual property owners – including both copyright and patent owners – have granted in advance all necessary rights to enjoy the software in any field of use and in any way. SEPs licensed on bilaterally-negotiated terms break this model and thus are naturally avoided. Further, the natural tendency for such bilateral negotiations to have some form of non-disclosure agreement (NDA) as a prerequisite also prevents many communities wanting to engage with them as unlike companies they do not have the mechanisms or resources to “firewall” NDA terms and thus routinely refuse NDAs. &#xA;&#xA;Not all standards have SEPs, and not all SEPs require licensing on restricted terms. While some standards are encumbered by patents registered by contributors to the standards process, patents are not an essential or inherent aspect of standardisation. As I explained for Open Forum Europe, some standards are developed in a sequence of activities that starts from a statement of requirements (“requirements-led”) while others are developed as a harmonisation of existing industry implementation (“implementation-led”). &#xA;&#xA;The requirements-led approach leads some standards development organisations (SDOs) to tolerate restricted licensing of included patented technologies due to the long lead-times in research and development investment by standards contributors. Despite this practice leading to barriers to entry in the resulting markets, tolerating SEP monetisation appears a compromise that in many cases can be proportionate to the delayed monetisation opportunity for participants.  While negotiation-required (FRAND) licensing of these SEPs is desirable for the commercial entities consuming them, the bilateral negotiation with NDA-enforced privacy that results unwittingly erects a barrier to the normal practice of open source communities, where both restrictions on mere use and requiring NDAs are anathemic antipatterns. As a consequence, the standards of this kind are unwelcome in open source projects.&#xA;&#xA;By contrast, the implementation-led approach frequently arises in circumstances where recovery of R&amp;D costs is already in hand and patent monetization is not a proportionate compromise. As a result, projects developed under an implementation-led approach (such as at OASIS and W3C) frequently opt for the restriction-free (RF) subset of FRAND terms that results in a negotiation-free usage. As a consequence, standards of this kind do not conflict with the realities of open source community operation and are widely implemented as open source.&#xA;&#xA;The Commission&#39;s activities regulating SEPs and their licensing are a golden opportunity to also harmonise their standards strategy with their open source aspirations. In particular, standards organisations should be required to ask contributors at standards-inception whether a negotiation-required or a negotiation-free/royalty-waived subset of FRAND is appropriate for the resulting standard and develop the standard on that basis -- with a default to waiving royalties. &#xA;&#xA;This does not mean ending SEPs anywhere else, but there is no point tolerating the desire of certain dominant parties at SDOs to try to pretend open source can be defined as copyright-only so they can tax implementation outside their legacy domains. Trying to openwash encumbered standards may satisfy the peers of their bubble but it will simply chill progress and proliferate standards outside it as the market works around the obstacle. The only way forward is to respect the 17-year-old settled consensus and embrace OSI&#39;s Open Standards Requirement. &#xA;&#xA;[OSI Submission]: https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/13109-Intellectual-property-new-framework-for-standard-essential-patents/F3257383_en&#xA;&#xA;#SEP #Standards #SEPD&#xA;&#xA;Follow @webmink@the.webm.ink to be informed of new posts. To discuss this post please reply from Mastodon etc. (search for the URL) &amp; include @webmink@meshed.cloud as WriteFreely still doesn&#39;t display replies. a href=&#34;/About&#34;More/a.]]&gt;</description>
      <content:encoded><![CDATA[<p><em>Update:</em> Graduated to the <a href="https://blog.opensource.org/why-open-source-should-be-exempt-from-standard-essential-patents/">OSI Blog</a>.
</p>

<p>With the European Commission <a href="https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/13109-Intellectual-property-new-framework-for-standard-essential-patents_en">soon to offer the Parliament a bill relating to Standard-Essential Patents (SEPs)</a>, it is worth taking time to understand exactly why vendors requiring negotiations to use the patents they have embedded in <a href="https://meshedinsights.com/2022/07/06/overloading-open/">“open” standards</a> is antithetical to open source practice.</p>

<p><img src="https://pix.webm.ink/storage/m/_v2/494915983315767297/0fca8ea69-e1c06b/ZNF1UkCxOnZg/8YQEL1QI5G1ybL4VJT3PJUm9hvfELKEnukgS6a7i.jpg" alt="Yellow buoy with white radar reflector beacon on top, floating in aquamarine water and with a navy blue flash down the side stating WRECK in white letters" title="The marker is not the hazard, it is the indicator not to go there"></p>

<p>The <a href="https://joinup.ec.europa.eu/collection/open-source-observatory-osor/news/first-results-study-impact-open-source#:~:text=The%20study%20found%20that%20Open,%E2%82%AC63%20billion%20per%20year.">value and prosperity generated from open source</a> arises from open source software licences seamlessly and frictionlessly permitting anyone to use, modify, and redistribute the software for any purpose including monetisation. When SEPs are licensed in such a way that bilateral negotiation with the licensors is a necessary element of software use, open source projects must necessarily avoid implementation of the associated standards to the extent that it is possible for them to do so. A requirement for bilateral, after-the-fact patent licensing is <a href="https://opensource.org/osd" title="See clause 7">by definition not open source</a> due to this introduction of licensing friction.</p>

<p>This is not a matter of ideology but of pragmatics. Open source developer communities operate on the assumption that the intellectual property owners – including both copyright and patent owners – have granted in advance all necessary rights to enjoy the software in any field of use and in any way. SEPs licensed on bilaterally-negotiated terms break this model and thus are naturally avoided. Further, the natural tendency for such bilateral negotiations to have some form of non-disclosure agreement (NDA) as a prerequisite also prevents many communities wanting to engage with them as unlike companies they do not have the mechanisms or resources to “firewall” NDA terms and thus routinely refuse NDAs.</p>

<p>Not all standards have SEPs, and not all SEPs require licensing on restricted terms. While some standards are encumbered by patents registered by contributors to the standards process, patents are not an essential or inherent aspect of standardisation. As I <a href="https://www.openforumeurope.org/wp-content/uploads/2019/03/OFA_-_Opinion_Paper_-_Simon_Phipps_-_OSS_and_FRAND.pdf">explained for Open Forum Europe</a>, some standards are developed in a sequence of activities that starts from a statement of requirements (“requirements-led”) while others are developed as a harmonisation of existing industry implementation (“implementation-led”).</p>

<p>The requirements-led approach leads some standards development organisations (SDOs) to tolerate restricted licensing of included patented technologies due to the long lead-times in research and development investment by standards contributors. Despite this practice leading to barriers to entry in the resulting markets, tolerating SEP monetisation appears a compromise that in many cases can be proportionate to the delayed monetisation opportunity for participants.  While negotiation-required (FRAND) licensing of these SEPs is desirable for the commercial entities consuming them, the bilateral negotiation with NDA-enforced privacy that results unwittingly erects a barrier to the normal practice of open source communities, where both restrictions on mere use and requiring NDAs are anathemic antipatterns. As a consequence, the standards of this kind are unwelcome in open source projects.</p>

<p>By contrast, the implementation-led approach frequently arises in circumstances where recovery of R&amp;D costs is already in hand and patent monetization is not a proportionate compromise. As a result, projects developed under an implementation-led approach (such as at OASIS and W3C) frequently opt for the restriction-free (RF) subset of FRAND terms that results in a negotiation-free usage. As a consequence, standards of this kind do not conflict with the realities of open source community operation and are widely implemented as open source.</p>

<p>The Commission&#39;s activities regulating SEPs and their licensing are a golden opportunity to also harmonise their standards strategy with their open source aspirations. In particular, standards organisations should be required to ask contributors at standards-inception whether a negotiation-required or a negotiation-free/royalty-waived subset of FRAND is appropriate for the resulting standard and develop the standard on that basis — with a default to waiving royalties.</p>

<p>This does not mean ending SEPs anywhere else, but there is no point tolerating the desire of certain dominant parties at SDOs to try to pretend open source can be defined as copyright-only so they can tax implementation outside their legacy domains. Trying to openwash encumbered standards may satisfy the peers of their bubble but it will simply chill progress and proliferate standards outside it as the market works around the obstacle. The only way forward is to respect the 17-year-old settled consensus and embrace OSI&#39;s <a href="https://opensource.org/osr">Open Standards Requirement</a>.</p>

<p><a href="https://the.webm.ink/tag:SEP" class="hashtag"><span>#</span><span class="p-category">SEP</span></a> <a href="https://the.webm.ink/tag:Standards" class="hashtag"><span>#</span><span class="p-category">Standards</span></a> <a href="https://the.webm.ink/tag:SEPD" class="hashtag"><span>#</span><span class="p-category">SEPD</span></a></p>

<p><em>Follow <code><a href="https://the.webm.ink/@/webmink@the.webm.ink" class="u-url mention">@<span>webmink@the.webm.ink</span></a></code> to be informed of new posts. To discuss this post please reply from Mastodon etc. (search for the URL) &amp; include <code><a href="https://the.webm.ink/@/webmink@meshed.cloud" class="u-url mention">@<span>webmink@meshed.cloud</span></a></code> as WriteFreely still doesn&#39;t display replies. <a href="/About">More</a>.</em></p>
]]></content:encoded>
      <guid>https://the.webm.ink/exempting-open-source-from-seps</guid>
      <pubDate>Wed, 15 Feb 2023 08:59:18 +0000</pubDate>
    </item>
  </channel>
</rss>