Hubbry Logo
The Open Source DefinitionThe Open Source DefinitionMain
Open search
The Open Source Definition
Community hub
The Open Source Definition
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
The Open Source Definition
The Open Source Definition
The Open Source Definition
View on Wikipedia
from Wikipedia

The Open Source Definition (OSD) is a policy document published by the Open Source Initiative in 1998[1]. Derived from the Debian Free Software Guidelines written by Bruce Perens, the definition is the most common standard for open-source software. The definition has ten criteria, such as requiring freely accessed source code and granting the open-source rights to everyone who receives a copy of the program. Covering both copyleft and permissive licenses, it is effectively identical to the definition of free software, but motivated by more pragmatic and business-friendly considerations. The Open Source Initiative's board votes on proposals of licenses to certify that they are compliant with the definition, and maintains a list of compliant licenses on its website. The definition has been adapted into the Open Knowledge Foundation's Open Definition for open knowledge and into open hardware definitions.

History

[edit]

There have been several attempts to define open source and free software. Amongst the earliest was Free Software Foundation's Free Software Definition, which then defined as the three freedoms of Free Software (Freedom Zero was added later). Published versions of FSF's Free Software Definition existed as early as 1986, having been published in the first edition of the (now defunct) GNU's Bulletin.[2]

Debian Free Software Guidelines

[edit]

The Debian Free Software Guidelines (DFSG) was first published together with the first version of the Debian Social Contract in July 1997.[3] The primary author was Bruce Perens, with input from the Debian developers during a month-long discussion on a private mailing list, as part of the larger Debian Social Contract. Perens was copied to an email discussion between Ean Schuessler (then of Debian) and Donnie Barnes of Red Hat, in which Schuessler accused Red Hat of never elucidating its social contract with the Linux community. Perens realized that Debian did not have any formal social contract either, and immediately started creating one. The (then) Three Freedoms, which preceded the drafting and promulgation of the DFSG, were unknown to its authors.[4]

The guidelines were:

  1. Free redistribution.
  2. Inclusion of source code.
  3. Allowing for modifications and derived works.
  4. Integrity of the author's source code (as a compromise).
  5. No discrimination against persons or groups.
  6. No discrimination against fields of endeavor, like commercial use.
  7. The license needs to apply to all to whom the program is redistributed.
  8. License must not be specific to a product.
  9. License must not restrict other software.
  10. Example licenses: The GNU GPL, BSD, and Artistic licenses are examples of licenses considered free.[3][5]

Open source

[edit]

As Netscape released the open-source Mozilla browser in 1998, Bruce Perens again drafted a set of open-source guidelines to go with the release.[6] It has been claimed that the Open Source Definition was created by re-titling the exact text of the DFSG.

A modified version of this definition was adopted by the Open Source Initiative (OSI) as the Open Source Definition.[7][8] The OSI uses the label "open source", rather than "free software", because it felt that the latter term had undesirable ideological and political freight, and it wanted to focus on the pragmatic and business-friendly arguments for open-source software.[7] It adopted a closed rather than membership-driven organizational model in order to draft the definition and work together with a wider variety of stakeholders than other free or open-source projects.[7]

Once the DFSG became the Open Source Definition, Richard Stallman saw the need to differentiate free software from open source and promoted the Free Software Definition.[9]

Debian diverges

[edit]

In November 1998, Ian Jackson and others proposed several changes in a draft versioned 1.4, but the changes were never made official. Jackson stated[10] that the problems were "loose wording" and the patch clause.

The Debian General Resolution 2004-003,[11] titled "Editorial amendments to the social contract", modified the Social Contract. The proposer Andrew Suffield stated:[12]

"The rule is 'this resolution only changes the letter of the law, not the spirit'. Mostly it changes the wording of the social contract to better reflect what it is supposed to mean, and this is mostly in light of issues that were not considered when it was originally written."

However, the change of the sentence "We promise to keep the Debian GNU/Linux Distribution entirely free software" into "We promise that the Debian system and all its components will be free" resulted in the release manager, Anthony Towns, making a practical change:[13]

"As [SC #1] is no longer limited to 'software', and as this decision was made by developers after and during discussion of how we should consider non-software content such as documentation and firmware, I don't believe I can justify the policy decisions to exempt documentation, firmware, or content any longer, as the Social Contract has been amended to cover all these areas."

This prompted another General Resolution, 2004–004,[14] in which the developers voted overwhelmingly against immediate action, and decided to postpone those changes until the next release (whose development started a year later, in June 2005).

Criteria

[edit]

Providing access to the source code is not enough for software to be considered "open-source".[15] The Open Source Definition requires that ten criteria be met:[16][7]

  1. Free redistribution[16]
  2. Source code must be accessible and the license must permit redistribution in the form of source code (rather than object code).[16] In order to modify the software, access to source code is required.[17]
  3. Derivative works must be allowed and able to be redistributed under the same licensing terms as the open-source product[16]
  4. The license may require that the original software be distributed intact, but only if modifications are able to be distributed as patches without restriction.[16][17]
  5. No discrimination between users[16]
  6. No discrimination between uses, including commercial use[16]
  7. Everyone who receives a copy of the program is granted all the open-source rights[16]
  8. The license must cover all the code, not a particular product or distribution.[16][17]
  9. There may not be restrictions on other software distributed at the same time[16]
  10. Technological neutrality—cannot restrict use to any particular technology.[16] For example, a license that requires a user to click a box agreeing to it is not free because the work cannot be distributed as a paper copy.[17]

The Open Source Definition is available under a Creative Commons (CC BY 4.0) license.[18] It covers both copyleft—where redistribution and derivative works must be released under a free license—and permissive licenses—where derivative works can be released under any license. It is part of the open source movement rather than the free software movement, and seeks to promote the availability of open-source software for anyone seeking to reuse it, even the makers of proprietary software.[7][19][17] It does not address warranty disclaimers, although these are very common in open-source software.[17] The definition does not specify a governance structure for open-source projects.[7]

Compliant licenses

[edit]

The criteria are used by the OSI to approve certain licenses as compatible with the definition, and maintain a list of compliant licenses. New licenses have to submit a formal proposal that is discussed by the OSI mailing list before it is approved or rejected by the OSI board. Seven approved licenses are particularly recommended by the OSI as "popular, widely used, or having strong communities":[20]

Application

[edit]

Software

[edit]

Most discussions about the DFSG happen on the debian-legal mailing list. When a Debian Developer first uploads a package for inclusion in Debian, the ftpmaster team checks the software licenses and determines whether they are in accordance with the social contract. The team sometimes confers with the debian-legal list in difficult cases.

Non-"software" content

[edit]

The DFSG is focused on software, but the word itself is unclear—some apply it to everything that can be expressed as a stream of bits, while a minority considers it to refer to just computer programs. Also, the existence of PostScript, executable scripts, sourced documents[clarification needed], etc., greatly muddies the second definition. Thus, to break the confusion, in June 2004 the Debian project decided to explicitly apply the same principles to software documentation, multimedia data and other content. The non-program content of Debian began to comply with the DFSG more strictly in Debian 4.0 (released in April 2007) and subsequent releases.

GFDL

[edit]

Much documentation written by the GNU Project, the Linux Documentation Project and others licensed under the GNU Free Documentation License contain invariant sections, which do not comply with the DFSG. This assertion is the end result of a long discussion and the General Resolution 2006-001.[21]

Due to the GFDL invariant sections, content under this license must be separately contained in an additional "non-free" repository which is not officially considered part of Debian.

Multimedia files

[edit]

It can be sometimes hard to define what constitutes the "source" for multimedia files, such as whether an uncompressed image file is the source of a compressed image and whether the 3D model before ray tracing is the source for its resulting image.

[edit]

The debian-legal mailing list subscribers have created some tests to check whether a license violates the DFSG. The common tests (as described in the draft DFSG FAQ)[22] are the following:

  • "The Desert Island test". Imagine a castaway on a desert island with a solar-powered computer. This would make it impossible to fulfill any requirement to make changes publicly available or to send patches to some particular place. This holds even if such requirements are only upon request, as the castaway might be able to receive messages but be unable to send them. To be free, software must be modifiable by this unfortunate castaway, who must also be able to legally share modifications with friends on the island.
  • "The Dissident test". Consider a dissident in a totalitarian state who wishes to share a modified bit of software with fellow dissidents, but does not wish to reveal the identity of the modifier, or directly reveal the modifications themselves, or even possession of the program, to the government. Any requirement for sending source modifications to anyone other than the recipient of the modified binary—in fact, any forced distribution at all, beyond giving source to those who receive a copy of the binary—would put the dissident in danger. For Debian to consider software free it must not require any such excess distribution.
  • "The Tentacles of Evil test". Imagine that the author is hired by a large evil corporation and, now in their thrall, attempts to do the worst to the users of the program: to make their lives miserable, to make them stop using the program, to expose them to legal liability, to make the program non-free, to discover their secrets, etc. The same can happen to a corporation bought out by a larger corporation bent on destroying free software in order to maintain its monopoly and extend its evil empire. To be free, the license cannot allow even the author to take away the required freedoms.

Reception

[edit]

The Open Source Definition is the most widely used definition for open-source software,[23] and is often used as a standard for whether a project is open source.[18] It and the official definitions of free software by the Free Software Foundation (FSF) essentially cover the same software licenses.[7][24] Nevertheless, there is a values difference between the free software and open source movements: the former is more based on ethics and values, the latter on pragmatism.[7]

Derived definitions

[edit]

The Open Knowledge Foundation's Open Definition is substantially derivative of the Open Source Definition.[25]

The Open Source Hardware Statement of Principles is adapted from the Open Source Definition.[26][23]

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

The Open Source Definition

View on Grokipedia
from Grokipedia
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 (OSI). Derived from the Debian Free Software Guidelines, it prioritizes practical permissions for redistribution, modification, and access to while prohibiting discriminatory restrictions. 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. 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. 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. 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 . Critics, including of the , 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 enclosures, potentially allowing "" code to fuel restrictive products. This tension reflects a core divergence: as a development methodology versus as a defense of user autonomy.

History

Origins in Debian Free Software Guidelines

The Debian Free Software Guidelines (DFSG) originated as a set of criteria for determining what constitutes within the project. Drafted primarily by , the guidelines were refined through a month-long discussion among developers in June 1997 before being incorporated as Section 2 of the , version 1.0, ratified on July 5, 1997. 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. 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 . The adaptation occurred in early 1998, amid growing commercial interest in 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 . Unlike the Free Software Foundation's emphasis on ethical imperatives, the DFSG's formulation favored empirical enforceability of , influencing the OSD's role as a certification standard for licenses enabling collaborative development without ideological barriers. This foundation underscored a shift toward causal mechanisms of through unrestricted access and derivative works, rather than appeals to user .

Formation of the Open Source Initiative

The (OSI) was established in late February 1998 as a dedicated to promoting through the stewardship of a standardized definition and license certification process. It was cofounded by , then Debian project leader, and , author of , who served as OSI's initial president and vice president, respectively. 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 Foundation's (FSF) emphasis on user freedoms as moral imperatives. The OSI's creation stemmed from a strategic effort to reframe ""—a term associated with Richard Stallman's FSF and its philosophical commitments—as "," highlighting practical benefits like collaborative development and to appeal to businesses wary of ideological connotations. 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. 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. In March 1998, the OSI released version 1.0 of the OSD, establishing ten criteria for licenses to qualify as , including free redistribution, derived works allowance, and integrity preservation. Early objectives centered on creating an authoritative list of compliant licenses to reduce legal ambiguity, certify software against the OSD, and build trust through education and advocacy, thereby accelerating 's integration into enterprise environments. This certification role positioned OSI as a steward independent of any single project or ideology, contrasting with the FSF's copyleft-focused approach.

Key Versions and Revisions

The Open Source Definition (OSD) was first published by the (OSI) in February 1998, adapted from the Debian Free Software Guidelines by removing Debian-specific references while preserving core principles of software freedom. This initial version established ten criteria for licenses, emphasizing free redistribution, availability, and derived works without restrictions on commercial use or modification. Subsequent iterations through version 1.3 in 1999 introduced minor editorial refinements for clarity, such as explicit language on and non-endorsement requirements, but avoided substantive alterations to maintain interpretive consistency. 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 grants to ensure licenses explicitly allow 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. 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. No further textual modifications have occurred since, underscoring the document's design for enduring applicability despite advancements in , mobile ecosystems, and . In 2020, OSI and community forums debated potential revisions to incorporate contemporary concerns like mandates or AI-specific freedoms, with proposals suggesting additions for data transparency or environmental compliance. These were ultimately rejected, prioritizing textual stability to preserve legal predictability and avoid fragmenting the global ecosystem, where over 1,000 licenses had been evaluated against the unchanged criteria. 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 AI Definition emerged without altering the core text.

Core Criteria

The Ten Criteria in Detail

The Open Source Definition (OSD), version 1.9 as maintained by the (OSI), specifies ten criteria that a must meet to qualify as . 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. 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 can be freely incorporated into larger distributions without financial barriers, promoting widespread dissemination without . 2. Source Code. The program must include and allow distribution in both source and compiled forms. If is not distributed with a product, a well-publicized means of obtaining it must exist for no more than a reasonable cost—preferably free Internet download—and the source must be the preferred form for modification by a . Deliberately obfuscated code or intermediate forms like outputs are prohibited. This provision guarantees that users can inspect, debug, and improve the software, distinguishing from binaries. 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. 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. 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. 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. 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. 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. 9. License Must Not Restrict Other Software. The license cannot impose conditions on accompanying software, such as mandating it be . It isolates the licensed program's terms, allowing flexible integration with or other elements without coercive spillover. 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.

Design Principles and Rationale

The Open Source Definition's criteria derive from the principle that unrestricted access to maximizes software evolution by enabling diverse contributors to inspect, modify, and redistribute it without or use. This facilitates causal chains of where code derivatives proliferate, fostering competition and rapid adaptation as empirical patterns in demonstrate that correlates with accelerated feature development and bug resolution compared to 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 controls. Central to the rationale is a deliberate rejection of mandatory reciprocity mechanisms, such as , which could deter commercial entities from building upon open code due to enforced openness of their extensions. By permitting permissive licenses that allow 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 in projects like operating systems and libraries. This avoids ideological mandates, focusing instead on deployability to broaden participation and . Provisions like non-discrimination against fields of endeavor address pragmatic IP constraints, ensuring licenses do not impose use limitations akin to exclusions, thereby safeguarding usability in commercial, research, or applied contexts. Such criteria evolved to counter emerging threats from assertions in the late and early , 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 over absolutist purity.

License Compliance and Approval

OSI Approval Process

The (OSI) maintains a structured approval 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 , 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. 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. 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 , which conducts a final vote; decisions are announced publicly on the , 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. Since its inception in , the OSI has approved more than 100 licenses via this process, reflecting a deliberate restraint against proliferation by favoring reusable standards over 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.

Examples of Compliant and Non-Compliant Licenses

The , a permissive license approved by the (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. Similarly, the Apache License 2.0, OSI-approved since 2004, meets OSD criteria through provisions for distribution, derived works, and explicit patent licenses, while prohibiting patent retaliation against contributors; it powers major projects like the Android operating system. The GNU General Public License (GPL) versions 2.0 and 3.0, classified as strong 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. In contrast, licenses with non-commercial restrictions, such as those incorporating 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. The , introduced by 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. Even OSD-compliant licenses like the GPL face practical enforcement challenges, as evidenced by Software Freedom Conservancy's litigation over —a GPL-licensed utility. In December 2009, suits were filed against , , Westinghouse, and others for distributing in devices without providing required , leading to settlements, financial penalties, and a 2010 U.S. court mandating cessation of violations; these cases underscore gaps in automatic compliance, relying on copyright holders for proactive legal remedies rather than inherent mechanisms. 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. 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. 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.
  • 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.
  • Patent grants: Absent systematic audits due to feasibility issues, licenses failing to preclude rights revocation via claims or lacking implicit/explicit grants render software non-free, aligning with Debian's anti- stance.
  • 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.
These tests yield empirical outcomes like excluding ambiguous licenses (e.g., v3.91 despite MIT-like terms due to restrictive intent) and sustaining coherence by prioritizing clear freedoms, with decisions informing OSI precedents through shared DFSG roots.

Applications and Scope

Primary Use in Software

The Open Source Definition (OSD) establishes criteria for software licenses that promote the free redistribution, modification, and study of , forming the foundational framework for (OSS) development. By requiring licenses to permit derived works and ensure availability without , the OSD enables collaborative coding practices central to software . These provisions allow developers to inspect, , and extend projects, fostering iterative improvements through contributions. In practice, the OSD underpins major software projects like the , licensed under the GNU License (GPL), which complies with all ten OSD criteria. This compliance has supported the kernel's evolution via thousands of contributors submitting patches and forks, resulting in widespread adoption; for instance, 61.4% of large enterprises ran at least one mission-critical application on Linux-based systems as of 2025. Such ecosystems thrive on the OSD's mandates for non-discriminatory distribution and technology neutrality, which prevent restrictions that could hinder integration into diverse software stacks. The OSD also accommodates hybrid development models, such as open core, where a permissive OSS base (meeting OSD requirements for source access and derived works) pairs with extensions. Examples include GitLab's core repository under the and MongoDB's server under the (SSPL), both initially OSD-compliant in their open components to attract contributions while monetizing add-ons. This model leverages the OSD's allowance for integrity protections on author's code, enabling vendors to control enhancements without violating core freedoms. A notable boundary in OSD-compliant software arises with software-as-a-service (SaaS) deployments, where licenses like the GPL permit server-side use without mandating source disclosure to remote users, creating an "." This stems from the OSD's focus on distribution rather than network access, allowing providers to offer OSS under cloud terms without full reciprocity, though licenses like the AGPL extend to close this gap while remaining OSD-approved.

Extensions to Hardware, Data, and AI

The principles of the Open Source Definition (OSD) have been adapted to open hardware, where designs for physical artifacts must be made publicly available to enable study, modification, distribution, and fabrication. The Open Source Hardware Definition, maintained by the Open Source Hardware Association (OSHWA) since its initial draft in 2010, mirrors OSD criteria by requiring documentation sufficient for replication, non-discriminatory licensing, and allowance for derived works, applied to schematics, PCB layouts, and bill of materials. Projects such as Arduino exemplify this extension, with hardware designs certified under Creative Commons Attribution-ShareAlike licenses that permit commercial production and modifications while preserving openness. Extensions to data and (AI) build on OSD by addressing unique challenges like model opacity and dataset provenance. In 2024, the (OSI) released version 1.0 of the Open Source AI Definition (OSAID), which applies OSD freedoms—use without permission, study via access to components, modification through preferred forms, and distribution—to AI systems including models, code, weights, and training infrastructure. OSAID mandates "sufficiently detailed information" about training data, such as curation processes and sources, to facilitate verification and adaptation, countering the "" nature of many AI systems where training details remain undisclosed. For datasets, this implies documentation enabling independent replication, though full data release is not required, distinguishing it from software mandates. OSI's 2025 strategic roadmap reinforces these extensions by establishing a multilateral to track AI practices, certify compliant licenses, and promote global standards, while upholding the OSD's integrity for software without conflating domains. This approach prioritizes empirical verifiability in AI components, such as model parameters exceeding billions in scale (e.g., in systems like Llama), to sustain collaborative innovation amid rapid AI advancement.

Limitations and Boundary Cases

The Open Source Definition (OSD) faces empirical constraints when applied to documentation and multimedia, primarily due to license features incompatible with unrestricted modification. The GNU Free Documentation License (GFDL), designed for manuals and texts, allows authors to designate "invariant sections" that recipients cannot alter or omit, directly conflicting with OSD criterion 3, which mandates allowing derived works without added restrictions. This provision drew criticism for restricting derivative freedoms, as noted in Debian's general resolution rejecting GFDL-covered works for their main archive, citing invariant sections alongside other issues like required digital signatures as barriers to free redistribution. Such incompatibilities manifested in practical boundary cases for projects. GFDL version 1.3, published 2008, introduced an "exit clause" permitting certain GFDL-licensed materials—such as content without cover texts or invariant sections—to migrate to Attribution-ShareAlike 3.0 (CC BY-SA) by August 1, 2009, addressing persistent interoperability problems with ecosystems. This adjustment enabled relicensing efforts but highlighted how documentation-specific invariants dilute OSD's emphasis on full modifiability, leading to hybrid licensing as a rather than seamless compliance. In non-software domains like datasets and AI models, OSD's requirement for "preferred form for making modifications" (criterion 2) creates ambiguities, as these lack software's clear distinction between editable source and output. For datasets, "source" is ill-defined—raw collections may involve proprietary or privacy-protected elements unamenable to open release, fostering inconsistent adoption where processed is shared but origins remain opaque. The (OSI) has grappled with this in developing an AI Definition, identifying confusion over " " in drafts, where training datasets for models are often withheld due to legal constraints, undermining verifiable . Proposals within OSI discussions separate "source " openness from processing details, yet emphasize that incomplete disclosure violates OSD's intent, as users cannot fully audit or replicate causal inputs. Hardware extensions reveal further limitations, as OSD presumes digital forkability, but physical designs demand fabrication resources, eroding practical enforceability. The Open Source Hardware Association (OSHWA) adapts OSD via its definition, requiring licensed design files, manufacturing instructions, and tools for study, modification, and distribution, yet surveys indicate challenges in academia and industry, including incomplete and barriers to prototyping derivatives. Without software's low-cost modularity, these boundary cases risk superficial openness, where shared schematics do not guarantee causal control over production chains, leading to uneven collaborative outcomes.

Comparison to Free Software Definition

Structural and Philosophical Similarities

The Open Source Definition (OSD) and the (FSD) exhibit structural similarities rooted in their common origins in the Debian Free Software Guidelines (DFSG), a set of principles drafted in 1997 by for Debian's licensing policy. The OSD, first published by the in 1998, was explicitly derived from the DFSG, adapting its criteria with minimal changes beyond terminology, such as replacing "" with "." The FSD, outlined by of the in 1986 and refined over time, influenced the DFSG through shared emphases on essential user freedoms, creating a foundational overlap that ensures broad compatibility in core requirements. At the level of specific freedoms, the OSD's first six criteria closely mirror the FSD's four essential freedoms: the freedom to run the program (OSD criterion 6, no discrimination against fields of endeavor), to study and modify it (OSD criteria 2 and 3, requiring source code distribution and allowing derived works), and to redistribute copies or modified versions (OSD criteria 1 and 3, permitting free redistribution and derivative distribution). These provisions enable unmodified source code access, modification for derived works, and redistribution without royalties or fees, forming a practical framework that supports peer review, debugging, and iterative enhancement in both definitions. Philosophically, both definitions presuppose that unrestricted user access to is a prerequisite for empirical verification of software and subsequent improvements, prioritizing transparency as a mechanism for collective reliability over opacity. This shared rationale underpins the empirical observation that the majority of the over 80 OSI-approved licenses as of 2023 also qualify as under FSF criteria, facilitating dual classification for projects like the and without inherent conflict in baseline permissions.

Key Divergences in Requirements

The Open Source Definition (OSD) explicitly requires licenses to be technology-neutral, stipulating in its tenth criterion that they must not depend on any particular technology or style of interface, thereby accommodating a broad range of implementation approaches without favoring specific formats or protocols. In contrast, (FSD) lacks such an explicit provision, focusing instead on universal user freedoms without mandating neutrality across technological paradigms. Regarding patents, the OSD permits non-discriminatory patent grant clauses in , consistent with its sixth criterion prohibiting discrimination against fields of endeavor, which allows contributors to explicitly essential patents alongside the software as long as access is not restricted based on use case. such as Apache 2.0, approved under the OSD, include such grants to mitigate litigation risks while ensuring broad usability. The FSD, however, does not directly address patent , leaving it to individual implementations like the , which incorporates defensive patent protections but imposes stricter conditions on patent assertions tied to distribution. The OSD emphasizes pragmatic distribution and modification rights through its criteria on redistribution, source code availability, and derived works, without explicitly requiring unrestricted "freedom to run" the software for any purpose—a core element of the FSD's zeroth freedom, which ethically mandates user control over execution regardless of intent or hardware. This distributional focus in the OSD assumes use rights implicitly via non-discrimination clauses but permits scenarios where runtime restrictions might arise indirectly, differing from the FSD's user-centric insistence on inviolable operational autonomy. While is optional under the OSD, which approves both permissive licenses like the BSD series—allowing derivatives to be relicensed proprietarily—and ones, the FSD supports strong variants such as the GPL as a preferred mechanism to perpetuate freedoms in derivatives, though it does not mandate for compliance. This flexibility in the OSD enables broader without enforcing reciprocal sharing, contrasting with the FSD's foundational alignment toward mechanisms that safeguard long-term openness in modified works.

Implications for Users and Developers

The Definition's (OSD) pragmatic criteria enable developers to integrate open source components into systems without mandatory reciprocity for modifications, fostering commercial viability as demonstrated by Android's framework, which employs the Apache 2.0 license to support services atop an open base, powering over 3 billion active devices as of 2023. This contrasts with the Definition's (FSD) insistence on comprehensive user freedoms across the entire software stack, which can impose adoption barriers for developers wary of viral licensing obligations that erode competitive edges in market-driven environments. Empirical studies indicate that such flexibility correlates with higher corporate investment, as firms leverage OSD-compliant licenses to accelerate development cycles without full disclosure mandates. For users, OSD's allowance of hybrid models—combining open cores with closed extensions—expands access to robust, scalable software ecosystems, verifiable through GitHub metrics showing over 420 million repositories and billions of contributions annually, predominantly under OSI-approved licenses that prioritize usability over ideological purity. This pragmatic orientation supports diverse applications, from cloud infrastructure to mobile OS, where users gain reliability from community-vetted code alongside vendor-provided enhancements, unlike FSD's potential constraints on proprietary interoperability that might limit ecosystem breadth. Data from OSS platforms reveal that market-aligned incentives under OSD drive sustained participation, with contributor activity linking to firm-level innovation and venture formation, underscoring causal pathways from permissive structures to real-world utility. Overall, the divergences yield OSD's superior correlation with broad-scale , as permissive frameworks incentivize proprietary augmentation and rapid , empirically outpacing FSD's freedoms in generating user-accessible advancements; analyses of engagement affirm that economic motivations amplify collaborative outputs beyond ethical mandates alone. This market realism debunks reliance on unrestricted freedoms as self-sustaining, highlighting how OSD's balance sustains developer ecosystems and user benefits through aligned incentives rather than prescriptive universality.

Criticisms and Controversies

Ideological Critiques from Free Software Proponents

Richard Stallman, founder of the Free Software Foundation (FSF), articulated a core ideological critique of the Open Source Definition (OSD) in his 1998 essay "Why Open Source Misses the Point of Free Software," arguing that it "misses the point" by emphasizing practical advantages like improved reliability and collaboration over the moral imperative of ensuring users' essential freedoms. Stallman contended that the OSD's focus on utility permits software that grants technical permissions but allows proprietary restrictions or unethical uses, such as surveillance or discrimination, without requiring developers to oppose them on principle, thereby diluting the ethical foundation of software freedom. Free software advocates further criticize the OSD for enabling "" branding on licenses that fail to protect against practices like , where is embedded in hardware that uses cryptographic signatures to block modified versions from running, effectively nullifying the user's freedom to modify and execute the program for any purpose. Unlike the FSF's version 3, released in 2007 with explicit anti-tivoization clauses via installation freedoms, the OSD lacks requirements to safeguard against such hardware-level restrictions, allowing companies to exploit code while restricting user control. Despite these objections, indicates that the OSD's pragmatic criteria have facilitated broader adoption than the FSF's stricter ethical demands; for instance, OSI-approved licenses underpin the majority of packages in ecosystems like and PyPI, where over 90% of projects use permissive or weakly terms rather than FSF-preferred strong copyleft, suggesting that ideological rigidity may impede diffusion relative to the OSD's flexibility.

Practical and Economic Shortcomings

Despite widespread adoption of , where 97% of scanned codebases in 2025 contained components, persistent vulnerabilities arise from fragmented and under-resourced maintenance. Many projects rely on volunteer-led coordination without centralized oversight, leading to delayed patching of known flaws; for instance, developers frequently incorporate third-party packages for speed but neglect upgrades, exacerbating risks like unaddressed dependency vulnerabilities. This structure, inherent to the Open Source Definition's emphasis on permissive distribution freedoms rather than mandatory , results in ongoing exposure, as evidenced by the prevalence of attacks targeting poorly maintained components in 2025. Economically, the Open Source Definition enables a freeloading dynamic where corporations derive substantial value from community-developed code without equivalent reciprocal investment, overburdening volunteer maintainers. In 2025, reports highlighted maintainer burnout as a systemic issue, with volunteers handling disproportionate workloads amid rising project demands, while firms like those in profit from stable without core upkeep. This imbalance strains resources, as unpaid labor sustains ecosystems valued in billions, yet leads to project abandonment or reduced security updates when maintainers exit due to exhaustion. The definition's lack of provisions for sustainable models perpetuates this, allowing commercial entities to internalize benefits while externalizing maintenance costs onto individuals. The Open Source Definition proves ineffective at delineating true , facilitating "openwashing" where entities apply the label to or restrictively controlled offerings, eroding its practical utility. Examples include AI firms releasing models with weights under permissive terms but withholding training data or imposing usage limits, misleading users about modifiability despite OSI-approved . This boundary failure stems from the definition's focus on criteria without robust enforcement against misrepresentations, allowing superficial compliance to mask underlying controls and diluting trust in certified projects.

Corporate Influence and "Openwashing"

The Open Source Initiative's policy of approving a diverse array of licenses—over 80 as of 2023—has facilitated corporate submissions that tailor terms to proprietary ecosystems, enabling firms like Amazon Web Services to contribute code under permissive licenses while integrating it with closed cloud infrastructures. Critics, including developers on platforms like Hacker News, contend that this proliferation undermines the open source commons by allowing Big Tech to dominate governance and direction, as seen in OSI's endorsements of licenses favoring platform lock-in over fully modular alternatives. Such influence is evident in AWS's substantial contributions to projects like Kubernetes, which, while OSD-compliant, often steer adoption toward Amazon's proprietary services, eroding interoperability in practice. "Openwashing" refers to the practice of corporations invoking rhetoric or partial compliance to mask control, thereby gaining legitimacy without full reciprocity. A prominent case involves 's of following its 2010 acquisition of ; relicensed commercial distributions of the (JDK) under subscription models with per-employee pricing starting in 2019, coupled with aggressive audits, while maintaining the community-driven under GPL terms that align with the OSD. This dual structure allows to claim OSD adherence for core elements to attract developers, yet enforces lock-in through extensions, binary updates, and legal pressures, prompting nearly 90% of surveyed users to consider migrating to pure open alternatives by 2025. Empirical analyses indicate that corporate involvement, despite these risks, causally accelerates development by injecting resources and expertise; for instance, firm contributions correlate with higher entrepreneurial growth and innovation rates in OSS ecosystems, as firms offset internal costs through labor while funding maintainers. Studies confirm that over half of commits in major projects originate from company-affiliated developers, yielding faster feature delivery and bug resolution compared to volunteer-only models, suggesting that pragmatic co-optation enhances overall velocity without necessitating ideological purity.

Reception and Impact

Widespread Adoption and Economic Effects

The Open Source Definition (OSD) underpins software that has achieved near-universal adoption in organizational settings. The 2025 State of Open Source Report indicates that 96% of surveyed organizations either increased or maintained their usage of open source software over the prior year, reflecting sustained reliance on OSD-compliant projects for core operations. This prevalence extends to : the , distributed under the GNU General Public License (compatible with OSD principles), powers 100% of the world's top 500 supercomputers as of 2025 and approximately 96% of the top one million web servers. Mobile and cloud ecosystems further demonstrate OSD's reach. Android, leveraging and licensed under the 2.0 (an OSD-approved license), commands over 70% of the global market share and supports more than 3.5 billion active devices. In , OSD-conforming tools like facilitate container orchestration across major providers, enabling scalable deployment of applications in hybrid and public environments. Economically, OSD-aligned generates substantial value through cost avoidance and enhanced productivity. A analysis estimates the demand-side value—the hypothetical cost to replicate widely used open source code—at $8.8 trillion annually for adopting firms. Complementary research from the attributes roughly $9 trillion in global economic contributions to , including innovations in AI and that bolster GDP growth. By permitting free access, modification, and redistribution, OSD reduces development barriers relative to models, enabling startups to rapidly and scale without prohibitive licensing fees. This causal mechanism supports higher innovation rates, as evidenced by venture-backed firms outperforming closed-source counterparts in growth metrics. Such dynamics have democratized software markets, allowing smaller entities to compete effectively and drive broader .

Derived Standards and Global Influence

The Open Source Hardware Definition, formulated in 1997 by shortly after authoring the Open Source Definition, extends its principles to physical designs by requiring documentation sufficient for replication, unrestricted modification, and distribution without royalties or fees. This framework underpins certifications by the Open Source Hardware Association, which has validated hundreds of designs globally since 2011, promoting collaborative hardware innovation in fields like and scientific instruments. In 2024, the adapted the Open Source Definition's core freedoms—use, study, modification, and distribution—into the Open Source AI Definition version 1.0, released on , requiring public access to AI model weights, code, datasets, and procedures to enable full and reuse. This standard addresses AI-specific challenges, such as opaque data, while maintaining compatibility with the original criteria to distinguish truly open systems from restrictive "open-weight" models. The Open Source Definition has shaped international policies emphasizing and software reuse, as seen in the European Commission's 2023 open source software strategy, which promotes and development aligned with OSI-approved licenses to reduce and enhance digital sovereignty. In contexts, it standardizes evaluations of component compliance, mitigating risks in global software ecosystems where constitutes up to 90% of production codebases, per industry analyses. Its pragmatic focus on permissive licensing has facilitated industry adoption over the Free Software Foundation's emphasis, enabling hybrid models in enterprise environments despite critiques from purists favoring stricter ideological controls.

Recent Developments and Ongoing Debates

In March 2025, the (OSI) released its strategic roadmap for the year, emphasizing support for the open source ecosystem through education, advocacy, and community-building initiatives without proposing alterations to the core criteria of the Open Source Definition (OSD). This approach prioritizes maintaining the OSD's stability to preserve long-standing trust among developers and users, as evidenced by analyses highlighting the risks of definitional fragmentation leading to competing standards. The roadmap addresses emerging challenges like AI integration by advancing the separate Open Source AI Definition (OSAID), ratified in late 2024, which extends OSD principles to AI systems but explicitly avoids modifying the original software-focused criteria. Debates surrounding the OSAID have intensified post-2024 , particularly over requirements for transparency in training and model weights, with critics arguing that incomplete disclosure undermines and favors interests of large tech firms. Proponents, including OSI affiliates, counter that mandating full could stifle in data-scarce domains, yet empirical reviews of AI project outcomes suggest that partial transparency still enables sufficient scrutiny without overhauling foundational freedoms. These tensions reflect broader unresolved questions on whether OSD-like criteria should evolve incrementally for non-software artifacts like datasets, or remain unaltered to avoid diluting its software-centric rigor. License proliferation persists as an ongoing concern, with over 400 approved s by 2025 complicating compliance and interoperability, prompting calls from industry analysts for simplification through consolidation to a core set of permissive and options. Counterarguments favor proliferation to address niche needs, such as clauses in newer licenses, though data from license usage surveys indicate that the top 10 licenses dominate 90% of projects, supporting incremental over radical reduction. Security initiatives, led by the Open Source Security Foundation (OpenSSF), have gained traction since 2023 to tackle maintenance crises, including the release of the Open Source Project Security Baseline in February 2025, which provides tiered best practices for and supply chain security. These efforts empirically demonstrate improved project resilience, with participating repositories showing 30-50% reductions in unpatched vulnerabilities, yet debates continue on funding models to sustain volunteer maintainers amid rising attack surfaces. funding discussions in 2024-2025 highlight tensions between corporate sponsorships, which risk "openwashing," and grants, with analyses revealing that diversified revenue streams—such as bounties and paid support—preserve OSD compliance while addressing burnout in 70% of underfunded projects.

References

  1. https://opensource.org/osd
  2. https://opensource.org/about/history-of-the-open-source-initiative
  3. https://www.debian.org/social_contract#guidelines
  4. https://opensource.org/licenses
  5. https://www.gnu.org/philosophy/open-source-misses-the-point.en.html
  6. https://www.gnu.org/philosophy/free-software-for-freedom.en.html
  7. https://www.debian.org/social_contract.1.0
  8. https://www.debian.org/social_contract
  9. https://perens.com/2017/09/26/on-usage-of-the-phrase-open-source/
  10. https://www.oreilly.com/openbook/opensources/book/perens.html
  11. https://opensource.org/blog/twenty-years-and-counting-2
  12. https://opensource.com/article/18/2/pivotal-moments-history-open-source
  13. https://opensource.org/about
  14. https://opensource.org/about/authority
  15. https://opensource.com/article/20/9/open-source-definition
  16. https://discourse.sustainoss.org/t/is-it-time-to-revise-the-open-source-definition/506
  17. https://opensource.org/blog/the-open-source-ai-definition-v-1-0-rc1-is-available-for-comments
  18. https://opensource.org/definition-annotated
  19. https://opensource.org/licenses/review-process
  20. https://opensource.org/blog/how-the-osi-checks-if-new-licenses-comply-with-the-open-source-definition
  21. https://opensourcewatch.beehiiv.com/p/open-source-initiative-improves-licensing-rules
  22. https://www.infoq.com/news/2024/11/open-source-ai-definition/
  23. https://opensource.org/license/mit
  24. https://opensource.org/license/apache-2-0
  25. https://opensource.org/license/gpl-2-0
  26. https://softwarefreedom.org/news/2009/dec/14/busybox-gpl-lawsuit/
  27. https://sfconservancy.org/news/2010/aug/03/busybox-gpl/
  28. https://lists.debian.org/debian-legal/
  29. https://people.debian.org/~bap/dfsg-faq.html
  30. https://www.debian.org/legal/licenses/
  31. https://www.debian.org/legal/patent
  32. https://www.amraandelma.com/linux-marketing-statistics/
  33. https://www.techtarget.com/searchitoperations/definition/open-core-model-open-core-software
  34. https://version-2.com/en/2024/10/exploring-the-differences-between-community-foss-open-core-and-commercial-oss/
  35. https://www.mend.io/blog/the-saas-loophole-in-gpl-open-source-licenses/
  36. https://www.revenera.com/blog/software-composition-analysis/understanding-the-saas-loophole-in-gpl/
  37. https://oshwa.org/definition/
  38. https://opensource.org/ai/open-source-ai-definition
  39. https://opensource.org/blog/the-open-source-initiative-announces-the-release-of-the-industrys-first-open-source-ai-definition
  40. https://juliaferraioli.com/blog/2024/on-open-source-ai/
  41. https://magazine.joomla.org/all-issues/march-2025/the-future-of-open-source-ai-the-osi-s-open-source-ai-definition-osaid
  42. https://opensource.org/blog/big-news-for-open-source-from-the-un-to-the-osi-new-directors
  43. https://www.debian.org/vote/2006/vote_001
  44. https://lwn.net/Articles/305892/
  45. https://www.gnu.org/licenses/fdl-1.3-faq.en.html
  46. https://opensource.org/blog/explaining-the-concept-of-data-information
  47. https://discuss.opensource.org/t/proposal-to-handle-data-openness-in-the-open-source-ai-definition-rfc/561
  48. https://discuss.opensource.org/t/rfc-separating-concerns-between-source-data-and-processing-information/568
  49. https://oshwa.org/wp-content/uploads/2022/02/OSHWA-Survey-Analysis.pdf
  50. https://2012.oshwa.org/challenges-of-open-source-consumer-products/
  51. https://www.gnu.org/philosophy/free-sw.en.html
  52. https://opensource.org/licenses/BSD-3-Clause
  53. https://www.hbs.edu/ris/download.aspx?name=24-040.pdf
  54. https://github.blog/news-insights/research/open-source-creates-value-but-how-do-you-measure-it/
  55. https://www.sciencedirect.com/science/article/pii/S0048733323001300
  56. https://pubsonline.informs.org/doi/10.1287/orsc.2023.18348
  57. https://arxiv.org/html/2411.05087v1
  58. https://www.sciencedirect.com/science/article/am/pii/S0048733324000039
  59. https://www.researchgate.net/publication/288665644_Movement_ideology_vs_user_pragmatism_in_the_organizational_adoption_of_open_source_software
  60. https://www.linuxfoundation.org/blog/blog/a-summary-of-census-ii-open-source-software-application-libraries-the-world-depends-on
  61. https://www.blackduck.com/blog/open-source-trends-ossra-report.html
  62. https://www.heeler.com/resource/the-broken-economics-of-open-source-security
  63. https://www.veracode.com/blog/software-supply-chain-attacks-in-2025/
  64. https://www.theregister.com/2025/09/23/openssf_open_source_infrastructure/
  65. https://news.itsfoss.com/open-source-infrastructure-is-breaking-down/
  66. https://www.linuxcareers.com/resources/blog/2025/06/exploitation-of-unpaid-labor-in-open-source-ecosystems/
  67. https://www.nytimes.com/2024/05/17/business/what-is-openwashing-ai.html
  68. https://flamingltd.com/what-is-open-washing/
  69. https://digitalcommons.law.uw.edu/cgi/viewcontent.cgi?article=1071&context=faculty-articles
  70. https://news.ycombinator.com/item?id=37121501
  71. https://sease.io/2024/07/openwashing-a-closer-look-at-transparency-in-open-source-ai.html
  72. https://www.mescomputing.com/news/4174893/oracles-controversial-stewardship-java-bad
  73. https://developers.slashdot.org/story/25/01/30/1617210/oracle-faces-java-customer-revolt-after-predatory-pricing-changes
  74. https://bura.brunel.ac.uk/bitstream/2438/6981/5/Fulltext.pdf
  75. https://www.researchgate.net/publication/333834702_On_Company_Contributions_to_Community_Open_Source_Software_Projects
  76. https://www.openlogic.com/blog/state-of-open-source-report-key-insights
  77. https://sqmagazine.co.uk/linux-statistics/
  78. https://www.sealevel.com/linux-os
  79. https://www.businessofapps.com/data/android-statistics/
  80. https://www.tekrevol.com/blogs/android-vs-ios-statistics/
  81. https://www.ibm.com/think/topics/kubernetes-use-cases
  82. https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4693148
  83. https://siliconangle.com/2025/06/26/linux-foundation-open-source-ai-opensourcesummit/
  84. https://oshwa.org/resources/brief-history-of-open-source-hardware-organizations-and-definitions/
  85. https://nyuengelberg.org/outputs/the-state-of-open-source-hardware-2021/
  86. https://commission.europa.eu/about/departments-and-executive-agencies/digital-services/open-source-software-strategy_en
  87. https://www.sonatype.com/state-of-the-software-supply-chain/2023/open-source-supply-and-demand
  88. https://openuk.uk/wp-content/uploads/2025/01/Open-Source-in-2025-What-Will-Matter-Most-This-Year-The-New-Stack.pdf
  89. https://www.theverge.com/2024/10/28/24281820/open-source-initiative-definition-artificial-intelligence-meta-llama
  90. https://thenewstack.io/the-case-against-osis-open-source-ai-definition/
  91. https://lwn.net/Articles/995159/
  92. https://www.mend.io/blog/top-open-source-licenses-explained/
  93. https://baseline.openssf.org/
  94. https://linuxsecurity.com/news/organizations-events/openssf-security-baseline-fortifies-open-source-projects
  95. https://licenseware.io/the-price-of-freedom-confronting-the-sustainability-crisis-in-open-source/
  96. https://thenewstack.io/open-source-in-2025-strap-in-disruption-straight-ahead/
Add your contribution
Related Hubs
User Avatar
No comments yet.