Why Open Source should be exempt from Standard-Essential Patents

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.

The value and prosperity generated from Open Source arises from Open Source software licenses seamlessly and frictionlessly permitting anyone to use, modify, and redistribute the software for any purpose including monetization. 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 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 standardization. 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 harmonization of existing industry implementation (“implementation-led”).

The requirements-led approach leads some standards development organizations (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 monetization appears a compromise that in many cases can be proportionate to the delayed monetization 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 harmonize their standards strategy with their Open Source aspirations. In particular, standards organizations 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. We wrote to the consultation by the Commission last May to explain.

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.

This article first appeared on Webmink in Draft.

Image of Wreck Buoy by Simon Phipps

Mentions

  1. Simon Phipps Avatar
  2. daovotion Avatar
  3. Jure Repinc (Mastodon: @JRepin@mstdn.io) Avatar
  4. Jure Repinc :linux: :kde: Avatar
  5. Simon Phipps Avatar
  6. Stefane Fermigier Avatar
  7. Asta McCarthy Avatar
  8. Crell@phpc.social Avatar
  9. Anmol Vaid Avatar
  10. Oleg Nenashev ??? Avatar
  11. Oleg Nenashev ??? Avatar
  12. Vaibhav Tiwari Avatar
  13. Lukas Grossar Avatar
  14. sdem21 ?? ?? Avatar
  15. Betsy Waliszewski Avatar
  16. Matt "msw" Wilson Avatar
  17. sdem21 ?? ?? Avatar
  18. sdem21 ?? ?? Avatar
  19. Oleg Nenashev ??? Avatar
  20. zoobab "NO Software Patents" Avatar
  21. gilde Avatar
  22. Simon Phipps Avatar
  23. PublicLewdness Avatar
  24. Crell@phpc.social Avatar
  25. Matthias Sohn Avatar
  26. chrismckee Avatar
  27. Software, tecnología y negocios. Avatar
  28. Mekki MacAulay Avatar
  29. Bilal Khan ? Avatar
  30. Andrea Dell’Amico Avatar
  31. Rev. Lunar ?:anarchy:? Avatar
  32. Rev. Lunar ?:anarchy:? Avatar
  33. Rev. Lunar ?:anarchy:? Avatar
  34. Mikaël Barbero Avatar
  35. Josh Bruce Avatar
  36. Boris Avatar
  37. Len Avatar
  38. pchestek Avatar
  39. karadanvers@follow.darn.social Avatar
  40. Simon Phipps Avatar
  41. Nemo_bis ? Avatar
  42. Gerardo Lisboa Avatar
  43. Wikimedia Italia Avatar
  44. Simon Brooke Avatar
  45. Jure Repinc :linux: :kde: Avatar
  46. Jure Repinc (Mastodon: @JRepin@mstdn.io) Avatar
  47. Esther Payne ??????? Avatar
  48. Esther Payne ??????? Avatar
  49. Konstantin :veripawed: :veritrek: :rainbow_pride_potion: Avatar
  50. Koen Hufkens, PhD Avatar
  51. lasombra Avatar
  52. smallcircles (Humane Tech Now) Avatar
  53. sunflower ? Avatar
  54. Simon Phipps Avatar
  55. Stefane Fermigier Avatar
  56. Daniel Svindseth Avatar
  57. carlopiana Avatar
  58. CESAr Avatar
  59. Oblomov Avatar
  60. Dave Lane (FOSSDLE) Avatar
  61. AdamHurwitz.eth ? Avatar
  62. ] Rene Paul Mages [ No Software Patents‏ Avatar
  63. Guy Moise Schaub Avatar
  64. Simon Phipps Avatar
  65. Vincent Picavet Avatar
  66. Debian Türkiye Avatar
  67. julien ANCELIN Avatar
  68. dynfi Avatar
  69. Simon Phipps Avatar
  70. benny Vasquez Avatar
  71. AlmaLinux Avatar
  72. pchestek Avatar
  73. PublicLewdness Avatar

    Mentions

  • 💬 Jure Repinc (Mastodon: @JRepin@mstdn.io)
  • 💬 zoobab “NO Software Patents”
  • 💬 Jure Repinc (Mastodon: @JRepin@mstdn.io)
  • 💬 daovotion
  • 💬 Simon Phipps