Category Archives: Reusable Footnote

Briefly: FRAND Is Toxic To Collaboration

I’ve repeatedly heard lawyers arguing about whether Open Source licenses and FRAND terms are compatible. But ultimately it doesn’t matter, because the toxin remains whatever the answer – legal compatibility is the wrong lens. When developers come to an Open Source project, they need to find a level playing field, a uniform surface with no traps, a fully illuminated environment with no shadows. Without them, collaboration is compromised.

But the presence of a standard with embedded patents (standard-essential patents or SEPs) under so-called “Fair Reasonable and Non-Discriminatory” (FRAND) terms introduces inequality. Some developers believe they are unaffected, because their usage is purely personal or they are poorly advised. Others are unconcerned because their employer is part of a cross-licensing cartel with the patent holder. But the remainder must each go privately and under NDA to the patent holder(s) and negotiate individual terms to use the patents. They then can’t publicly share the exact arrangements — or possibly even the existence of the arrangement — because of the NDA. Individual terms and secret rights are the opposite of open collaboration and destroy trust.

It’s this inequality that is toxic, not the precise compliance with the legal terms in the Open Source license. Whether great legal minds find the presence of SEPs compatible or incompatible with the license, the inequality of the participants in the community is what makes it avoid SEP-laden standards. That’s why the Open Standards Requirement for Software says any SEPs have to be waived or freely licensed in advance – to restore the level playing field. It’s not because of ideology or an anti-patent agenda or an attempt at market manipulation. The open source network effect underlying the market depends on it.

So learned dissertations about the compatibility of FRAND terms with Open Source licenses may be academically interesting, but they aren’t relevant. All SEPs in standards intended to be implemented as Open Source must be waived or freely pre-licensed, or the standard won’t be implemented by open communities

Briefly: On Overloading “Open”

The word “open” is overloaded. In the domain of standardisers, a process that permits any company to participate (even if doing so is punitively expensive) is considered “open” and the resulting deliverable is considered an “open standard” even if you have to pay to read it and negotiate patent licenses to implement it.

In the domain of software and APIs, it is the deliverable that has to be open – usable for any purpose without negotiation with its rights-holders. This overloading of the term is the origin of many of today’s issues, since – properly understood – Open Source and open standards are conceptually orthogonal. 

This variation in how “open” is understood within linked and overlapping domains is why “Open Source” is treated as a term of art with a consensually-agreed meaning in the domain of technology – a noun – and not as a descriptive adverbial phrase. If you see a hyphen in the middle of open-source it’s about military/political intelligence and not technology.