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.