Standards &mdash; Webmink In Draft https://the.webm.ink/tag:Standards Things cooking in the Minkiverse. They move elsewhere when the oven pings. Sun, 26 Apr 2026 15:47:22 +0100 Standards and the Presumption of Conformity https://the.webm.ink/patents-and-the-presumption-of-conformity <![CDATA[This post has graduated to the OSI Blog. !--more-- Access to the law includes access to the harmonised standards it predicates. But is it right that those standards can include royalty-due patents (SEPs)? ---- If you have been following the progress of the Cyber Resilience Act (CRA), you may have been intrigued to hear that the next step following publication of the Act as law in the Official Journal is the issue of a European Standards Request (ESR) to the three official European Standards Bodies (ESBs). What is that about? Well, a law like the CRA is extremely long and complex and conforming to it will involve a detailed analysis and a lot of legal advice. Rather than forcing everyone individually to do that, the ESBs are instead sent a list of subjects that need proving and are asked to recommend a set of standards that, if observed, will demonstrate conformity with the law. This greatly simplifies things for everyone and leads to what the lawmakers call a "presumption of conformity". You could go comply with the law based on your own research, but realistically that's impossible for almost everyone so you will instead choose to observe the harmonised standards supplied by the ESBs. This change of purpose for standards is very significant. They have evolved from merely being a vehicle to promote interoperability in a uniform market - an optional tool for private companies that improves their product for their consumers - to being a a vehicle to prove legal compliance - a mandatory responsibility for all citizens and thus a public responsibility. This new role creates new challenges as the standards system was not originally designed with legal conformance in mind. Indeed, we are frequently reminded that standardisation is a matter for the private sector. So for example, the three ESBs (ETSI, CENELEC and CEN) all have "IPR rules" that permit the private parties who work within them to embed in the standards steps that are patented by those private companies. This arrangement is permitted by the European law that created the mechanism, Regulation 1025/2012 (in Annex II §4c). All three ESB's expressly tolerate this behaviour as long as the patents are then licensed to implementors of the standards on "Fair, Reasonable and Non Discriminatory" (FRAND) terms. None of those words is particularly well defined, and the consequence is that to implement the standards that emerge from the ESBs you may well need to retain counsel to understand your patent obligations and enable you to enter into a relationship with Europe's largest commercial entities to negotiate a license to those patents. Setting aside the obvious problems this creates for open source software (where the need for such relationships broadly inhibits implementation), it is also a highly questionable challenge to our democracy. At the foundation of our fundamental rights is the absolute requirement that first, every citizen may know the law that governs them and secondly every citizen is freely able to comply if they choose. The Public.Resource.Org case shows us this principle also extends to standards that are expressly or effectively necessary for compliance with a given law. But when these standards are allowed to have patents intentionally embodied within them by private actors for their own profit, citizens find themselves unable to practically conform to the law without specialist support and a necessary private relationship with the patent holders. While some may have considered this to be a tolerable compromise when the goal of standards was merely interoperability, it is clearly an abridgment of fundamental rights to condition compliance with the law on identifying and negotiating a private licensing arrangement for patents, especially those embedded intentionally in standards. Just as Regulation 1025/2012 will need updating to reflect the court ruling on availability of standards, so too should it be updated to require that harmonised standards will only be accepted from the ESBs if they are supplied on FRAND terms where all restrictions on use are waived by the contributors. ------- Links, Tags & Mentions #CRA #Patents #SEP #OpenSource #Reg1025 #Standards @carlmalamud@official.resource.org Follow @webmink@the.webm.ink to be informed of new posts. To discuss this post please reply from Mastodon etc. (search for the URL) & include @webmink@meshed.cloud as WriteFreely still doesn't display replies. a href="/About"More/a.]]> This post has graduated to the OSI Blog.

Access to the law includes access to the harmonised standards it predicates. But is it right that those standards can include royalty-due patents (SEPs)?

If you have been following the progress of the Cyber Resilience Act (CRA), you may have been intrigued to hear that the next step following publication of the Act as law in the Official Journal is the issue of a European Standards Request (ESR) to the three official European Standards Bodies (ESBs). What is that about? Well, a law like the CRA is extremely long and complex and conforming to it will involve a detailed analysis and a lot of legal advice.

Rather than forcing everyone individually to do that, the ESBs are instead sent a list of subjects that need proving and are asked to recommend a set of standards that, if observed, will demonstrate conformity with the law. This greatly simplifies things for everyone and leads to what the lawmakers call a “presumption of conformity”. You could go comply with the law based on your own research, but realistically that's impossible for almost everyone so you will instead choose to observe the harmonised standards supplied by the ESBs.

This change of purpose for standards is very significant. They have evolved from merely being a vehicle to promote interoperability in a uniform market – an optional tool for private companies that improves their product for their consumers – to being a a vehicle to prove legal compliance – a mandatory responsibility for all citizens and thus a public responsibility. This new role creates new challenges as the standards system was not originally designed with legal conformance in mind. Indeed, we are frequently reminded that standardisation is a matter for the private sector.

So for example, the three ESBs (ETSI, CENELEC and CEN) all have “IPR rules” that permit the private parties who work within them to embed in the standards steps that are patented by those private companies. This arrangement is permitted by the European law that created the mechanism, Regulation 1025/2012 (in Annex II §4c). All three ESB's expressly tolerate this behaviour as long as the patents are then licensed to implementors of the standards on “Fair, Reasonable and Non Discriminatory” (FRAND) terms. None of those words is particularly well defined, and the consequence is that to implement the standards that emerge from the ESBs you may well need to retain counsel to understand your patent obligations and enable you to enter into a relationship with Europe's largest commercial entities to negotiate a license to those patents.

Setting aside the obvious problems this creates for open source software (where the need for such relationships broadly inhibits implementation), it is also a highly questionable challenge to our democracy. At the foundation of our fundamental rights is the absolute requirement that first, every citizen may know the law that governs them and secondly every citizen is freely able to comply if they choose. The Public.Resource.Org case shows us this principle also extends to standards that are expressly or effectively necessary for compliance with a given law.

But when these standards are allowed to have patents intentionally embodied within them by private actors for their own profit, citizens find themselves unable to practically conform to the law without specialist support and a necessary private relationship with the patent holders. While some may have considered this to be a tolerable compromise when the goal of standards was merely interoperability, it is clearly an abridgment of fundamental rights to condition compliance with the law on identifying and negotiating a private licensing arrangement for patents, especially those embedded intentionally in standards.

Just as Regulation 1025/2012 will need updating to reflect the court ruling on availability of standards, so too should it be updated to require that harmonised standards will only be accepted from the ESBs if they are supplied on FRAND terms where all restrictions on use are waived by the contributors.

Follow @webmink@the.webm.ink to be informed of new posts. To discuss this post please reply from Mastodon etc. (search for the URL) & include @webmink@meshed.cloud as WriteFreely still doesn't display replies. More.

]]> https://the.webm.ink/patents-and-the-presumption-of-conformity Tue, 26 Nov 2024 15:23:52 +0000 SEPs Cut Both Ways https://the.webm.ink/seps-cut-both-ways <![CDATA[I just read a news story about how Chinese tech companies are threatening Europe by registering so many patents. Turns out it'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. The handles of three gigantic sword statues seen against a blue sky !--more-- I still meet people who think that implementing an "open standard" is something anyone can do freely. But it's unfortunately not so - the word "open" in standards is not used the same way as "open" 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. 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 "open" any standard created under a standards-body process that is theoretically equally open to all, which thus circumvents the anti-trust rules. 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 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. 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. 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's common for patent owners to drag their feet to disadvantage licensees. 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. There'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. --- Notes, Tags and Mentions #FRAND #RAND #SEP #Patents #SoftwarePatents #Standards #SEPD #OpenSource If the story is paywalled try a longer ladder for fair use. 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: Pocknell, Robert & 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 Lundell, Björn; Gamalielsson, Jonas & 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 Follow @webmink@the.webm.ink to be informed of new posts. To discuss this post please reply from Mastodon etc. (search for the URL) & include @webmink@meshed.cloud as WriteFreely still doesn't display replies. a href="/About"More/a.]]> I just read a news story about how Chinese tech companies are threatening Europe by registering so many patents. Turns out it'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.

The handles of three gigantic sword statues seen against a blue sky I still meet people who think that implementing an “open standard” is something anyone can do freely. But it's unfortunately not so – the word “open” in standards is not used the same way as “open” 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.

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 “open” any standard created under a standards-body process that is theoretically equally open to all, which thus circumvents the anti-trust rules.

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 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.

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.

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's common for patent owners to drag their feet to disadvantage licensees.

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.

There'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.

Notes, Tags and Mentions

  • #FRAND #RAND #SEP #Patents #SoftwarePatents #Standards #SEPD #OpenSource
  • If the story is paywalled try a longer ladder for fair use.
  • 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:
    • Pocknell, Robert & 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
    • Lundell, Björn; Gamalielsson, Jonas & 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

Follow @webmink@the.webm.ink to be informed of new posts. To discuss this post please reply from Mastodon etc. (search for the URL) & include @webmink@meshed.cloud as WriteFreely still doesn't display replies. More.

]]> https://the.webm.ink/seps-cut-both-ways Wed, 03 May 2023 10:28:46 +0100 CRA Compliance - Engaging Standards Bodies https://the.webm.ink/cra-compliance-engaging-standards-bodies <![CDATA[Update: This has now graduated to the OSI Blog. !--more-- One of the proposals in the Cyber Resilience Act (CRA) is that European standards bodies should develop suitable standards that help simplify conformance. Bert Hubert explains how this might work in his extensive CRA explainer. There's a crucial issue here for open source. EU policy experts say not to worry about CRA compliance because the EU standards bodies will streamline it. But the ESOs are corporate-controlled, patent-loving & expensive to engage. Shouldn't the EU address this if they want open source accommodated? A medieval window in Southampton's city walls has had a later structure built across it that obstructs the window, which itself partly obstructs an even earlier window In Europe, standards requests from the European Commission are handled by bodies which have been designated a European Standardisation Organisation (ESO) under EU law. There are only three of these; CEN, CENELEC and ETSI. None of these standards development organisations are accessible to open source projects per se. CEN and CENELEC are largely controlled by national standards bodies which in turn are dominated by national industries, while ETSI is a member organisation with high membership fees and largely secret proceedings (although laudably with free specifications) that is directly controlled by its members, predominantly from the telecoms industries but also including the European states. In addition, ETSI celebrates its role as a pioneer and proponent of FRAND licensing, which is fundamentally incompatible with open source communities. As with all de jure standards, participation in each of these standards bodies is expensive, both financially and in time, and engaging in their governance is beyond the scope of small players. Given this context, when the European Commission requests standards that will be applied for conformity assessment it's not clear how they will take into account the development workflow that applies to open source software. Like the European Commission itself (as I commented recently), Europe's standards bodies have no functional relationships with open source charities and do not consult them. It is very important to find ways to give a voice to the true community and not just its corporate members. As things currently stand open source will only be considered through the lens of its corporate uses. Since open source is a social movement with software artifacts for which the applications are diverse, paying heed only to the attributes of the software and the needs of the companies consuming it is an inadequate approach. You can't even proxy through small business, let alone multinationals and their lobbyists - many of them are unaware of how communities work and without community understanding, fundamental errors can be made. As a result, I believe whatever legislation arises from the CRA (and related instruments) needs to specify that standards bodies making related standards must include effective measures to consult and include the open source community. If this doesn't happen, as NLnet Labs explained, "The only alternative left available are the conformity assessment procedures that involve paying for third party process auditors." And open source developers definitely can't afford that. --- Tags & Mentions #CRA #Standards #OpenSource #FOSS #Policy#4thSector @berthubert@fosstodon.org @maarten@techpolicy.social [RP-DD]: https://papers.ssrn.com/sol3/papers.cfm?abstractid=4231645 Follow @webmink@the.webm.ink to be informed of new posts. To discuss this post please reply from Mastodon etc. (search for the URL) & include @webmink@meshed.cloud as WriteFreely still doesn't display replies. a href="/About"More/a.]]> Update: This has now graduated to the OSI Blog. One of the proposals in the Cyber Resilience Act (CRA) is that European standards bodies should develop suitable standards that help simplify conformance. Bert Hubert explains how this might work in his extensive CRA explainer.

There's a crucial issue here for open source. EU policy experts say not to worry about CRA compliance because the EU standards bodies will streamline it. But the ESOs are corporate-controlled, patent-loving & expensive to engage. Shouldn't the EU address this if they want open source accommodated?

A medieval window in Southampton's city walls has had a later structure built across it that obstructs the window, which itself partly obstructs an even earlier window

In Europe, standards requests from the European Commission are handled by bodies which have been designated a European Standardisation Organisation (ESO) under EU law. There are only three of these; CEN, CENELEC and ETSI. None of these standards development organisations are accessible to open source projects per se.

CEN and CENELEC are largely controlled by national standards bodies which in turn are dominated by national industries, while ETSI is a member organisation with high membership fees and largely secret proceedings (although laudably with free specifications) that is directly controlled by its members, predominantly from the telecoms industries but also including the European states. In addition, ETSI celebrates its role as a pioneer and proponent of FRAND licensing, which is fundamentally incompatible with open source communities. As with all de jure standards, participation in each of these standards bodies is expensive, both financially and in time, and engaging in their governance is beyond the scope of small players.

Given this context, when the European Commission requests standards that will be applied for conformity assessment it's not clear how they will take into account the development workflow that applies to open source software. Like the European Commission itself (as I commented recently), Europe's standards bodies have no functional relationships with open source charities and do not consult them.

It is very important to find ways to give a voice to the true community and not just its corporate members. As things currently stand open source will only be considered through the lens of its corporate uses. Since open source is a social movement with software artifacts for which the applications are diverse, paying heed only to the attributes of the software and the needs of the companies consuming it is an inadequate approach. You can't even proxy through small business, let alone multinationals and their lobbyists – many of them are unaware of how communities work and without community understanding, fundamental errors can be made.

As a result, I believe whatever legislation arises from the CRA (and related instruments) needs to specify that standards bodies making related standards must include effective measures to consult and include the open source community. If this doesn't happen, as NLnet Labs explained, “The only alternative left available are the conformity assessment procedures that involve paying for third party process auditors.” And open source developers definitely can't afford that.

Tags & Mentions

#CRA #Standards #OpenSource #FOSS #Policy#4thSector @bert_hubert@fosstodon.org @maarten@techpolicy.social

Follow @webmink@the.webm.ink to be informed of new posts. To discuss this post please reply from Mastodon etc. (search for the URL) & include @webmink@meshed.cloud as WriteFreely still doesn't display replies. More.

]]> https://the.webm.ink/cra-compliance-engaging-standards-bodies Fri, 24 Mar 2023 09:38:41 +0000 Exempting Open Source From SEPs https://the.webm.ink/exempting-open-source-from-seps <![CDATA[Update: Graduated to the OSI Blog. !--more-- 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 "open" standards is antithetical to open source practice. 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 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. 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. 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”). 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. By contrast, the implementation-led approach frequently arises in circumstances where recovery of R&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. The Commission'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. 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's Open Standards Requirement. [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 #SEP #Standards #SEPD Follow @webmink@the.webm.ink to be informed of new posts. To discuss this post please reply from Mastodon etc. (search for the URL) & include @webmink@meshed.cloud as WriteFreely still doesn't display replies. a href="/About"More/a.]]> Update: Graduated to the OSI Blog.

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 “open” standards is antithetical to open source practice.

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

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.

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.

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”).

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.

By contrast, the implementation-led approach frequently arises in circumstances where recovery of R&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.

The Commission'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.

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's Open Standards Requirement.

#SEP #Standards #SEPD

Follow @webmink@the.webm.ink to be informed of new posts. To discuss this post please reply from Mastodon etc. (search for the URL) & include @webmink@meshed.cloud as WriteFreely still doesn't display replies. More.

]]> https://the.webm.ink/exempting-open-source-from-seps Wed, 15 Feb 2023 08:59:18 +0000