The following article was co-written with Michele Herman of JustTech
Open source software and open standards have many similarities but the legal frameworks under which each are created have real and important differences. Nonetheless there is an increasing desire to combine the benefits of both open source and standards in the development of new interoperable software-based technologies. The good news is that the differences in legal frameworks can be reconciled by giving care to the rules under which standards are developed. One key area of attention to achieve this end involves the copyright rules under which open source elements of standards are made available.
Of course, many thousands of standards have been developed for decades that are intended to be implemented in software, particularly in order to achieve interoperability. Such standards generate multiple competing commercial implementations, some of which have been developed through open source software (OSS) communities, while other commercial implementations remain proprietary. Standards setting organizations (SSOs) and OSS communities also develop (or contract for the development of) software to enable more rapid deployment of standards-based solutions. Examples include standards compliance testing and product certification test tools, and even complete reference implementations to aid in interoperability testing.
The mere development and use of software by SSOs in these ways has for the most part not given rise to conflicts with traditional SSO patent policies that permit participants to license their essential patent claims (i.e., those patent claims that would be infringed by implementing the standard), on fair, reasonable and non-discriminatory (FRAND) terms. The intellectual property rights (IPR) policies of most (but not all) SSOs provide that FRAND terms may include reasonable royalties or other reasonable license fees. SSOs with such patent policies are referred to in this article as FRAND SSOs.
When open source and open standards merge. Today, many SSOs are going further and incorporating software into their standards. For example, for a given element, the standard may include both a traditional descriptive text section as well as a text section expressed exclusively as implementable code[1]. For some SSOs, the code text is provided for optional use, while for other SSOs the use is mandatory. In some cases, both SSOs and OSS projects may create complete code implementations, either as reference implementations or independent of any traditional standard. While there are obvious efficiency benefits to repurposing existing code in a product, there is also a desire to strive for a higher degree of assurance that the user has received the requisite licenses to the IPR in the code from those that developed the reference implementation.
When SSOs evolve to develop software, however, they typically run into a limitation in their traditional IPR Policies: those policies only require work group contributors to authorize the SSO to distribute a work product that is the sum of the contributions of (usually) multiple work group members. Once code is included, the SSO must also have the right to allow implementers and other downstream parties to copy, modify, and further distribute the software in standards-conformant products and services. This requires the addition of new license terms to the IPR Policy.
One set of rules or two? When this situation occurs, the question arises whether the same rules relating to IPR should apply to the entire standard, or whether separate rules should apply to the text and code sections. Understandably, most SSOs conclude that both participants in the development of the standard and users of their standards would prefer to have a single set of rules that applies to the entire standard, and also prefer that the set of rules that should apply are the FRAND rules they have traditionally applied to patents.
Notwithstanding their interest in having common policies that apply to both the text and the code portions of the standard, many SSOs are interested in putting in place collaborative processes for developing software that mirror the benefits and efficiency of traditional OSS communities. This desire often leads them to consider using one of the popular open source licenses such as the BSD 3, MIT or Apache licenses.
Tailoring the rules to fit the need. Those common licenses, however, are incompatible with FRAND SSO IPR policies, as they do not include economic terms with respect to patents (traditional SSO IPR polices do expect contributor copyright licenses to be free). FRAND SSOs may also wish to limit the degree to which code can be modified in pursuit of the goal of achieving interoperability. As a result, while those common licenses could be used as a starting point, they could not be used without modification, at minimum by adding text that states that the license grant is restricted to copyrights alone. SSOs that wish to limit modification rights (particularly with respect to reference implementations) would need to make more drastic revisions. Importantly, making changes to these common OSS license means that such modified licenses should no longer be referred to by their original names, because these modifications make material changes to their terms.
By adopting separate copyright rules for code, the SSO can carefully craft the rights conveyed to promote conformance with its standards which it cannot do when using licenses like the BSD, MIT or Apache. It is reasonable to expect that implementers will need to make modifications to the software in order to implement mandatory software, or even am entire reference implementation, into its standards-conformant products and services. The software license can be crafted to allow such modifications while prohibiting modifications that impede conformance with the standard or thwart interoperability among relevant products and services.
The authors have very similar practices involving standards, open source, and intellectual property licensing but our respective clients often have very different views on licensing and intellectual property rights policies. Notwithstanding some of our clients’ differing views, we agree that using separate copyright rules for code as described in this article is an effective approach for SSOs that wish to develop software within the legal guardrails of traditional SSO IPR policies.
[1] One definition of such text reads as follows: “Any combination of: text listings of commands to be interpreted or to be compiled, translated, or assembled into an executable computer program; text listings that describe data structures; text listings that specify an Application Programming Interface (API) used to interact with some executable computer service (including access from an executable computer program, library, or remotely via a telecommunications interface); binary data files; executable, object, or other intermediate executable code files; and text listings that describe the behavior of modeled devices or objects (e.g., XML, YANG, etc.).”
