Chapter 1: What Is a Standard and Why Should You Care?

Standards are everywhere. If your kid has a bicycle helmet, flip it over. You'll see certification marks and references to safety standards that define how much impact the foam has to absorb. Your car's crumple zones, the electrical outlet on the wall, the USB port on your laptop — all built to standards. Most of the time, nobody thinks about this. That's the point.

The standards we deal with in the technology space work the same way, just applied to software. They describe how two systems connect and communicate. Think of it as a software equivalent of a power outlet. The standard defines the shape of the plug, the voltage, the amperage. It doesn't care what you plug into it.

1.1 Standards Come in Multiple Flavors

Not all standards are the same, and it helps to separate them into rough categories.

Measurement and construction standards are the oldest category, and they're worth naming first because they shape how everyone else thinks about the word "standard." Weights and measures — the meter, the kilogram (the international prototype kilogram in Paris famously appeared to lose tens of micrograms of mass relative to its sister copies over the course of a century, which is part of what eventually drove the 2019 redefinition of the SI base units in terms of physical constants), the volt, the kilowatt-hour — sit underneath essentially every modern transaction. A pound of coffee means the same thing in Seattle and São Paulo because someone, somewhere, agreed on a definition and built an institutional apparatus to enforce it. Building codes are the close cousin: how thick a load-bearing wall has to be, how far apart studs can sit, what gauge of wire runs through which conduit. These standards rarely come up directly in technology practice, but they're the cultural template — when a non-specialist hears "standard," this is usually what they're picturing. It's worth knowing they're there because, while this book focuses on the lessons drawn from interoperability standards, all of these flavors share the same foundation: an agreed-upon definition, an institutional process for maintaining it, and a community that relies on it.

Health and safety standards are the ones most people think of next. Bicycle helmets. Bumper crash ratings. Factory safety requirements. These carry regulatory weight and often end up embedded in law. We won't spend much time on them, but one thing worth noting: these standards become tools of industrial policy. American automakers push for worldwide adoption of European bumper safety standards because it levels the playing field. If Toyota has to build one bumper design that meets the European requirement, they're competing on even terms everywhere. A local manufacturer in Brazil, say, can sell a cheaper car because they only need to meet a lower national standard. Toyota loses on cost. Harmonized standards fix that.

Management and process standards are the ones you get audited against. ISO 9000 is the canonical example — it's one of the most widely adopted standards in the world. These standards don't tell you exactly what to do. They tell you what capabilities and processes you need to have, and then you describe how you meet them.

Here's the way I explain it. Imagine you have two mountains and you need to move goods from the top of one to the top of the other. The standard says you need a mechanism to do that. If you're a small operation, maybe your plan is: we hike down and hike back up once a month. Fine. Maybe you built a bridge. Maybe you use a helicopter. The standard doesn't care how — it just requires that you have a plan, you can describe it, and someone can evaluate whether it's reasonable.

The one closest to our world is OpenChain, which is an open source compliance standard. It doesn't prescribe how to run a compliance program. It says a compliance program should have certain elements — tell us what yours are. You self-certify. If someone asks, you hand over your artifacts and they decide if they're comfortable.

These management standards matter more than you'd expect, because governments reference them. A lot of times a government procurement policy will say "you must comply with ISO 1234" for data center operations, and what people don't always realize is that we can help write ISO 1234 to make sure it reflects our practices.

Management system standards also do real work as soft law — the layer of obligation that operates alongside formal regulation rather than through it. Three functions stand out. First, regulatory compliance: a regulator can require "implement an ISO/IEC 27001 information security management system" instead of writing the controls itself, which is faster, more durable, and easier to update than primary regulation. Second, efficient contracting: when both sides of a deal point to the same management standard, the diligence, the audit rights, and the remediation obligations all collapse into a known quantity instead of a bespoke negotiation. Third, trust at the scale of the economy: when millions of transactions depend on counterparties handling data, code, or supply chains responsibly, no individual contract can verify that — but a recognized management standard, with third-party certification behind it, can. That's how trust gets manufactured at scale, and it's why these standards end up mattering far more than their unglamorous reputation suggests.

Interoperability standards are where I've spent most of my career. These describe how two pieces of software interact — the format, the protocol, the interface — without prescribing how either side does the actual work.

Here's a simple example. Say you have a number-sorting standard. One side takes a series of numbers, separates them by commas, ends with a semicolon, and passes them to the other side. The receiving side sorts them lowest to highest, formats the result, and sends it back. The standard describes the communication format. It doesn't describe the sorting algorithm. You might optimize for speed. Someone else optimizes for accuracy with prime numbers. Both implementations comply with the standard as long as the inputs and outputs match.

This distinction matters enormously for patent purposes, and we'll get into that. But the core concept is that a standard describes the interface, not the implementation. There are exceptions — encryption algorithms are one, where you can't describe the standard in English alone and you need the actual algorithm — but those are outliers.

One framing point worth flagging early, because it shapes a lot of downstream confusion: an interoperability standard sets the floor for innovation and product differentiation, not the ceiling. The standard tells you the minimum you have to do to interoperate. It says nothing about what you're allowed to build on top.

This gets misunderstood often, especially in procurement and regulation. There are too many examples of policies that treat the mandated standard as the universe of permitted behavior — products that conform are "legal" or "allowed," anything else is "out of policy" or "non-compliant." That framing fails for two reasons.

First, it fails operationally. Organizations don't want their roadmaps capped by a procurement clause, so they immediately negotiate exceptions. The exceptions multiply, and within a few years the policy is more carve-out than rule. The standard ends up doing none of the work it was supposed to do.

Second, it fails economically. No economy has succeeded by using standards to set the maximum allowed behavior. The Soviet Union tried it. China tried it through the 1990s and into the 2000s. In both cases, standards-as-ceiling produced exactly the stagnation you'd expect. China's current "socialist market economy" approach is instructive: standards are still central, but they're used to set technical regulation based on flexible behavioral requirements rather than fixed implementations. The state still gets to define what "good" looks like, but innovation above the floor is allowed — encouraged, even — because the alternative doesn't work.

The lesson generalizes. When you see a procurement policy, a regulation, or a contract clause that treats an interoperability standard as a ceiling, that's a drafting error worth flagging. The standard is the common language. What gets said in it is up to the speaker.

1.2 Why Standards Matter

Standards create markets. That's the simplest version of it.

Consider the consumer electronics industry in the early 2000s. When DVD players first came out, they could cost four, five, six, seven hundred dollars. Once the market matured and prices dropped, the entire upgrade cycle was done. Consumers had their players, their TVs were fine, and nobody was buying new equipment. The industry needed the next generation to juice the cycle again. That next generation — Blu-ray — was built on standards. Without agreed-upon standards for the disc format, the compression codec, the content protection, and the display interface, you don't get an ecosystem. You get fragmented, incompatible products that consumers won't buy.

Standards also solve coordination problems. The Japanese power grid is a surprisingly good example. In the 1890s, Tokyo's electric company imported 50Hz generators from AEG in Germany, while Osaka's imported 60Hz generators from General Electric in the United States. Nobody coordinated, and both regions built out their grids independently. The voltage is the same across Japan, but the frequency difference means the two grids can't directly interconnect. Your devices can adapt — most modern electronics handle both — but the infrastructure itself cannot. When the Fukushima earthquake hit in 2011, Japan couldn't route power from the unaffected western grid to the eastern grid because the two systems were fundamentally incompatible. One standard, adopted a century earlier, would have prevented that.

The natural follow-up question is who should do the coordinating, and how. The European experience with two roughly contemporaneous mandates is instructive, because the Commission ran the same playbook twice in the same era and got opposite results.

GSM is the success story everyone cites. In the late 1980s, the European Commission — working first through CEPT and then through the newly formed ETSI — pushed a single digital cellular standard onto the European market. The mandate worked. By the mid-1990s GSM was the dominant European standard, by 2000 it was the dominant global standard, and the European cellular industry — Nokia, Ericsson, the carriers — was for a decade or so the most important player in mobile. The centralized model picked the right horse, locked it in fast, and built an industry around it.

HD-MAC is the failure story almost no one remembers. In the same period, with the same instinct, the Commission mandated a European HDTV standard for direct-broadcast satellite — analog, hybrid, designed by Philips, Thomson, Bosch, and Nokia under the Eureka 95 project, and backed by two directives (86/529/EEC and 92/38/EEC) and an Action Plan worth several billion ECU. Two things went wrong. First, the market routed around the mandate: Sky launched on the medium-power Astra satellites, which weren't covered by the directive, broadcast in PAL to the TVs consumers already owned, and absorbed the licensed competitor (BSB) within two years. Second, the technology bet was wrong: by 1993 it was clear that digital HDTV (the work that became ATSC in the US) was going to overtake analog HDTV entirely. The Commission abandoned the mandate that year and pivoted to DVB — voluntary, industry-led, digital, and modular — which went on to become the dominant digital broadcasting family worldwide.

The honest lesson isn't that mandates work or that they don't. It's that mandates work when the technology call happens to be right, and they fail catastrophically when it isn't — and the same property that makes them powerful (lock-in, no exit) is what makes the failure mode so costly. The decentralized model is messier in the short run and almost always slower to coordinate. It also doesn't have the catastrophic-failure mode, because no one is forced onto the wrong horse. Europe got HDTV right the second time around by going decentralized and digital. The pattern is worth remembering whenever someone cites GSM as proof that mandates work.

And standards carry legal and trade significance. Under WTO rules, international standards receive preferential treatment over national ones. The idea is that if we want telephone systems to work worldwide, everyone should adopt international telephone standards rather than national ones. Countries are strongly encouraged to use international standards unless there's a good reason not to. This gives international standards real power — they aren't just technical documents. They're trade instruments.

That said, the technology sector is a bit different from aerospace or manufacturing, where nearly every screw is an international standard. We move too fast. Government procurement policies don't constrain us the way they constrain the aircraft industry. Something like HTTP isn't an international standard in the formal sense, but no government is going to refuse to use it. The distinction between formal international standards and widely-adopted industry standards matters less in our world than in others. But it's still worth understanding, because when it does matter, it matters a lot.

Market-making, coordination, and trade are the headline reasons standards matter. They aren't the only ones. Several other functions show up often enough that it's worth naming them.

Trust that enables efficient contracting and diffusion. A recognized standard, especially one with third-party certification behind it, is a substitute for bespoke diligence. Two parties don't have to negotiate from scratch about what good security looks like, what good open source compliance looks like, or what good environmental practice looks like — they can point at the standard and move on. That cuts transaction costs and, just as importantly, accelerates diffusion. People adopt a technology faster when they don't have to verify it themselves.

Market access — both barrier and enabler. A standard that aligns with how a market already operates lowers the cost of entry. A standard that doesn't can become a barrier, sometimes deliberately. Regional standards are sometimes designed to favor incumbents or local industry, and the line between "legitimate technical requirement" and "non-tariff trade barrier" is blurrier than people assume. The flip side is that adopting a widely-recognized international standard is often the fastest way for a new entrant to credentialize into a market it doesn't yet have relationships in.

Consumer protection. Some standards exist to set the floor on what consumers are entitled to assume — about safety, accessibility, data handling, privacy, or product behavior. The point isn't to prescribe how a product is built. The point is to ensure that when something is sold as compliant, the consumer can rely on what that means.

Technical criteria to demonstrate conformity to new laws. As regulation moves into areas like AI, cybersecurity, and data protection, regulators increasingly need technical specificity that statutes and rules can't easily provide. Standards fill that gap. The EU AI Act, for example, leans heavily on harmonized standards to translate broad legal requirements into testable technical criteria. The standard becomes the operational definition of compliance — which makes the people who write the standard quietly very influential.

These functions overlap with each other, and with the soft-law role of management standards discussed earlier. The point isn't to draw clean lines. It's to recognize that "standards create markets" is the headline, not the whole story.

1.3 The Organizational Landscape

If you use the wrong terminology in a room full of standards professionals, you lose credibility immediately. A quick map.

Big-S Standards come from international organizations: ISO, IEC, and ITU (specifically ITU-T and ITU-R). Standards professionals will tell you these are the only "real" standards. Everything else is a small-s standard — technically a standard, but not a formal international one.

The distinction is not purely semantic. A Big-S international standard carries treaty-level obligations, government procurement preferences, and regulatory weight. A small-s standard from W3C or OASIS doesn't have that by default — but it can. A consortium spec can run through the PAS (Publicly Available Specification) process and come out the other side with an ISO stamp.

De jure standards are those that some official body has blessed. A de facto standard is something like the Win32 API — it became a standard by market dominance, not by process.

Below the international level you'll encounter national standards bodies (ANSI in the U.S.), regional European bodies (CEN, CENELEC, ETSI — backed by considerably more government involvement than anything you see in the U.S.), and a large ecosystem of industry consortia and foundations where most technology standardization actually happens. Chapter 2 walks through each category in detail. The point for now is just that the category of organization shapes everything downstream: governance rules, IPR defaults, confidentiality expectations, and the route to government adoption.

1.4 Where the Work Gets Done

Day to day, most of the standards work that matters to technology practitioners happens in industry consortia and foundations — IETF, W3C, OASIS, the Linux Foundation, the Joint Development Foundation, and dozens of smaller bodies. These are the workhorses, and Chapter 2 covers them in depth.

Here's an analogy that's worth carrying through the rest of the book. Think of a standards organization as a warehouse.

The walls, floor, and roof are the legal framework — the bylaws, the IPR policy, the antitrust guidelines, the membership terms. They define the building. People bring buckets of ideas in through the door; those are contributions. Inside, there are tables where experts gather and the buckets get emptied out and the contents are debated. Those tables are the working groups. Some people stand in the room without bringing buckets — they listen, they react, they shape the conversation without contributing material themselves. Those are participants. When the work is done, the result gets stacked on the loading dock at the back of the warehouse. Implementers walk up, take a copy, and go build something with it.

The roles aren't exclusive, and forgetting that is a common source of confusion. A contributor is usually also a participant, and is often an implementer of the spec they helped write. A participant who never contributed material can still go pick something up off the loading dock and build with it. And the people who walk up to the loading dock — the implementers — generally aren't contributors or participants at all. Most implementers of any successful standard never set foot inside the warehouse. That's the whole point of having a loading dock.

Four roles, three groups of rights. Contributors have rights in what they put into the bucket. Participants have rights to be in the room and to be heard. Implementers have rights in what they pick up off the dock. The whole job of a standards organization — the bylaws, the IPR policy, the governance — is to keep those three sets of rights in balance. Tilt too far toward contributors and you get a standard nobody can implement. Tilt too far toward implementers and nobody contributes. Tilt too far toward participants and the work doesn't ship. Most of the choices we'll work through in the rest of this book — patent policy, scope, exclusions, governance, voting, copyright — are choices about where on that triangle a particular organization wants to sit.

One more thing worth flagging up front, because it shapes how you should think about every battle inside the warehouse: just because you win the standards vote doesn't mean people will implement the standard. Most interoperability standards are voluntary. There is no regulator forcing anyone to walk up to the loading dock. The implementers come — or don't — based on whether the spec actually solves a problem they have, whether they trust the process that produced it, and whether the people whose code they need to interoperate with are also going to ship it. If you push a standard through to publication by out-voting the people whose buy-in you actually needed, you can win the battle and lose the war. The loading dock stays empty. This is why so much of the practitioner's job is consensus-building during development rather than vote-counting at the end. The vote is the receipt; the consensus is the product.

One durable pattern to internalize before we move on: as soon as a standards organization becomes an incorporated entity with staff, it develops its own agenda. That may or may not be a problem, but it is always a factor. If all you need is a lightweight home for some specs, you want to understand whether the organization's institutional interests align with yours. Organizations behave like organizations, not like neutral hosts.

1.5 Standards and Open Source: The Convergence

This is the trend that changed how we think about all of this.

For most of its history, the standards world and the open source world operated in parallel and didn't interact much. Standards had their formal processes, their patent policies, their governance structures. Open source had licenses, contributor agreements, and community-driven development. The IETF's principle of "rough consensus and running code" bridged the two cultures early — IETF standards development often relied on open source implementations as proof of concept — but outside of IETF, the two worlds were largely separate.

Then they started doing the same thing.

The HTML5 story is the clearest example. HTML4 was a W3C standard. When it came time for the next version, W3C's staff believed the future was the "semantic web" — markup that described not just layout but meaning, making it easier for machines to understand web content. Academically interesting. But a group of browser vendors — Apple, Mozilla, and Opera — just wanted a better markup language. In 2004, they formed the WHATWG (Web Hypertext Application Technology Working Group), forked HTML, and started iterating on it as a living standard. Google and Microsoft joined later. Meanwhile, W3C's own effort — XHTML 2.0 — went nowhere.

The result is a strange arrangement that persists today: the actual HTML work happens at WHATWG, but it gets published through W3C so W3C still looks like the steward. The crown jewel walked out the door, and the institution had to adapt.

This matters because it demonstrates something fundamental: if people don't like what a standards body is doing, they will fork the work. It's harder than in open source, and the ecosystem isn't designed for it, but it happens. And increasingly, the fork destination is an open source project rather than another standards body.

At Microsoft, we saw this convergence coming. We had always had a separate standards team and open source team. The two groups were sizable and operated independently, with different cultures and different risk profiles.

Eventually, we combined them. The logic was straightforward: open source was increasingly being used in place of standards. It's a different kind of plug fitting into the same outlet. If we wanted to advise our product teams on how to do interoperability — which is ultimately what both standards and open source solve — we needed to be able to look at the full picture and recommend the right tool for the situation. Sometimes that's a formal standard. Sometimes it's an open source project. Sometimes it's both.

That convergence is now the norm across the industry. The Joint Development Foundation supports both standards and open source governance. Organizations like the Linux Foundation host both traditional specifications and open source projects. The line between "standard" and "widely-adopted open source project" has blurred to the point where the distinction is often more about process and IP terms than about the output itself.

For attorneys advising on these engagements, this means you need to understand both worlds. A standards patent policy and an open source contributor license agreement are solving related but different problems — and they cover different things. An open source license covers the specific code (or text) that contributors submit. It does not cover the specification as a whole. A standards patent commitment covers necessary claims across the entire specification regardless of who contributed what. That distinction becomes critical when someone releases a "spec" under an open source license and treats that as patent coverage; it isn't. Chapter 5 develops this point in depth. For now, the foundation to build from is this: standards and open source are two paths to the same destination — interoperability — but they reach it through different legal machinery. Know both.

1.6 Key Terminology Quick Reference

Before we move on, here's the shorthand you'll encounter throughout this book.

Term	Meaning
SDO	Standards Development Organization — broad term covering most standards bodies
SSO	Standards Setting Organization — sometimes used for the "big" international bodies specifically
Consortium	Usually a smaller, often contractually based collaboration; may or may not be incorporated
Foundation	Generally an incorporated entity (often 501(c)(6)) that hosts standards or open source work
SIG	Special Interest Group — a small, focused collaboration; the term has fallen out of favor
Big-S Standard	A standard from an international body (ISO, IEC, ITU)
Small-s standard	An industry standard from a consortium or foundation (W3C, OASIS, IETF, etc.)
De jure	A standard blessed by an official body through a formal process
De facto	A standard by market adoption, not formal process (e.g., Win32 API)
PAS	Publicly Available Specification — a process for submitting consortium specs to ISO/IEC for international standardization
ANSI	American National Standards Institute — accredits U.S. standards bodies
IPR Policy	Intellectual Property Rights Policy — the patent and copyright rules governing a standards body; the subject of most of this book

Use the right terms. Standards professionals notice when you don't.