.. SPDX-License-Identifier: CC-BY-4.0 Copyright 2026 The Linux Foundation Standards vs. Software ====================== The introduction on the preceding page explained a few of the key concepts involved in community-driven standards development. However, it's helpful to understand more precisely how standards development differs from other collaborative technical efforts, in particular open source software projects. Open source software developers are often confused when first encountering a standards development effort. Open source communities are typically accustomed to working in a mostly- or fully-public manner. Issues and bug reports are available to participate in via a public code hosting service; mailing lists and meetings are open to the public; and contributions can come from anyone, perhaps with limited requirements such as a :doc:`DCO sign-off or a CLA signature `. By contrast, standards development projects can seem insular and oddly-structured for newcomers. Participation in meetings and mailing lists may be limited to those organizations who have signed project agreements. Ability to contribute and provide feedback may be similarly limited. And for those familiar with open source software licensing practices, the licenses used for many standards will look quite unusual. The following details help to explain the reasons behind these different approaches. Specification vs. Implementation -------------------------------- At its core, a standards project is developing something different than a software project: * The standards project is developing an *idea* (or rather, a *detailed description of an idea*). * The software project is developing a *specific, concrete implementation* of an idea. The *specification* developed by a standards project is essentially a collection of criteria. It might be a series of steps in a process, or a description of the particular format and shaping of data, or some other set of constraints. But ultimately, it consists of requirements where *many different implementations* may exist that conform to those requirements. By contrast, a software *implementation* is exactly that. It is one concrete instantiation of code which executes that specific program. It embodies its designers' choices in determining *how* to implement the requirements set forth in any specification to which it conforms. Different developers, writing a different implementation, might make different choices in how they choose to implement the same specification. There can be overlap between the two categories. For example, a standard might include references to particular versions of software components. Software might include data from a specification that is necessary to use in order to implement the standard. Nonetheless, approaching these as separate categories of technical artifacts is helpful in understanding why they are developed in different ways. Breadth of Intellectual Property Grants --------------------------------------- This distinction matters for several reasons. A key one is the implications that it has on the *scope of intellectual property rights* granted by participants in the development process. Any notable *open source software* typically includes contributions from many individuals, organizations and companies. Without getting into the details of the wide variety of open source licenses in use today, a few concepts are typically applicable: * Each contributor grants rights under the license as to *the specific parts they contribute*. * Those rights are granted *concurrently with making the contribution available*. * The granted rights *cannot be withdrawn* (except perhaps for persons who violate the license). * Contributor A's contribution doesn't affect the rights granted by Contributor B, and vice versa. By contrast, for a *specification*, the goals and mechanics of intellectual property grants are often quite different: * Each contributor grants rights under the license as to *the approved specification in its entirety*. * Certain of those rights may be granted *only when the specification is "approved" and published*. * Certain of the granted rights *might be capable of withdrawal* prior to formal approval of the specification. * Contributor A's contribution to the specification may lead to rights being granted by *all participants in the standards development effort*. The first of these points is the driver of the rest. When a group of organizations elects to participate in developing a standard, the applicable IP policy often requires that *all such participants* agree to license their intellectual property rights as to the final specification as a whole--and *not* only as to the specific pieces that they contribute. Because of this, SDOs' IP policies and the specifications' licenses are often more complex than those of open source software projects. The complexities can provide participants in the SDO effort with mechanisms to avoid unanticipated contributions of intellectual property rights, while still respecting the ultimate goal of all participants granting rights to the final approved specification.