The Open Source Definition
The Open Source Definition (OSD) is a concise document outlining ten specific criteria that a software license must satisfy to be recognized as open source by the Open Source Initiative (OSI).[1] Derived from the Debian Free Software Guidelines, it prioritizes practical permissions for redistribution, modification, and access to source code while prohibiting discriminatory restrictions.[2][3] The criteria include requirements for free redistribution without fees, mandatory inclusion of source code in distributions, allowance for derived works under the same terms, and protections against discrimination toward individuals, groups, or application domains.[1] Additional clauses ensure license rights propagate to downstream users, remain neutral across software ecosystems, impose no limits on bundled non-open-source components, and avoid favoring specific technologies.[1] These provisions enable collaborative development and commercial viability, fostering the growth of projects like Linux distributions and web servers that underpin much of modern computing infrastructure.[4] While the OSD has standardized license approval—certifying over 80 licenses to date—and driven industry adoption by appealing to pragmatic benefits over ideological mandates, it has sparked debate with the free software movement.[4] Critics, including Richard Stallman of the Free Software Foundation, contend that the definition's focus on technical accessibility neglects the ethical imperative of ensuring all users' freedoms to run, study, modify, and redistribute software without proprietary enclosures, potentially allowing "open source" code to fuel restrictive products.[5] This tension reflects a core divergence: open source as a development methodology versus free software as a defense of user autonomy.[6]History
Origins in Debian Free Software Guidelines
The Debian Free Software Guidelines (DFSG) originated as a set of criteria for determining what constitutes free software within the Debian project. Drafted primarily by Bruce Perens, the guidelines were refined through a month-long email discussion among Debian developers in June 1997 before being incorporated as Section 2 of the Debian Social Contract, version 1.0, ratified on July 5, 1997.[7] The DFSG outlined ten specific principles focused on ensuring users' practical abilities to run, study, share, and modify software, without embedding explicit moral or ideological requirements beyond these functional freedoms.[8] These ten points directly templated the Open Source Definition (OSD), which Perens adapted by rephrasing the DFSG to emphasize pragmatic licensing terms suitable for broader industry adoption, stripping away Debian-specific references while retaining the core structure of distribution and modification rights.[1] The adaptation occurred in early 1998, amid growing commercial interest in source code release, such as Netscape's January 29, 1998, announcement to open-source its browser, highlighting the need for a neutral, non-proprietary framework that prioritized verifiable permissions over prescriptive ethics.[9] Unlike the Free Software Foundation's emphasis on ethical imperatives, the DFSG's formulation favored empirical enforceability of rights, influencing the OSD's role as a certification standard for licenses enabling collaborative development without ideological barriers.[10] This foundation underscored a shift toward causal mechanisms of innovation through unrestricted access and derivative works, rather than appeals to user solidarity.Formation of the Open Source Initiative
The Open Source Initiative (OSI) was established in late February 1998 as a nonprofit organization dedicated to promoting open source software through the stewardship of a standardized definition and license certification process.[2] It was cofounded by Bruce Perens, then Debian project leader, and Eric S. Raymond, author of The Cathedral and the Bazaar, who served as OSI's initial president and vice president, respectively.[2] The formation responded to the growing interest in non-proprietary software development following Netscape's January 1998 announcement to open-source its browser code, but sought a pragmatic framework to encourage broader industry participation beyond the Free Software Foundation's (FSF) emphasis on user freedoms as moral imperatives.[11] The OSI's creation stemmed from a strategic effort to reframe "free software"—a term associated with Richard Stallman's FSF and its philosophical commitments—as "open source," highlighting practical benefits like collaborative development and interoperability to appeal to businesses wary of ideological connotations.[12] This rebranding aimed to facilitate adoption by corporations and governments without mandating the FSF's four essential freedoms as ethical absolutes, instead focusing on verifiable license criteria that enable commercial viability and innovation.[2] Perens initially adapted the Debian Free Software Guidelines into the Open Source Definition (OSD) as a neutral benchmark, though he later resigned from OSI in July 1998 over disagreements regarding the dilution of free software principles.[2] In March 1998, the OSI released version 1.0 of the OSD, establishing ten criteria for licenses to qualify as open source, including free redistribution, derived works allowance, and source code integrity preservation.[1] Early objectives centered on creating an authoritative list of compliant licenses to reduce legal ambiguity, certify software against the OSD, and build ecosystem trust through education and advocacy, thereby accelerating open source's integration into enterprise environments.[13] This certification role positioned OSI as a steward independent of any single project or ideology, contrasting with the FSF's copyleft-focused approach.[14]Key Versions and Revisions
The Open Source Definition (OSD) was first published by the Open Source Initiative (OSI) in February 1998, adapted from the Debian Free Software Guidelines by removing Debian-specific references while preserving core principles of software freedom.[2] This initial version established ten criteria for open source licenses, emphasizing free redistribution, source code availability, and derived works without restrictions on commercial use or modification.[1] Subsequent iterations through version 1.3 in 1999 introduced minor editorial refinements for clarity, such as explicit language on license compatibility and non-endorsement requirements, but avoided substantive alterations to maintain interpretive consistency.[1] By 2007, the OSD reached version 1.9 on March 22, incorporating limited clarifications to address evolving interpretations, including strengthened wording in criterion 5 on patent grants to ensure licenses explicitly allow derivative works without patent encumbrances, and refinements to criterion 6's anti-discrimination clauses to preclude field-of-endeavor restrictions while permitting narrow ethical safeguards against malicious use.[1] These changes were conservative, focusing on precision rather than expansion, as evidenced by OSI's annotated version retaining the 1998 structure amid growing adoption in enterprise contexts.[1] No further textual modifications have occurred since, underscoring the document's design for enduring applicability despite advancements in cloud computing, mobile ecosystems, and artificial intelligence.[1] In 2020, OSI and community forums debated potential revisions to incorporate contemporary concerns like sustainability mandates or AI-specific freedoms, with proposals suggesting additions for data transparency or environmental compliance.[15] [16] These were ultimately rejected, prioritizing textual stability to preserve legal predictability and avoid fragmenting the global open source ecosystem, where over 1,000 licenses had been evaluated against the unchanged criteria.[15] This conservatism reflects OSI's rationale that the OSD's principles—rooted in practical freedoms rather than prescriptive updates—remain robust, even as separate initiatives like the Open Source AI Definition emerged without altering the core text.[17]Core Criteria
The Ten Criteria in Detail
The Open Source Definition (OSD), version 1.9 as maintained by the Open Source Initiative (OSI), specifies ten criteria that a software license must meet to qualify as open source. These criteria form the authoritative standard for OSI approval, requiring licenses to enable unrestricted access, modification, and redistribution while prohibiting discriminatory or restrictive clauses that undermine openness. Compliance is determined by the literal terms of the license text, ensuring predictability and verifiability in classification.[1] 1. Free Redistribution. This criterion mandates that the license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources, nor require a royalty or other fee for such sale. It ensures that open source software can be freely incorporated into larger distributions without financial barriers, promoting widespread dissemination without vendor lock-in.[1] 2. Source Code. The program must include source code and allow distribution in both source and compiled forms. If source code is not distributed with a product, a well-publicized means of obtaining it must exist for no more than a reasonable reproduction cost—preferably free Internet download—and the source must be the preferred form for modification by a programmer. Deliberately obfuscated code or intermediate forms like preprocessor outputs are prohibited. This provision guarantees that users can inspect, debug, and improve the software, distinguishing open source from proprietary binaries.[1] 3. Derived Works. The license must permit modifications and derived works, allowing their distribution under the same terms as the original software's license. This enables collaborative evolution of software, fostering innovation through community contributions without requiring relicensing for changes.[1] 4. Integrity of The Author’s Source Code. Restrictions on distributing modified source code are permitted only if the license allows "patch files" for build-time modifications and explicitly permits distribution of software built from such modified sources. Derived works may be required to use different names or version numbers. This balances authorial control over the original codebase with the need for extensibility, preventing unauthorized substitutions while allowing verifiable alterations.[1] 5. No Discrimination Against Persons or Groups. The license must not discriminate against any person or group of persons. This prohibits clauses targeting individuals, organizations, or demographics, ensuring universal applicability and preventing exclusionary practices that could fragment the user base.[1] 6. No Discrimination Against Fields of Endeavor. The license must not restrict use in specific fields, such as business or genetic research. It safeguards against limitations that confine software to non-commercial or approved domains, upholding its utility across diverse applications without ideological preconditions.[1] 7. Distribution of License. Rights granted by the license must extend to all recipients upon redistribution, without requiring additional agreements. This automates propagation of freedoms, avoiding administrative hurdles that could dilute openness in downstream distributions.[1] 8. License Must Not Be Specific to a Product. Rights must not depend on inclusion in a particular software distribution; extraction and standalone use or redistribution must preserve the original freedoms for all parties. This prevents bundling dependencies that erode portability and independence.[1] 9. License Must Not Restrict Other Software. The license cannot impose conditions on accompanying software, such as mandating it be open source. It isolates the licensed program's terms, allowing flexible integration with proprietary or other elements without coercive spillover.[1] 10. License Must Be Technology-Neutral. No provision may depend on specific technologies or interface styles. This ensures enduring applicability amid evolving tools and platforms, avoiding obsolescence tied to particular implementations.[1]Design Principles and Rationale
The Open Source Definition's criteria derive from the principle that unrestricted access to source code maximizes software evolution by enabling diverse contributors to inspect, modify, and redistribute it without barriers to entry or use. This facilitates causal chains of innovation where code derivatives proliferate, fostering competition and rapid adaptation as empirical patterns in software development demonstrate that open access correlates with accelerated feature development and bug resolution compared to proprietary silos. For instance, requirements for free redistribution and derived works ensure no royalties or modification restrictions impede the flow of improvements, prioritizing long-term collaborative gains over short-term proprietary controls.[18][1] Central to the rationale is a deliberate rejection of mandatory reciprocity mechanisms, such as copyleft, which could deter commercial entities from building upon open code due to enforced openness of their extensions. By permitting permissive licenses that allow proprietary forks or integrations, the OSD accommodates real-world incentives for investment, recognizing that hybrid models—where open cores support closed enhancements—have empirically driven widespread adoption and sustainability in projects like operating systems and libraries. This avoids ideological mandates, focusing instead on deployability to broaden participation and market penetration.[18] Provisions like non-discrimination against fields of endeavor address pragmatic IP constraints, ensuring licenses do not impose use limitations akin to patent exclusions, thereby safeguarding usability in commercial, research, or applied contexts. Such criteria evolved to counter emerging threats from patent assertions in the late 1990s and early 2000s, when explicit grants in compatible licenses became standard to affirm non-restrictive rights without diluting core freedoms. This balances innovation-enabling openness against legal realities, prioritizing verifiable interoperability over absolutist purity.[18][1]License Compliance and Approval
OSI Approval Process
The Open Source Initiative (OSI) maintains a structured license approval process to evaluate proposed licenses against the Open Source Definition (OSD), ensuring they permit free use, modification, and distribution while aligning with community norms. Submissions begin with posting the license text to the license-review mailing list, where the proposer must affirm compliance with key OSD criteria—particularly those related to redistribution, derived works, and non-discrimination—and provide details such as a unique name, SPDX identifier, and, for new licenses, justification of any gaps not addressed by existing approved licenses.[19][20] Public discourse follows, requiring the submitter to engage with community feedback, clarify ambiguities, and demonstrate the license's broad reusability through examples of potential or existing adoption by multiple independent entities, thereby providing empirical evidence of practical compliance rather than theoretical assertions.[19][20] The OSI License Committee then reviews the discussion thread, seeking consensus on whether the license meets all OSD tenets within an initial 60-day period, which may be extended for complex cases or revisions. If consensus emerges, the committee recommends approval or rejection to the OSI Board of Directors, which conducts a final vote; decisions are announced publicly on the mailing list, with approved licenses added to the official OSI registry. This multi-stage, transparent mechanism, formalized through community input and board oversight, minimizes subjective bias by prioritizing documented evidence and collective scrutiny over individual judgments.[19] Since its inception in 1998, the OSI has approved more than 100 licenses via this process, reflecting a deliberate restraint against proliferation by favoring reusable standards over bespoke variants. Post-2020 updates have enhanced procedural clarity, including refined submission requirements and categorization guidelines, amid increased scrutiny of submissions related to emerging domains like AI models and datasets. These changes underscore a heightened emphasis on transparency, as the OSI has separately advanced an Open Source AI Definition to address ambiguities in applying OSD principles to non-software artifacts, though traditional license approvals remain focused on software conformance.[4][21][22]Examples of Compliant and Non-Compliant Licenses
The MIT License, a permissive license approved by the Open Source Initiative (OSI) in 1999, complies with the Open Source Definition (OSD) by allowing unrestricted redistribution, modification, and commercial use, subject only to retaining the original copyright notice and disclaimer.[23] Similarly, the Apache License 2.0, OSI-approved since 2004, meets OSD criteria through provisions for source code distribution, derived works, and explicit patent licenses, while prohibiting patent retaliation against contributors; it powers major projects like the Android operating system.[24] The GNU General Public License (GPL) versions 2.0 and 3.0, classified as strong copyleft licenses and OSI-approved (GPLv2 in 1999, GPLv3 in 2007), conform to the OSD despite requiring derivatives to adopt the same license terms, as they ensure source availability and avoid discrimination against persons or fields of endeavor.[25] In contrast, licenses with non-commercial restrictions, such as those incorporating Creative Commons Non-Commercial (NC) clauses (e.g., CC BY-NC), fail OSD criterion 5 by discriminating against commercial fields of use, rendering them unsuitable for open source designation despite OSI approval of unmodified CC0.[1] The Server Side Public License (SSPL), introduced by MongoDB in 2018, was rejected by the OSI in 2019 for violating multiple OSD criteria, including requirements for additional service-level obligations on distributors (e.g., cloud providers) that hinder free redistribution and impose field-specific burdens beyond software modification.[19] Even OSD-compliant licenses like the GPL face practical enforcement challenges, as evidenced by Software Freedom Conservancy's litigation over BusyBox—a GPL-licensed utility. In December 2009, suits were filed against Best Buy, Samsung, Westinghouse, and others for distributing BusyBox in devices without providing required source code, leading to settlements, financial penalties, and a 2010 U.S. court injunction mandating cessation of violations; these cases underscore gaps in automatic compliance, relying on copyright holders for proactive legal remedies rather than inherent mechanisms.[26][27]Debian-Legal and Related Compliance Tests
The debian-legal mailing list, active since the late 1990s, enables Debian contributors to debate software legality, with a focus on vetting licenses against the Debian Free Software Guidelines (DFSG) for main archive inclusion.[28] These discussions apply DFSG-derived tests informally but rigorously to packaging decisions, serving as an ongoing practical benchmark for licenses' alignment with the Open Source Definition (OSD), which adapts the 1997 DFSG.[8] Debian-legal emphasizes tests ensuring licenses avoid post-distribution restrictions, such as the Tentacles of Evil test prohibiting authors from clawing back freedoms, and the Desert Island test verifying operability without external contact.[29]- Field-of-use neutrality: Licenses imposing domain-specific limits, like barring commercial use, violate DFSG principle 6 and are rejected from main, directing them to non-free; this mirrors OSD criterion 6 by demanding unrestricted application across endeavors.[29][30]
- Patent grants: Absent systematic patent audits due to feasibility issues, licenses failing to preclude rights revocation via patent claims or lacking implicit/explicit grants render software non-free, aligning with Debian's anti-patent stance.[29][31]
- Endorsement clauses: Overly broad prohibitions on implying endorsement or mandates for user actions (e.g., notifications) fail freedom tests, as seen in rejections like the Open Publication License, preventing encumbrances on derivative works.[29][30]