Chapter 5: Open Source and Standards: The Convergence

Standards and open source started as separate worlds with separate cultures, separate legal frameworks, and separate communities. Over the past two decades, they've converged to the point where the line between them is often invisible. A specification developed through a standards process may be implemented as an open source project. An open source project may become the de facto standard. And increasingly, the same organization hosts both — with the same participants, the same governance challenges, and the same IP questions.

The convergence isn't an accident, and it's worth naming why. Standards and open source are both, fundamentally, structured collaboration among parties who don't fully trust each other and don't share interests in any deep way. Both rely on a layer of norms and practices — voting rules, contribution mechanics, IPR commitments, codes of conduct, review processes — that exist to make the collaboration possible at all. And in both, the essential ingredient is a creative tension between self-interest and collective benefit. Participants show up because contributing to the common artifact serves their own ends; the artifact is useful because no one participant can capture it. When that tension is in balance, the system produces things no participant could have built alone. When it isn't — when self-interest dominates and the work tilts toward one party, or when collective sentiment dominates and the work stops serving anyone in particular — the collaboration breaks down. Most of the legal machinery in both worlds is, at root, about keeping that tension productive.

This chapter explores that convergence: where the two cultures differ, where they overlap, and what practitioners need to understand to advise effectively in a world where the answer to "is this a standard or an open source project?" is increasingly "yes."

One caveat up front, because it's the single most common mistake counsel see in this area: an open source license is not a substitute for a standards patent commitment. An open source license (and any accompanying contributor patent grant) covers the specific code or text that contributors submit. It does not cover the specification as a whole, and it does not cover independent implementations by parties who read the spec and build their own version. A standards patent commitment covers necessary claims across the entire specification regardless of who contributed what. That is a fundamentally different scope of protection. Projects that release a "spec" under Apache 2.0, MIT, or Creative Commons and treat that as patent coverage are one bad disclosure away from a nasty surprise. Chapter 10 works through a live example. The rest of this chapter assumes that distinction and builds on it.

5.1 Two Cultures Colliding

The Standards Mindset vs. the Open Source Mindset

Standards development and open source development solve related problems but come from different traditions and operate with different assumptions.

Standards are rooted in antitrust law. A group of competitors comes together, agrees on a common approach, and publishes a specification that anyone can implement. The process emphasizes due process, balance, consensus, and the right to appeal. The output is a document — a specification — that describes what conforming implementations must do. The IP framework is built around patent commitments to that document.

Open source is rooted in copyright. An individual or group publishes code under a license that grants broad rights to use, modify, and redistribute. The process varies widely — from benevolent dictator models to formal governance structures — but it centers on contribution, review, and the accumulation of working code. The IP framework is built around copyright licenses and, in some cases, contributor license agreements.

These different foundations create different instincts. Standards professionals think in terms of specifications, conformance, and patent commitments. Open source professionals think in terms of code, licenses, and community governance. Standards professionals worry about scope creep and patent exposure. Open source professionals worry about license compatibility and maintainer burnout.

When the two communities work together — which they increasingly must — these different instincts can create friction. A standards professional may insist on formal patent commitments before work begins. An open source developer may view that as unnecessary overhead that slows development. An open source community may want to iterate quickly and publish frequently. A standards professional may insist on review periods, public comment, and formal approval processes.

Neither instinct is wrong. They reflect different risk models. The practitioner's job is to understand both and find structures that satisfy the requirements of each.

How the Cultures Differ in Practice

The cultural differences go beyond legal frameworks. They show up in how meetings are run, how decisions are made, and what counts as progress.

In standards, progress is measured by the maturity of the document. Working draft. Committee draft. Public review draft. Final specification. Each stage has formal criteria and usually a vote or consensus call. The document is the deliverable.

In open source, progress is measured by the quality of the code. Does it compile? Does it pass tests? Has it been reviewed? Has it been merged? The code is the deliverable. Documentation is important but secondary — and often written after the code, not before.

In standards, influence comes from organizational affiliation and formal roles (chair, editor, voting member). In open source, influence comes from contribution — the people who write the most code, review the most pull requests, and respond to the most issues earn the most influence, regardless of who employs them.

In standards, confidentiality during development is common. Draft specs are often restricted to members. In open source, development happens in public by default. The code is visible. The discussions are visible. The review process is visible.

These differences create practical challenges when the same project tries to operate in both modes. An engineer who's comfortable with open source workflows may find the standards review process painfully slow. A standards professional who's used to member-only access may be uncomfortable with everything happening in a public GitHub repository.

Code as Specification

The traditional model is clear: the standard is a document, and the code is an implementation of that document. They're separate artifacts governed by separate legal frameworks.

That model is breaking down. In an increasing number of cases, the code is the specification. The open source project is the canonical reference for how the technology works. There may be documentation — API references, protocol descriptions, developer guides — but the authoritative source is the codebase itself.

This creates IP complications. A standards patent commitment covers the specification — the document that describes what implementations must do. If there is no document — only code — what does the patent commitment cover? An open source license covers the specific code. It doesn't cover independent implementations by parties who read the code and build their own version. That difference is exactly what matters when someone independently implements a protocol described only by open source code.

This is the distinction discussed in Chapter 10's analysis of open source licenses applied to specifications. It matters here because as more "standards" are developed code-first, more implementations exist without the patent protection that a traditional standards process would provide.

When Open Source Replaces Standards

In some cases, open source doesn't just complement standards — it replaces them entirely. The technology becomes ubiquitous not because it was standardized through a formal process but because the open source implementation was so dominant that alternatives became impractical.

Chromium is a current example. The web standards that govern how browsers work are formally developed at W3C and WHATWG. But the dominant open source browser engine — Chromium, which powers Chrome, Edge, Opera, Brave, and others — is the practical arbiter of what the web actually is. If a website works in Chromium, it works for the vast majority of users. If it doesn't, the website changes, not the engine. The formal standard describes the ideal. The dominant implementation determines the reality.

This pattern creates a different kind of lock-in than proprietary formats. It's not vendor lock-in in the traditional sense — the code is open, anyone can fork it, and the licenses allow free use. But when a single implementation is so dominant that it defines the platform, the distinction between "open source" and "de facto standard" becomes academic. And the governance of that implementation — who accepts pull requests, who sets the roadmap, who decides what goes in and what stays out — becomes the governance of the standard, whether or not anyone calls it that.

For practitioners, this means that advising on "standards" sometimes means advising on dominant open source projects. The IP framework is different (code licenses rather than patent commitments). The governance is different (maintainer decisions rather than consensus votes). The risk profile is different (fork risk rather than patent assertion risk). But the strategic questions — who controls the technology, who benefits from adoption, who bears the cost of change — are the same.

Sometimes the line is difficult to draw. Linux is code — an open source project governed by maintainers under the GPL. But Linux has very stable APIs that effectively function as standards. Applications are written to those APIs. Entire ecosystems depend on their stability. Nobody went through a formal standards process to define them, but they carry the same practical weight as any published specification. Is the Linux kernel API an open source project or a de facto standard? The honest answer is both — and the distinction matters less than understanding what your client is building to and what governs it.

5.2 Open Source as Competitive Strategy in Standards

Reference Implementations in Open Source

As discussed in Chapter 13, reference implementations were traditionally created by standards bodies to verify that the specification could be implemented. They were not intended for production use.

The shift toward open source reference implementations changes the dynamic. When the reference implementation is an open source project intended for production deployment, it becomes the path of least resistance for adoption. Why implement the spec from scratch when you can use the existing, tested, production-ready code?

This creates a powerful competitive dynamic. The company or community that controls the reference implementation has outsized influence on adoption — because most implementers will use their code rather than building their own. If the open source implementation becomes dominant, it becomes the de facto standard regardless of what the specification document says.

The WHATWG/W3C HTML5 Fork

The HTML5 story, discussed in Chapter 1, is the canonical example of open source and standards convergence. When W3C's direction for the web diverged from what browser vendors wanted, Apple, Mozilla, and Opera formed WHATWG and forked the HTML spec. Google and Microsoft joined later. The actual HTML development happens at WHATWG; W3C publishes it.

The lesson isn't just about organizational politics. It's about the power of implementation. WHATWG succeeded because its members controlled the browsers. They could implement their version of the spec directly. W3C's version — without browser implementation — was academic. The implementers determined the standard, not the standards body.

This pattern repeats across the industry. When the people who implement the technology are the same people who develop the specification — or when a dominant open source implementation exists — the formal standards process becomes a ratification of what the code already does, not a design exercise.

5.3 Hybrid Models

Community Specification License

The Community Specification License, discussed in Chapter 9, represents one approach to bridging the gap. It applies standards-style IP terms — patent commitments, exclusion mechanisms, contribution-triggered licensing — to work done in Git repositories using open source-style workflows.

The CSL acknowledges that modern specification development often looks more like open source development than traditional standards work. Small teams iterate on a spec in a repo, accept contributions via pull requests, and publish when ready. The CSL provides the patent clarity that open source licenses don't, without requiring the organizational overhead of a formal standards body.

Open Source Foundations as Standards Homes

The Linux Foundation, Eclipse Foundation, Apache Foundation, and others increasingly host both open source projects and standards initiatives. The organizational infrastructure — governance frameworks, IP policies, operational support — serves both purposes.

This co-location is natural. The communities overlap. The governance challenges are similar. And having both the spec and the code under the same organizational umbrella simplifies the IP relationship between them.

But co-location creates its own challenges. Open source governance (meritocratic, contribution-based, often informal) and standards governance (due process-based, consensus-driven, often formal) don't always coexist easily. A project that tries to operate under both models simultaneously can end up satisfying neither — too slow for the open source community, too informal for the standards community.

The organizations that handle this best are the ones that clearly separate the two functions — spec development under standards governance with appropriate patent policies, code development under open source governance with appropriate licenses — while ensuring the two tracks are coordinated. JDF's model, where the spec is governed by standards IP terms and the code is governed by an open source license, is one approach that works.

The key design question is institutional. Does the foundation treat the spec as an appendage of the code project? Or does it treat the spec as a first-class artifact with its own governance track? Organizations that default to open source governance for everything tend to produce specs with inadequate patent coverage. Organizations that default to standards governance for everything tend to produce code with processes too heavy for developer communities. The goal is to match the governance model to the artifact.

The Convergence in Practice: What It Looks Like Today

In practice, the convergence takes several common forms:

Spec-first with open source reference implementation. The traditional model, updated. A working group develops a specification through a standards process with patent commitments. An open source implementation is developed alongside — sometimes by the same people, sometimes by a separate community. The spec is authoritative; the code validates it. This model is used by many JDF projects and OASIS technical committees.

Code-first with spec documentation. An open source project develops a technology, gains adoption, and then documents it as a specification — either for interoperability (so others can build independent implementations) or for formalization (to submit through a PAS process for international recognition). The code is authoritative; the spec describes it. This is increasingly common for API definitions and protocol work.

Dual-track parallel development. The spec and the code are developed simultaneously by overlapping teams. Neither is strictly authoritative — they inform each other iteratively. This is the hardest model to manage but can produce the best results when the coordination is deliberate.

Open source as de facto standard with no spec. The code is the standard. There is no separate specification document. Implementers who want to interoperate read the code, reverse-engineer the behavior, or use the code directly. This is functionally what happens with Chromium for web rendering, and it's what the Crystal Ball chapter (Chapter 17) suggests may become more common with AI-driven interoperability.

AI and the New Frontier

AI is accelerating the convergence. The Agentic AI Foundation at the Linux Foundation, Google's Agent-to-Agent Protocol, and similar initiatives are developing interoperability specifications for AI systems. Some use traditional standards approaches. Others use open source approaches. Most use some hybrid.

As discussed in Chapter 17, the question of which approach is appropriate depends on the artifact. Protocol specifications benefit from standards-style patent commitments. Code benefits from open source licenses. Model artifacts, training data documentation, and evaluation frameworks don't fit neatly into either category.

This is the frontier for standards and open source convergence. The frameworks discussed in this book — patent policies, governance structures, non-assert agreements, the Community Specification License — provide the tools. Adapting them to new types of artifacts is the work ahead.

5.4 Practical Considerations for Attorneys

License Selection for Spec-Adjacent Code

When choosing a license for code that implements or accompanies a specification, the interaction between the open source license and the standards patent policy matters.

Permissive licenses (Apache 2.0, MIT) are most commonly used alongside standards work. Apache 2.0 includes an explicit patent grant tied to contributions, which provides some patent coverage — though narrower than a standards patent commitment. MIT includes no explicit patent grant at all.

Copyleft licenses (GPL, LGPL) are rarely used in standards-adjacent contexts. The copyleft obligation to share modifications can conflict with the proprietary implementation model that many standards participants rely on. In practice, copyleft licenses are essentially never used by standards bodies for their own reference implementations.

The key guidance: don't assume the open source license provides the same patent coverage as the standards patent policy. They cover different things. If both the spec and the code exist, make sure your client understands which rights come from which framework.

Governance Alignment

When a project has both a spec track and a code track, the governance structures need to be coordinated. Who has authority over the spec? Who has authority over the code? What happens when the code diverges from the spec? What happens when the spec evolves but the code doesn't follow?

A threshold question that must be answered at the outset: which leads? Is the spec being drafted first, with the code implemented against it as a reference? Or is the code leading, with the spec documented against a code snapshot at a point in time? These are fundamentally different development models with different IP implications.

In a spec-leads model, the specification is the authoritative source. The code implements what the spec describes. Patent commitments attach to the spec, and the code is a derivative artifact. Changes flow from the spec to the code, and conformance is measured against the document.

In a code-leads model, the codebase is the authoritative source. The spec documents what the code does. The spec may lag the code, and the code may evolve between spec snapshots. Patent commitments, if they attach to the spec, may not cover the latest code — and if they attach to the code, the framework described in Chapter 10 (open source licenses providing narrower patent coverage than standards commitments) applies.

Many projects fall somewhere in between, with the spec and code evolving in parallel. This can work if the coordination is deliberate — but if no one has decided which leads, the two tracks will diverge, and the divergence will surface at the moment someone asks "which version is authoritative?"

In traditional standards organizations, code was used primarily to verify the specification — reference implementations that proved the spec could be implemented and that identified ambiguities or errors. These reference implementations were not intended for production use, were often unoptimized, and frequently carried restrictive licensing terms specifically to prevent anyone from deploying them as products. The intent was to keep the spec canonical and the code subordinate. The modern shift toward production-quality open source implementations alongside specs inverts that relationship in ways that the traditional governance model wasn't designed to handle.

These questions are easier to answer when they're addressed at the design stage. Define which governance applies to which artifact. Define how conflicts between the spec and the code are resolved. Define who has the authority to declare that the code is a conformant implementation.

If you don't define these boundaries, the open source community and the standards community will each assume they have authority — and the resulting governance confusion will consume more time and energy than the underlying technical work.