Once upon a time, standards were standards and open source software was open source software (OSS), and the only thing people worried about was whether the copyright and patent rules relating to the standards would prevent them from being implemented in OSS. Actually, that was complicated enough, but it seems simple in comparison now that OSS is being included in the standards themselves. Now what?
If this sounds unusual and exotic, it isn’t. In fact, code has been creeping into standards for years, often without the keepers of the intellectual property rights (IPR) Policies governing the standards even being aware of it.
Now that it’s becoming more common, however, it’s harder for standard setting organizations (SSOs) to ignore it, and harder still for them to decide what to do about it. Why? Because the rules under which the two types of collaborative work are developed are so different.
Let’s do a quick summary of some of the IPR rules that typically apply to each, starting with OSS:
- Code is usually available for free
- The project developing the code may be subject to contribution and licensing rules, or there may be no rules at all
- If there is a user license for the OSS, the terms can vary widely, from almost minimal (“permissive”) to significant (“copy left”)
- The copyright in each code contribution may be conveyed to the project, or (more often) retained by the owner
- Patent rules (if any) for contributors and users can vary widely
As you can see, that’s less of a list of rules than it is a summary of categorical options. Now let’s look at typical IPR rules for an SSO:
- Consortia standards are usually available for free; traditional SSO standards are usually sold
- There are always patent and copyright rules that control contributions and the resulting standards, although they can appear in a variety of different documents (IPR Policy, Bylaws, Membership Agreement, etc.)
- If there is a license for the standard, it usually prohibits copying, amendment and distribution
- Contributors traditionally retain ownership of their individual contributions, but the SSO always owns the copyright in the completed standard
- Patent rules are always included, and require that “necessary claims” under patents must be licensed on reasonable and nondiscriminatory (RAND) terms (policies vary regarding whether a member can charge for a license and/or withhold a license entirely)
As you can see, while IPR policies for SSOs have lots of variations, those variations tend to occur within a somewhat narrower range. You can also see that there are some pretty big differences between the rule sets that govern standards and OSS. So why is that?
The “why” arises from some fundamental differences between the two types of deliverables, and these variations introduce IPR tensions that can be hard to reconcile. Here’s a sampling of the more significant differences:
- OSS derives its value from allowing anyone to change it, while open standards derive their value from everyone doing things the same way
- Standards often reference other standards (which may be subject to different rules), while OSS often includes other OSS (which are often subject to different, and sometimes incompatible licenses)
- Rules under SSO IPR policies do not bind downstream parties (e.g., customers), while SSO licenses do
- The individuals that do the work in most (although not all) ICT SSOs are employees of corporate members, allowing IPR rules to apply in a binding legal fashion to all concerned; individuals participating in OSS projects will usually be subject to inventions agreements with their employers, who may have no relationship with (and hence are not automatically bound by the rules of) the project
- Copyright rules relating to standards are simple, uniform and non-controversial; copyright rules relating to OSS vary very widely and are sometimes hotly debated
- Copyright in an SSO relates only to the standard, and not the product; in an OSS, the copyrights relate to the deliverable itself
- Patent rules are clearly defined in SSOs, but may not be mentioned at all in OSS licenses; and SSO IPR rules may violate some OSS license terms
And that isn’t an exhaustive list.
If you’re getting the idea that the IPR rules relating to OSS and SSO’s are almost mirror, opposing images of each other, you’re beginning to get the picture (after all, even the acronyms are!) So what’s a standards developer to do?
There are a number of approaches that an SSO can take, including the following:
- Prohibit the inclusion of OSS in standards entirely
- Provide for two different licenses, or subsets of terms within the same license, for a hybrid standard (one for the OSS, and one for the included code)
- Force the SSO rules on the included OSS, or vice-versa
As you might expect, each of these approaches has issues and problems, so let’s go through that list again:
- If the SSO adopts the first approach, it may find that work that it would like to do will go to other SSOs instead (SSOs often overlap and compete with each other).
- If it goes with the second approach, the result is (at minimum) more complex
- If it goes with the third approach, and the SSO rules apply, the standard may not be usable in OSS that is subject to “copy left” licenses, while if it applies the OSS rules, users of the standard will not enjoy the level of patent protection they are used to when they implement a standard.
Finally, it’s worth noting that while an SSO project will generally put all of its IPR rules in the license itself, an SSO puts them elsewhere, and may not even use a license at all in connection with its standards, relying on just the copyright notice to prevent unauthorized copying and distribution. So the more troublesome issues don’t actually arise in the license used in connection with the standard at all, but in the related IPR policy.
As of this writing, there is no consensus about which way is the best way to address code embedded in standards. But some SSOs have already tackled the problem, and I’ll be writing about that in the future.