Chapter 9: Non-Asserts, Pledges, and Covenants

The patent policies discussed in Chapters 7 through 8 operate within standards bodies — they're part of the governance framework that participants agree to when they join. Non-asserts and pledges started as something different: unilateral commitments made outside the standards process, typically by a single company, promising not to assert certain patents against implementers of a specification.

Over time, however, non-assert agreements have been adopted by standards bodies themselves. Organizations like OASIS and JDF now include non-assert options alongside their traditional RAND and royalty-free IPR modes. The Open Web Foundation agreements, originally developed as standalone instruments, are used by some organizations as their primary IPR framework. What began as an alternative to the standards process has become part of it.

Understanding the history of these agreements is useful for understanding why they exist, what problems they solve, and what their limits are.

The core motivation was distrust of RAND-based commitments. Under a RAND regime, the commitment is to offer a license on reasonable terms — but you don't see the actual terms until you go negotiate. For implementers, particularly in the open source community, this created a "gotcha" risk: you build to the standard, then discover that the license terms are unacceptable — incompatible with your distribution model, laden with conditions, or simply too expensive. By that point, you're already committed to the technology.

Non-asserts addressed this by putting the terms up front, before implementation. The rights are specified in the agreement itself — not deferred to a future bilateral negotiation. This was a model open source developers were already accustomed to. You read the license, you know what you're getting, you implement accordingly. No surprises after the fact.

9.1 Beyond Traditional Patent Licensing

A patent license grants specific rights to use patented technology. A non-assert is a promise not to sue. For a long time, the legal community debated whether these were functionally different — does it matter if I grant you a license to drive my car versus promise not to sue you when you drive it?

The Federal Circuit eventually concluded that for patent purposes, the distinction is largely academic. Both achieve the same result: the implementer can practice the technology without fear of enforcement. The original motivation for the non-assert formulation was to avoid patent exhaustion — the doctrine that once a patent holder licenses a product, their rights are exhausted for downstream recipients. By calling it a "promise" or "covenant" rather than a "license," drafters hoped to preserve the ability to assert against downstream parties. Courts were not impressed by the distinction.

Despite this, the non-assert formulation persists. Some of these instruments are drafted as promises, some as covenants, some as pledges. The terminology varies, but the practical effect is the same: the patent holder is committing not to enforce specified patents against specified implementations.

9.2 A History of Non-Assert Agreements

The evolution of non-assert agreements tracks the broader history of patent politics in the technology industry. Each generation was a response to specific trust failures and competitive dynamics.

The Sender ID Episode

In 2004, an early and instructive episode involved Microsoft's Sender ID email authentication specification at IETF. Microsoft made a royalty-free patent declaration — which sounded generous. But the actual license terms, linked from the declaration rather than included in it, imposed conditions that were incompatible with open source distribution models. The license was explicitly non-transferable and non-sublicensable, required formal execution, and distinguished between categories of users in ways that conflicted with how open source software is distributed. To make matters worse, the underlying patent application wasn't publicly available, so participants couldn't even evaluate the scope of the claims they were being asked to accept.

Major open source projects, including the Apache Software Foundation and the Debian project, publicly refused to implement the specification. The IETF working group itself ultimately rejected the proposal, concluding that the patent encumbrances could not be ignored and that participants could not accurately assess patent claims that weren't public.

The episode received mainstream press coverage and generated lasting distrust. It became a reference point every time Microsoft tried to engage with the open source and standards communities in the years that followed. But it also served as an important internal lesson. The Sender ID experience was one of several milestones that eventually led Microsoft to fundamentally rethink its relationship with open source — a process that took years but ultimately resulted in the company becoming one of the largest contributors to open source and a proponent of royalty-free standards. For other companies navigating similar tensions, it's a useful reminder: the terms you attach to a royalty-free commitment will be scrutinized, and getting them wrong can set back your credibility for a decade.

The Document Format Wars: ODF and OOXML

The mid-2000s document format standardization battle produced the most consequential wave of non-assert agreements.

Sun Microsystems, which had acquired StarOffice and was championing the Open Document Format (ODF), issued a non-assert for its patents reading on the ODF specifications developed through OASIS. The commitment was irrevocable, tied to specific versions where Sun participated, and included a defensive suspension provision. It was straightforward and well-received by the open source community — partly on its merits, partly because Sun had significant credibility with that community at the time.

IBM took a different approach. IBM published a "Statement of Non-Assertion of Named Patents Against OSS" — a pledge covering 500 named patents. The open source community praised it. On closer reading, however, many of the 500 patents were of marginal value, and the defensive suspension clause was exceptionally broad: if you asserted any patent against any open source software — regardless of whether it involved IBM's patents or IBM at all — the pledge was revoked. The actual legally binding terms were buried at the end of a very long document listing patent numbers. It was a significant public relations achievement with modest practical substance.

The Open Specification Promise

In response to criticism that its royalty-free commitments couldn't be trusted, Microsoft developed the Open Specification Promise (OSP). The OSP was deliberately drafted as a "promise" rather than a license, in part to avoid patent exhaustion and in part to avoid GPL compatibility concerns. It was structured as a direct commitment from Microsoft to each individual implementer — not a chain of rights that passed from one party to the next.

The OSP allowed subsetting — implementers could implement partial specifications and still receive patent coverage. This made sense for the office file formats, where nearly everything was optional, but created concerns when applied more broadly: a subset of a spec taken out of context could be used for purposes the original standard never intended.

Over time, the OSP became a default agreement applied to many specifications beyond its original purpose. As the number of specs covered grew, the defensive suspension provision — which revoked the promise if you sued over any covered specification — became increasingly broad.

The Open Web Foundation Agreements

The Open Web Foundation (OWF) agreements emerged from the open source community's dissatisfaction with all of the above. The goal was to create a community-developed, non-assert-style agreement specifically designed for standards and specification licensing that would be unambiguously compatible with open source.

The OWF agreements have two components: a Contributor License Agreement (CLA) for participants contributing to the spec, and a Final Specification Agreement (FSA) that grants patent and copyright rights to implementers of the final specification. The structure mirrors open source licensing patterns — familiar territory for the communities that use them.

The OWF agreements have been adopted by numerous specifications and, importantly, by standards organizations themselves — including as an IPR mode option within organizations like OASIS and JDF. This institutional adoption is what moved non-asserts from being ad hoc unilateral commitments to being a standard part of the standards toolkit. Their value is largely the same as any well-known, community-developed agreement: trust. They aren't proprietary to any single company, they were developed through an open process, and they're understood by the communities that rely on them.

9.3 The Community Specification License

The Community Specification License (CSL) represents the next evolution — taking the principles behind the OWF agreements and packaging them for the way specifications are actually developed today: in Git repositories, with asynchronous collaboration, using lightweight governance.

Origins and Design Philosophy

The CSL was developed by the Joint Development Foundation and is maintained under the Linux Foundation. It draws on the OWF agreements and the Alliance for Open Media patent agreements, distilling their IP terms into a form that can be adopted simply by forking a template repository.

The design philosophy is that starting a collaborative specification project should be as frictionless as starting an open source project. Fork the repo, define your scope and governance, and begin working. The IP terms — copyright licenses, patent grants, exclusion mechanisms — are already built into the framework.

How CSL Differs from Traditional IPR Policies

Unlike the patent policies discussed in Chapters 7 and 8, the CSL is not embedded in a standards organization's governance. It's a standalone set of agreements that any group can adopt, with or without a formal organizational structure.

Contributors grant a perpetual, royalty-free, non-exclusive copyright license and a patent license covering necessary claims. Patent exclusions are permitted but must be declared. The commitment is contribution-triggered — you make the commitment by submitting material to the repository.

The CSL is designed for specifications, not source code. This is an important distinction. Open source licenses grant rights to specific codebases. The CSL grants rights for independent implementations of a specification — a broader scope that ensures any implementer, using any codebase, receives patent coverage for practicing the spec.

When to Use CSL vs. a Full Standards Framework

The CSL is the right tool when you need IP clarity for collaborative spec development but don't need the full machinery of a standards organization — no corporate entity, no membership tiers, no formal governance structure. It works well for small collaborations, early-stage specification work, and projects that may later move into a formal standards body.

It also provides a natural on-ramp. A project that starts under the CSL can later transition to JDF or another standards framework if it outgrows the lightweight model. The IP terms are compatible, and the transition doesn't require re-doing the patent commitments from scratch.

The CSL is not the right tool when you need formal governance, tiered membership, certification programs, or the institutional weight of a recognized standards body. For those, the full frameworks discussed in Chapter 2 are more appropriate.

9.4 Anatomy of an Effective Non-Assert

Whether you're evaluating an existing non-assert or drafting one, several elements determine whether the agreement is meaningful or merely theatrical.

Scope

What specifications does the commitment cover? A specific version, or all versions in perpetuity? Only the mandatory portions, or optional portions as well? Only conformance implementations, or subsets? Each of these choices has consequences, and the answers should match the goals of the commitment.

Irrevocability

Is the commitment irrevocable? Most modern non-asserts are, but older ones sometimes include conditions or expiration provisions that limit their durability. An irrevocable commitment provides the strongest assurance to implementers.

Sublicensing and Exhaustion

Can the rights be passed downstream? This matters for supply chain scenarios where components implementing the spec are incorporated into larger products. If the commitment is structured to avoid exhaustion — as some early agreements attempted — downstream recipients may not be covered.

Defensive Termination

Under what circumstances can the commitment be revoked? A narrow defensive termination — revoking the commitment only against a party that asserts patents on the same specification — is reasonable and widely accepted. A broad defensive termination — revoking against anyone who asserts any patent against any open source software — is a different proposition entirely, and the implications grow with every specification added to the agreement.

Why Your Own Agreement May Be Technically Better but Practically Worse

This is one of the most important practical lessons in standards IP. You can draft a non-assert or patent pledge that is, on every technical dimension, superior to the OWF agreements or the CSL. Better definitions. Cleaner scope. More precise defensive termination.

Nobody will trust it.

The value of a well-known, community-developed agreement is that people recognize it. They can go to their legal team and say: this is the OWF agreement, it's been used by dozens of specs, here's the analysis we did last time. The conversation is about substance, not about whether the framework itself is trustworthy.

A bespoke agreement, no matter how well drafted, starts from zero trust. Every potential participant's legal team has to review it from scratch. They'll look for traps. They'll compare it unfavorably to what they know. The friction this creates is real, and it's often the difference between a specification that gets broad adoption and one that doesn't.

Use established agreements when you can. Save bespoke drafting for situations where the established options genuinely don't fit.