Development of standards specifications and development of open source software have much in common: both are mechanisms by which competitors can collaborate; both can facilitate interoperability; both can be used to facilitate the adoption of new technologies; both can be used to crystallize or harmonize mature technologies.
A technology may use both standards and open source: sometimes one precedes the other; in other cases, they may proceed in parallel. Increasingly, they may use similar tooling and process practices (e.g., fine-grained version control; driving certain development discussions with issue trackers).
The extent of the similarities can lead to over-generalization, incorrectly implying that everything is interchangeable—mix-and-match—pick a practice here; combine it with a process there. Indeed, it can be valuable to take experience gained in one domain and see if the benefit it provides might be obtained in other contexts. However, for certain practices, the context matters more than might be apparent.
While there are similarities, there are also significant differences. In an earlier article (Governance without rules: How the potential for forking helps projects), I discussed how governance of open source software development and standards development differ in the ability to take advantage of the potential for forking as a force that can facilitate lightweight governance. Another difference relates to the choice of patent rules.
Treatment of patents
Treatment of participant patent rights is typically arranged differently in open source software development and in standards development. There is a rationale for the difference. And, the difference has consequences for structuring the development process.
- Open source: Patent licenses granted when contributing to open source projects are generally scoped by each contributor's contribution.
- Standards: Patent commitments made by participants in standards development are generally scoped by the entire, final specification.
Open source projects: contribution-based patent rules
What do I mean by a contribution-scoped patent rule? If a patent owner contributes software such that, as a result of the software's addition to the project, the project software infringes a patent owned by that contributor, then the contributor ought not to come back and expect a patent license fee for use of software that it contributed. Of course, there are plenty of different license texts that could keep us busy analyzing the interpretation of each license and talking about uncertainties and nuances in the situations. In another article, I talked about this issue in the context of the MIT License (Why so little love for the patent grant in the MIT License?). I believe that, essentially, the shared expectation in open source development is as I have described above: When you contribute to open source, you are giving all the needed permissions that you have for the software that you contribute, and you will not later come back asking for a license fee for use of the software that you contributed.
Standards development: specification-based patent rules
In contrast, in development of standards, there is generally a higher expectation: Participants are expected to make a commitment with respect to patents that are essential to the entire, final specification, not merely to their contributions. Those patent commitments do not depend on determining who contributed what idea to the specification; for those who are part of the group developing the spec, their commitment is to the whole specification.
Patents included
The analysis to determine the relevant patents is also somewhat different between software and specifications. Software will typically include implementation details that would not be required if compared to a corresponding standards specification; permission to use any patents on those details would be included when contributing software. In contrast, the patent commitment for specification development is limited to patents that are "essential" or "necessary" to the specification. This, of course, depends on what is specified. For interoperability standards, the specification should only include the level of detail needed to accomplish interoperability, allowing implementation details to differ among competing implementations of the standard. A commitment to essential patents would not include patents on implementation details, which may be used as competitive differentiators.
Basis for differences in patent rules
Why is there this difference in treatment of patents? This different treatment makes sense in light of differences in how standards and open source software are developed.
The more limited, contribution-based expectation concerning patents fits with the incrementally evolving, open-ended nature of most collaborative software development. Open source projects often undergo continuous development, the direction of which may evolve over time. While roadmaps and milestones may be set and snapshots taken, these are less common and have less restrictive impact than the scope limitations and version targets that are common among standards projects.
One can see how the higher expectation that is typical of standards development (the whole final spec, not only contributions) makes sense considering differences in how development of standards specifications is structured. Standards specifications typically undergo a strongly version-oriented evolution with explicit scope. Specification development typically works toward specific snapshot versions. A standards development activity will often have a target set of functionality (typically expressed in a document such as a charter). This provides a clearer shared advance expectation as to the scope of technologies that are likely to be implicated in a standards development activity than would be the case for many software development activities. This clarity of scope facilitates a potential participant's evaluation of the patent implications of participating in a standards development project at the time of beginning participation. Contrast this with a more open-ended open source software development project, which would not generally exclude the possibility of incorporating any particular technology.
Implications on management of open source projects and standards
These different approaches to patents require different approaches in project management.
An open source project is often prepared to accept patches from new contributors. Contributors may come and go over time. Some stay. Others may stop by the project to address a single, limited issue. With software contributions, it is easier to have an understanding of who contributed what software than to have a precise understanding of who "participated" in some more abstract way.
On the other hand, there is typically greater formality associated with participation in a standards development activity. And, such formality of participation is important when it comes to the patent commitments. A patent commitment to the final spec makes sense when one participates through much of the development of that spec. Can a standards development process expect a full final specification commitment from one who provided a single, narrow contribution? It is important to have a process that leads to a clear understanding of who is participating and who is not. Clarity of participation is needed to support patent commitments from the actual patent owners, which are generally the companies who are represented by the individuals who are sitting at the table (speaking metaphorically; although this can involve actual tables).
How is a specification-wide commitment obtained? The royalty-free patent commitments that are typical of software standards are most commonly implemented as a condition of membership in the standards organization or membership in the particular committee that is responsible for development of the specification. In order for this mechanism to work, membership must be a well-defined concept, so that there is a clear membership decision point (i.e., a well-defined action that would be used to trigger the undertaking of patent commitments) and a clear record on which the beneficiaries of the commitments can rely. In addition to participation clarity, in order to facilitate participation by skeptical patent-owning participants, projects need to have an explicit scope and a clear beginning and end (with clarity of what is the "final specification" to which commitments will apply). This model for participation differs significantly from typical open source projects, which may have a continuum of participation extending from a few main drivers down to those who may submit only a single patch.
Patent policies
While the difference I have described is generally the case, there may be reasons for a particular activity to follow a different pattern. For example, consider the software that is a reference implementation that accompanies a standards development activity. There may be a strong rationale for expecting participants to commit to the full, final resulting reference implementation, not only to their contributions to it. Of course, other edge cases may exist; there may be rigidly scheduled open source development; there may be continuous, free-wheeling specification development.
Patent policies for standards development can be categorized as reasonable and non-discriminatory (RAND) or royalty-free (RF): essentially, whether patent licensing fees for implementation of the standard are considered OK (RAND) or not (RF). Development of standards relating to software (the focus of this article) more often uses a royalty-free policy. This matter of whether patent license fees are expected or not is a separate dimension of the policy from the scope of the license or commitment.
Conclusion
Development of standards and development of open source software typically have different scopes of patent expectations from participants (only to contributions or to the entire final deliverable). Rather than arbitrary differences, there is a rationale for these different choices that is based on significant differences in how development is typically undertaken.
1 Comment