Chapter 3: The Intellectual Property Landscape of Standards

Four categories of intellectual property come up in standards work: copyright, patents, trademarks, and trade secrets. Of these, patents get the most attention — and deserve it, because that's where most of the risk and complexity lives. But copyright and trademark each carry their own traps, and trade secrets present a unique set of concerns in a context built around sharing. Understanding how all four interact is essential before you start reading actual policies.

This chapter is the overview. Subsequent chapters will take you inside specific patent policies, necessary claims definitions, exclusion mechanisms, and the rest of the machinery. Here, the goal is to establish the framework so the details in subsequent chapters have context.

3.1 Copyright: Broader Than You Think

When someone makes a contribution to a standards body — a technical proposal, a draft section, a diagram — that contribution carries copyright. The standards body needs rights to that material. How it gets those rights varies, but the mechanism is almost always one of two things: a broad license or an assignment with a license back.

Most people prefer the license approach. It's less intrusive. You keep ownership of your contribution, which means you can submit the same material to multiple standards bodies if you're working on related specs. An assignment feels grabby, even when it comes with a broad license back. There's additional paperwork. People tend to avoid it when they can.

In practice, the distinction matters less than you'd expect. Whether it's a license or an assignment with a grant back, the rights the standards body receives are exceedingly broad. They need to be. The organization has to be able to evolve the material, create derivative works, publish it, and maintain it indefinitely. Don't assume you're retaining meaningful control over contributed material. The license is that broad by design.

Inbound and Outbound Copyright

It's useful to think about copyright in standards as having two directions.

Inbound copyright is the rights the standards body receives from contributors. This is the license or assignment discussed above — the mechanism that allows the organization to assemble, edit, publish, and maintain the specification.

Outbound copyright is the rights the standards body grants to implementers and the public. This is how the finished specification gets distributed. Some organizations sell copies, some publish under Creative Commons licenses, some make specs freely available on their websites. The outbound terms determine who can access the spec, whether they can reproduce it, and whether they can create derivative works.

The inbound and outbound sides can be asymmetric. A standards body might receive broad inbound rights from contributors but distribute the finished spec under restrictive outbound terms — for example, allowing implementers to read and use the spec but not reproduce or modify it. Others may be broad in both directions. The combination of inbound and outbound terms shapes the practical accessibility of the standard.

Who Owns the Spec?

Here's where it gets interesting. In most cases, the standards body doesn't own the entire specification outright. What it owns — or more precisely, what it has rights to — is the collective work. Individual contributions remain with their contributors. The standards body assembles them into something that functions as a unified document, and the rights in that compilation are what gives the organization its copyright position.

This works well enough when you have an incorporated standards body sitting in the middle. But in a contractual consortium — one with no corporate entity — there's no one to hold those collective rights. What you end up with is effectively a massive cross-license among all the participants. Everyone grants rights to everyone else. It works, but it's a different legal posture than having a central entity that can enforce the copyright in the spec.

Why does enforcement matter? Because for many traditional standards bodies, selling the spec is the business model. ISO, IEC, and similar organizations charge for access to their standards — sometimes hundreds of dollars per document. They need the ability to prevent unauthorized reproduction and distribution. The copyright in the collective work is what gives them that.

The Access-to-Law Problem

This business model is under pressure, and it's worth understanding why.

When a government normatively references a standard in legislation or regulation — building codes are the classic example — citizens are effectively required to comply with a document they may have to pay to access. You want to build a house in Redmond? You need to meet the building code. But the building code incorporates standards developed by private organizations, and those organizations charge for copies.

The democratic objection is straightforward: why should citizens have to pay a private entity to access the law? Some standards bodies have responded by allowing limited public viewing — you can read the spec in a reading room, but you can't take a copy home. Recent court decisions, particularly in Europe, have pushed further toward requiring free access when a standard is incorporated into law.

For most technology companies, this is not their fight. It's a business model problem for standards bodies. The preference is for all specs to be publicly available, but that doesn't mean it's wise to pick a fight with a standards body over their revenue model.

Where this has gotten more acute recently is around AI training. Some standards bodies have started posting notices on their websites explicitly prohibiting the use of their standards as AI training data — ISO updated its Terms of Use in 2023 to address this directly. The practice is emerging, not universal, but at least one organization has sent demand letters to technology companies. Their concern is that if someone can ask an AI to explain how to comply with a standard, there's no reason to buy the document. That concern has some basis, even if the practical risk of relying on AI-generated building codes seems obvious.

Creative Commons and Forking Risk

Many technology-focused standards bodies publish their specs under Creative Commons licenses or even on open wikis. The philosophy is that broad access leads to broad adoption.

The criticism — and I think it's valid — is that this creates forking risk. If someone can modify a spec on a wiki, and you build a product to that modified version, interoperability breaks. In practice, this hasn't been a significant problem. But it's a good reminder to advise your clients to always pull specs from the canonical source.

Copyright as a Stability Mechanism

It's worth stepping back and recognizing that copyright in standards isn't just about revenue or enforcement. It serves a structural function: maintaining the integrity of the spec over time.

A canonical, copyright-protected specification gives implementers confidence that the document they're building to is the real one. It prevents unauthorized forks that would fragment the ecosystem. When someone modifies a spec — even with good intentions — and products get built to the modified version, interoperability breaks. Copyright is the legal mechanism that keeps a single authoritative version in place.

This is one of the reasons that even organizations philosophically committed to openness still maintain copyright control over their specs. You can make a spec freely available and still prevent unauthorized modifications. The Creative Commons Attribution-NoDerivatives license, for instance, allows free distribution while prohibiting forks. The goal is broad access with long-term stability — and copyright is the tool that makes that possible.

3.2 Patents: The Main Event

Patents are where the complexity, the risk, and most of the case law lives. The entire second part of this book is devoted to patent policies, but here's the conceptual foundation.

The Monopoly Problem

Start with first principles. If you have a patent that reads on a standard, and that standard is widely adopted, you have a monopoly position.

In a normal market, patents create leverage but not unchecked power. If someone holds a patent on a particular technology, you can design around it, license a competing patent, or build something different. Market forces impose some discipline on what a patent holder can charge.

Standards eliminate that discipline. When a technology is embedded in a standard, every implementer must use it. There is no designing around it. The standard says: do it this way. If you hold a patent on "this way," you can charge whatever you want. You can seek injunctions. You have monopoly rents on a captive market.

This is the problem that every patent policy in every standards body is trying to solve.

RAND and FRAND

The most common solution is the RAND commitment — Reasonable and Non-Discriminatory licensing terms. In Europe, it's called FRAND, with the F standing for Fair. They mean the same thing, and no, the F does not mean Free. This is a common and consequential misunderstanding.

A RAND commitment is a commitment to license — not an actual license. The distinction matters. When a patent holder makes a RAND commitment, they are promising to offer a license on reasonable and non-discriminatory terms to anyone who wants to implement the standard. But the actual license itself — the specific terms, the rate, the scope — is left to the patent holder and the implementer to negotiate bilaterally, outside the standards body. The standards organization facilitates the commitment. It does not broker or administer the resulting licenses.

The idea is to restore something approximating competitive market conditions. The patent holder can still charge for necessary claims, but they can't leverage the monopoly created by the standard to extract monopoly pricing.

What constitutes "reasonable" is, predictably, where all the litigation happens. The policy terms themselves are rarely contested. It's the rates that get fought over. And those fights are substantial — they involve hundreds of millions of dollars in the wireless and video codec spaces. There's also an ongoing debate about whether a RAND commitment prohibits the patent holder from seeking injunctions against implementers. Opinions vary by jurisdiction and by policy, and courts have not been uniform on this point. It's one of the more contested open questions in standards patent law.

Necessary Claims

The RAND commitment doesn't apply to your entire patent portfolio. It applies only to what are called necessary claims (sometimes "essential claims") — patent claims that you cannot avoid when implementing the standard.

This concept is the heart of every patent policy and deserves its own chapter, which it gets. But at the overview level, the logic is this: if a patent claim is truly unavoidable — if there is no way to implement the standard without practicing that claim — then the patent holder has a monopoly, and the RAND commitment kicks in.

Counterintuitively, while disputes over essentiality do occur, they are far less frequent than disputes over royalty rates. Both sides typically have incentives to agree that a claim is necessary — the game theory favors it — and litigating essentiality is expensive enough that parties often concede the point to focus the fight on the rate. The game theory behind this dynamic is explored in Chapter 6.

Royalty-Free vs. Royalty-Bearing

Not all patent policies allow royalties. Royalty-free (RF) policies — sometimes called RAND-RF or RAND-Z (zero royalty) — require patent holders to license their necessary claims at no charge. The implementation is free; the commitment is irrevocable (usually with a defensive termination provision).

The choice between RAND and royalty-free is one of the most significant decisions in setting up a standards body, and it shapes everything downstream. Industries with large existing patent portfolios — telecom, video codecs, wireless — tend to use RAND. Software-focused and web-focused organizations tend to use royalty-free. We'll explore this divide in depth in Chapters 7 and 8.

The Certification Shortcut

One practical consequence of standards patents is worth noting here. If your product carries a certification logo — Wi-Fi, Bluetooth, whatever — the logo serves as strong evidence that the product practices any necessary claim. It's not a formal admission of infringement in a legal sense, but it dramatically simplifies the patent holder's case.

A patent holder pointing to a certified product doesn't need to prove infringement claim by claim. The logo tells the world you implement the standard. If they hold a necessary claim, the conversation moves quickly to the rate — which is one reason patent policies in standards have so much practical significance.

3.3 Trademarks and Certification Marks

Trademark in standards will feel familiar if you've worked with open source foundations. There are similar dynamics around brand control and licensing. But standards add a certification layer that creates its own set of issues.

The Value of the Logo

For many standards, the trademark — specifically the certification mark — is the most commercially powerful piece of IP the organization holds. Not the spec. Not the patents. The logo.

Retailers won't stock a Wi-Fi router without the Wi-Fi logo. It's not about legal obligation; it's about returns. A router without the logo might not interoperate with everything, and the retailer doesn't want to deal with customers bringing it back. So the logo becomes a market access requirement.

More forcefully, trademarks can be enforced at the border. Customs officers inspecting a shipment of, say, Bluetooth headsets will check whether the product is listed in the Bluetooth organization's licensed product database. If it's not, the shipment gets seized. That's a powerful enforcement mechanism — far more immediate than patent litigation.

Self-Certification vs. Formal Testing

Conformance programs come in several forms.

Self-certification is the most common. The standards body publishes a set of requirements, you test your product internally, and you declare compliance. OpenChain's open source compliance standard works this way. You describe your program, you self-certify, and if someone asks, you hand over your artifacts.

Formal third-party testing is the heavier approach. You submit your product to a testing lab — sometimes UL, sometimes a university lab, sometimes a lab run by the standards body itself — and they verify compliance before you get the logo. Some organizations use a hybrid: formal testing for your first product, self-certification for subsequent ones.

A foreign-market example worth knowing. China uses mandatory standards compliance, verified through formal testing, as a market access requirement. The leading example is GB18030, the national standard for the Simplified Chinese character set. Any product sold in China that handles text — operating systems, browsers, document software, fonts, embedded systems with displays — has to support GB18030, and conformance has to be demonstrated through the official testing process. There is no self-certification path. There is no "good enough" alternative. If you want access to the Chinese market, you support GB18030 and you get certified. The standard itself is unobjectionable on the merits — encoding the world's largest script is a real interoperability problem — but the certification regime is also doing market-access work, and that's the part counsel needs to understand. Several other Chinese GB standards function the same way across other product categories. When evaluating a product launch in China, the GB compliance pathway is often as important as the IP analysis.

When Certification Overrules the Spec

This is the trap to watch for. Sometimes the conformance program tests for things that go beyond what the spec requires.

A specification might describe a feature as optional — implementers can include it or not. But the conformance program might test for that optional feature and fail you if it's missing. Your product complies with the spec. It doesn't pass certification. No logo.

This has real consequences. It effectively elevates optional spec features to mandatory ones, not through the standards process but through the certification program. The Java certification dispute between Sun and Microsoft was partly about exactly this — the certification program was testing for capabilities beyond what the spec strictly required.

For antitrust reasons, most standards bodies separate their spec development and certification functions into different organizational arms, or rely on external organizations entirely. The IEEE develops the 802.11 wireless specifications. The Wi-Fi Alliance, a separate organization, runs the certification program and grants the Wi-Fi logo. This separation is deliberate and important.

Profiles

One more piece of the trademark and certification picture: profiles.

A broadly written standard may support many configurations. Different implementers may tune the settings differently, and products tuned differently may not interoperate even though they all comply with the spec. Profiles solve this by defining specific configurations for specific use cases.

MPEG DASH is a good example. The standard describes how to handle media streaming under varying network conditions — buffering, quality switching, congestion management. But the standard had so many options that different implementations set the dials differently and couldn't interoperate. The DASH Implementers Forum created profiles on top of the standard: if you're streaming on the web, use these settings; if you're on satellite, use those. This was what ultimately allowed services like Netflix to consolidate from dozens of encoding configurations down to a manageable few.

Profiles are sometimes developed by the standards body itself, sometimes by external organizations. Either way, they sit between the spec and the certification program and are often where the practical interoperability gets defined.

3.4 Trade Secrets: The Wrong Tool for Standards

Trade secrets and standards are fundamentally incompatible. Standards are built with and among competitors, and their entire purpose is to become publicly available for broad implementation. A trade secret, by definition, derives its value from being kept confidential. These two concepts don't coexist.

If you're advising someone who wants to contribute proprietary technology to a standards body while maintaining trade secret protection, the answer is almost always: don't. It is possible to share high-level, non-essential information in a standards setting and preserve trade secret status — particularly if appropriate NDAs are in place and the disclosure is carefully controlled. But the moment the inventive concept itself is shared in a multi-party setting with competitors — often dozens of them — trade secret status is effectively gone. Even if everyone in the room has signed a confidentiality agreement, the practical ability to maintain secrecy across that many parties and organizations is negligible.

More importantly, the intent of standards is publication. The spec will eventually be made available to the world. Any technology embedded in it will be described in sufficient detail for independent implementation. You cannot contribute to a standard and expect to maintain trade secret protection over the contributed material.

This doesn't mean proprietary information never enters a standards discussion. It does. Product roadmaps get referenced. Implementation strategies get discussed. Business plans come up in the context of use cases. But the onus is on the discloser to protect their own information. Standards meetings happen among competitors. If you share something confidential in that setting, that's on you.

We'll discuss confidentiality provisions in standards organizations in more detail later in this book. The short version: treat them with caution. They exist, they serve a purpose in protecting draft specifications, but they are not a substitute for the discloser exercising judgment about what to share in a room full of competitors. Discloser beware.

One thing worth flagging here, because it surprises people who haven't worked at the institutional level: a meaningful part of the confidentiality you see around draft standards isn't really about protecting contributors. It's about protecting the standards organization itself. SDOs compete with each other — for relevance, for participants, for the right to host the canonical work in a given technology area — and they do not want a competing organization to see their draft work in progress and use it as a head start to scoop them. That competitive dynamic is one of the quieter reasons draft access tends to be restricted to members. It's worth keeping in mind, because it explains some confidentiality rules that would otherwise look excessive.

3.5 Confidentiality and the Open Source Tension

Many standards bodies restrict access to draft specifications to members only — though not all. Organizations like W3C and IETF make their drafts publicly available as a matter of policy, and the trend is toward more openness. But the members-only model remains common, particularly among older organizations and those with dues-dependent business models. There are two reasons for it, one financial and one strategic.

The financial reason is straightforward: membership dues are the primary revenue source for many organizations. If the drafts are available to everyone, the incentive to join diminishes.

The strategic reason is more interesting. Members who participate in the drafting process get an implementation head start. They're in the room. They can adapt the spec to their product needs. They can start building before the spec is published. By the time the final standard goes public, participating members may have a significant lead over non-members.

This creates a tension when standards bodies want to include open source implementations alongside their specs. Open source, by its nature, lives in public repositories. But if the spec is confidential, how do you have a public codebase implementing a private document?

Some organizations have tried to square this circle by keeping the open source code inside the organization, subject to the same confidentiality rules as the spec. The code uses open source licenses — all the rights are there — but you can't actually access it unless you're a member.

Others have simply accepted that once you commit to having an open source implementation, the spec is effectively public regardless of what the confidentiality rules say. A careful reader can reverse-engineer a lot from working code.

The broader pattern here is that as standards and open source converge, the traditional confidentiality model comes under pressure. Organizations that embrace open development tend to thrive. Those that try to keep one foot in each world tend to create confusion for their participants and friction for their lawyers.

Confidentiality in standards development should be treated with a light touch. It has a role — protecting draft specifications from premature publication, giving participants space to work without external pressure. But it should never be mistaken for a mechanism to protect proprietary information. That responsibility falls on the party doing the disclosing, not on the organization's confidentiality rules.

3.6 How the Pillars Interact

Copyright, patents, trademarks, and trade secrets don't operate in isolation in standards. They interact in ways that matter for how you advise.

The spec is protected by copyright — which maintains its integrity and prevents breaking forks. The technology described in the spec may be covered by patents. The brand and certification program are protected by trademarks. And trade secrets, while inappropriate for contributed technology, still require vigilance about what gets shared in rooms full of competitors. An implementer needs to navigate these layers to get a product to market.

In a well-designed standards ecosystem, these layers are complementary. The copyright ensures a canonical, stable spec that can't be fragmented. The patent policy ensures implementers can access the technology at reasonable cost (or for free, in RF regimes). The trademark program ensures interoperability and gives consumers confidence. And clear expectations about trade secrets and confidentiality keep participants from inadvertently compromising their own proprietary positions. Each layer solves a different problem.

Where things go wrong is when the layers conflict. When a certification program tests for patent-covered features that the spec describes as optional. When confidentiality rules prevent open source contributors from accessing the spec they're implementing. When a standards body's copyright enforcement posture discourages adoption of the standard it's trying to promote.

Most of the time, these conflicts are manageable. But recognizing them early is part of the job. When you pick up a new standards engagement, map all the IP dimensions before you dive into the patent policy. The patent policy is the hardest part, but it's not the only part.

We'll spend the next six chapters inside it.