New technologies such as 5G, IoT, blockchain and many others are implemented as ecosystems with many interoperable products and services designed to communicate seamlessly through a developing web of technical standards. Today’s standards are far more software-driven than in the past. As a result, standards development organizations (SDOs) are increasing their use of open source software (OSS) to promote both the rapid development of new standards and the deployment of standards-conformant products and services in the marketplace.Although SDOs have traditionally avoided requiring the use of any specific software code for conformance to its standards, SDOs have relied on OSS communities to develop tools, test suites, and independent implementations to assist implementers in developing products and services utilizing the standard. Today, however, there is a growing movement for SDOs to initiate their own OSS projects so that the standards and open source development efforts can be better integrated.SDOs understandably seek to replicate the benefits of collaborative development associated with OSS projects. In doing so, SDOs are also selecting the most common OSS licenses for the software they develop through these projects, such as the BSD or Apache licenses. These common licenses are ones that have been certified by the Open Source Initiative (OSI) as being compliant with its open source definition (OSD). While OSI does not hold a trademark on the term “open source” nor is it the arbiter of which software is considered OSS, OSI discourages others from referring to software as open source if the applicable software is licensed under a license that does not meet the requirements of the OSD. As OSS has become more commercial, the OSS development community has increasingly formulated OSS licenses that are more tailored to their respective objectives even when those licenses do not satisfy the terms of the OSD. SDOs, however, have not for the most part considered using an OSS license tailored to the intended use of the software being developed nor to their unique goals. Rather, by default, SDOs most often select a common OSI-approved license for their OSS projects.SDOs have long balanced the rights and interests of stakeholders through intellectual property (IP) policies that have permitted their contributors to commit to negotiate licenses for their essential patent claims on reasonable and non-discriminatory terms and conditions (RAND). While all open source licenses are royalty free, they do not require that the OSS be “patent-free” in the sense that no patent licenses would be required for use of the OSS. Nonetheless, OSI advocates that a RAND licensing commitment from a patent holder is incompatible with OSI’s approved licenses. Some innovators who have committed to license their essential patent claims on RAND terms have raised concerns about the use of OSI-approved licenses for SDO software projects. These innovators are discouraged from participating in such SDOs’ OSS projects because these innovators’ business models are not consistent with OSI’s requirements for unrestricted royalty free licensing. If an SDO’s OSS project becomes fundamental to the way standards are implemented in the marketplace, the lack of participation from these innovators may (i) deprive the community of valuable contributions, and (ii) skew the resulting SDO-approved OSS implementation in a way that is no longer vendor neutral.OSI-approved open source licenses also authorize unrestricted modifications and distribution of the modified software which is antithetical to an SDO’s goal of promoting conformant products and services. If the software can be modified without restriction, then it can be modified in ways that fail to conform to the standard, disrupting the market and thwarting widespread adoption of the standard. The vast majority of SDOs restrict recipients of their specifications, the documents which set forth the requirements of the standard, from making any modifications. Similarly, RAND commitments are made with respect to conforming products and services, not non-conforming ones. It is rather inexplicable then that SDOs are selecting OSI- approved open source licenses that are contrary to their goals of conformance, inconsistent with their existing balanced IP policies, and creating tension among stakeholders.This paper, using real world examples, explores some of the business motivations that have led to the common use of OSI-approved licenses in SDO OSS projects and the challenges created by using those licenses. The paper concludes by offering sample licenses that SDOs may consider that will promote their goals, foster consistency across their standards and software development efforts, and reduce IP-related friction among different stakeholder groups
