Tag Archives: Standards

The Future Promise Of The Fediverse

There’s an old story about someone in the dark feeling the trunk of an elephant and believing it’s a snake because they can’t see the whole animal. It’s happening again, as people spooked from the Twitter crash try to feel their way around the Fediverse.

A beige room filled with connected globes made from translucent panels held in place by wires.

One of the benefits of the Fediverse is that I can use my preferred system to post things and you can follow and interact with any ActivityPub-compatible system you prefer. Your choice of, say, a photo-sharing platform doesn’t dictate that I have to sign up to the same site, or even to another photo sharing thing. It’s all powered by the ActivityPub standard – which is like RSS you can reply to. But there’s the potential to end the reign of monetized surveillance (AKA advertising) with a switch to user-owned applications.

No platform virality

If I were posting my photos to Instagram, to follow them you would have to sign up too (and since that’s Facebook-owned, submit to all their monetized identity harvesting). But if I post with PixelFed – an ActivityPub system tailored to posting photographs like on Instagram – you can follow from a compatible photo tool for sure. But you can also follow – and comment – from micro-blogging systems like Mastodon or Pleroma or from video-sharing systems like PeerTube or a blogging tool like Plume.

Yes, you have to join the Fediverse somewhere, but you can do it the way that’s comfortable on a platform that shares your values and still interact with people who made different choices, and once you’ve done it you can follow any feed regardless of the platform it’s from. It’s the end of platform virality and lock-in. It means every small app can benefit from a network effect previously only available to gatekeeper platforms.

This is the most important dimension of the Fediverse, and the one we need to develop. We need ActivityPub federated software tools of all kinds, cutting the link between my choices and your choices without also cutting our ability to interact with each other.
I never want to have to leave my social graph behind again.

Composable applications

This detachment goes further. I can segment my posting and use a more appropriate tool for specific content types and interaction styles. For example, I have been putting my travel photos on my new PixelFed server so that followers have the choice of following my micro-blogging feed on Mastodon, my photo feed on PixelFed or indeed both.

This means I don’t have to wait for my microblogging tool to get better support for posting photos; instead I can mix and match tools and build the ideal creative environment for me, and you’re not affected beyond needing to follow me in more than one place. Over time this will get fixed and I’ll be able to offer an aggregated subscription to all my feeds – it just needs someone to write a gadget to do it!

Of course, there’s much more to it than this. Since ActivityPub has two layers, a client-to-server layer and a server-to-server layer, there is great scope for wiring composable applications together so they collaborate better. And then there’s the privacy dimension – I especially like Christine Lemmer-Webber’s OCapPub ideas. I‘m sure we will see much innovation both in creating user capabilities and in managing infrastructure needs. Because pretty much everything in the Fediverse is open in every sense, there is plenty of scope for relays and clients to layer fresh capabilities upon the activity stream. It’s the UNIX philosophy revisited.

Open Source and standards done right

This is all powered by the dual merits of Open Source software and truly open standards. ActivityPub is a freely-available, royalty-free W3C standard. All the systems that manipulate it to date are Open Source software, which anyone can enjoy without asking permission first. Together that openness has fueled the wave of change triggered by the collapse of Twitter. But there is much more to it than that.

I’ll not tell you that calling the Fediverse “Mastodon” is a mistake (even if it is!) but I do recommend looking beyond the obvious similarities of Mastodon to Twitter and realize the phenomenon it is riding is not only bigger than a single piece of software, it’s bigger than a single category of software. Federation will get smarter, more secure and new categories of activity will be added. This is not so much an elephant in the dark as a whole zoo in the dark, and we’ve only touched the first few animals.

The Future Of Innovation Has Patent-Free Standards

It may come as a surprise to find that some supposedly “open“ standards – including those ratified by standards development organisations (SDOs) like ISO, CEN and ETSI – can’t be implemented without going cap-in-hand to the world’s largest companies to buy a licence. As I explained for OSI, it’s the result of a legacy approach to innovation from the days when it was only really about hardware.

As with any legal loophole, simply existing meant it was exploited and became the norm, even if it was initially temporary (“like income tax”). Once exploitation of a legal loophole becomes competitive, it becomes its own justification for the existence of the regulations (“look at the economic value of this segment”) and they become near impossible to remove – even when the original justification has ceased to need preferential protection.

So today we see a swathe of rich consumer electronics and telecoms companies, addicted to the revenue they get from licensing the patents (SEPs) they have embedded in “open” standards*, lobbying hard to ensure their value to the economy is recognised. They have much to lose from the loss of their special status, so invest much to protect it and to glorify it.

On the other hand, software companies have less to gain by the reformation of this anachronism – to the extent they have flirted with SEPs, maybe even a little to lose. Meanwhile, the new world of Open Source powered innovation lacks rich lobbyists due to its diffusion, and is accustomed to working round the obscenity of valuable standards being taxed by patent cartels. While the freedoms of Open Source mitigate to a degree, this means interoperability and interchangeability are being sacrificed on the altar of SEP protection.

It is not an ideological outlook that makes thoughtful Open Source advocates oppose patents in standards. It’s primarily pragmatic. Requiring a patent license to implement a standard implies that those implementing it must engage in private negotiation to get a license to proceed. That’s super-toxic to Open Source, whose mainspring is code owners giving advance, un-negotiated, equal permission to enjoy the software in any way – use, improve, share, monetise – all protected by a rights license reviewed and approved by OSI. So most projects avoid or work around SEP-encumbered standards and the ones that don’t are industry-specific.

OSI thus takes the position that standards destined to be implemented as Open Source must come with all the rights waived (and has done so for 15+ years). For some, that is already true; for others it is being actively resisted. If you want the crop of innovation you have to get the growing conditions right, and this new crop has different needs to the old hardware world and its long horizons. The future of innovation is open innovation, implemented as Open Source. Using anachronistic patent-centric metrics and regulations will chill that future. How about we don’t do that?

*Reusable Footnote: The word “open” is overloaded here.

(An edited version of this article appeared in the OpenUK survey report 2022)

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

Accommodating Open Source In Standards Processes

Holders of zero-tolerance positions on both sides of the divide need to realise that accommodating open source productively inside standards bodies is both viable and happening now.

A fine balance

You’ll recall that open source and open standards are orthogonal concepts where even the words they share (like “open”) are defined differently. That doesn’t mean they are mutually exclusive, nor that they are bad together – they can be cultivated well in the same garden. There is great value from accommodating the two orthogonal concepts so that neither is invalidated by non-mandatory elements of the other. When they combine, great value is unleashed.

Continue reading →

Growing Blueberries

Why accommodating open source at a standards body is like growing blueberries.

Fresh-from-the-bush blueberries are one of the good things of life. When I set up my home office about a decade ago, I had to install an underground conduit to supply essential services — power, water, network — and dug a deep trench all along the path that leads there. When I refilled the trench I decided to plant a blueberry hedge so looked into how to grow good blueberries.

Continue reading →

Chalk and Cheese

How similar are open source development and standards development? Not at all, and even the words they have in common mean different things in each.

It’s a traaap

It is often asserted that open source and open standards are in some way similar. For example, in the accompanying letter to a recent submission to the European Commission, a major European-based technology company that is very active is standardisation said:

Continue reading →

Policy Distractions

The open source network effect depends on unrestricted software freedoms. Licensing & business models that restrict those freedoms aren’t seeking the open source effect – or if they are they will fail – so calling a policy, product or company that does so “open source” is false advertising.

Woods Beautifully and Validly Concealed By Sunlit Trees

A focus solely on open source legal and licensing matters as they affect companies creates bad outcomes — for leaders and their advisers who are surprised by community and market reactions, and for developers who feel abused and betrayed by “open source companies” and “government initiatives” that actually put obstacles in their path rather than remove them.  While the minutiae of open source licensing and governance need to be understood and accommodated, it’s vital to never lose sight of the open source effect itself.

Continue reading →

FRAND And The Clash Of Industries

The largest forces in technology today – consumer-facing companies like Google and Facebook, business-facing companies like Salesforce, now even first-gen tech corporations like Microsoft and IBM – all increasingly depend on open source software. That means collaborative inter-company development of the software components and infrastructure technology these enterprises use for their business success. It’s enabled by the safe space created when they use their IP in a new way – to ensure an environment for collaboration where the four essential freedoms of software are guaranteed. Continue reading →

FRAND Is Not A Compliance Issue

The European Commission has been persuaded by lobbyists to change its position on standards to permit the use of FRAND license terms for patents applicable to technologies within those standards. This is a massive mistake that will harm innovation by chilling open source community engagement.

Continue reading →

FRAND Is Always Discriminatory

I participated in a study asking about the fairness, reasonableness and non-discriminatory nature of FRAND licensing in the context of licensing of patents in standards. I was surprised to find people there asserting there was no conflict between FRAND licensing and open source software. Here’s a simple explanation why that’s wrong.

Since patent licensing is by definition bilateral, and since open source communities that aren’t run by a single vendor are by definition multi-lateral, any standard which includes patents that require licensing discriminates against true multi-participant open source implementation. By definition, patent licensing as a precondition of implementation of a standard cannot ever be non-discriminatory. Even zero-fee licensing is discriminatory as it still requires implementers to seek permission, the antithesis of open source.