Open Source Foundations 2003-2026: From OSI to the Linux Foundation Empire

Open-source governance is the part of the open-source story that gets the least journalistic attention and the most consequential decisions. The licenses, the foundations, the contributor agreements, the trademark policies, the conflict of interest rules: none of it has the narrative appeal of a Linus Torvalds rant or a startup launch, and all of it shapes which projects survive contact with corporate adoption.

Between 2003 and 2026 the structures of open-source governance evolved through four roughly distinct phases. The first (1998-2003) was the license war, which produced the modern OSI Open Source Definition and the GPL vs MIT vs Apache vs BSD philosophical fault lines. The second (2004-2014) was foundation institutionalisation, in which the Apache Software Foundation, the Eclipse Foundation, and the Linux Foundation built the templates for project stewardship. The third (2015-2022) was corporate stewardship at scale, in which CNCF and similar bodies absorbed the cloud-native era’s project explosion. The fourth, still ongoing, is the source-available license movement (2018-2026), which is reopening arguments the OSI thought were settled.

Underneath all of it is the trademark, the funding question, and the contributor agreement, which together determine who actually gets to decide what counts as the project. This retrospective walks through the seven phases that produced the 2026 status quo.

The 1998-2003 OSI + FSF tension: copyleft vs permissive license wars

The Open Source Initiative was founded in February 1998 by Bruce Perens and Eric Raymond, with Christine Peterson coining the term “open source” earlier in the same year. The founding goal was to provide a more business-palatable alternative to Richard Stallman’s “free software” framing, which had been promoted by the Free Software Foundation since 1985 and was perceived (rightly or wrongly) as politically uncomfortable by enterprise procurement departments.

The OSI’s foundational document is the Open Source Definition, a ten-point criteria set adapted from the Debian Free Software Guidelines. The first version was published in 1998 and the current version (as of 2026) is substantially the same. The ten points cover free redistribution, source code availability, derived works, integrity of the author’s source, no discrimination against persons or groups, no discrimination against fields of endeavour, distribution of license, license not specific to a product, license not restricting other software, and license technology-neutral.

The license wars between 1998 and 2003 were largely between two camps:

• The copyleft camp, anchored by the GPL (GNU General Public License), which required derived works to be released under the same license. The pitch was that copyleft kept improvements in the commons and prevented proprietary forks. The criticism was that it constrained commercial use, especially in dynamic-linking and SaaS contexts where the GPL’s terms were ambiguous.
• The permissive camp, anchored by the BSD license, the MIT license, and (after 2004) the Apache 2.0 license. The pitch was that maximally permissive licenses produced wider adoption, more contribution, and less legal friction. The criticism was that permissive licenses allowed Amazon, Google and Microsoft to take open-source software, productise it as a managed service, and capture the value without contributing back.

The Apache 2.0 license, finalised in January 2004, became the practical compromise between the two camps. It was permissive (no copyleft), explicit about patent grants (an issue the BSD/MIT licenses did not address well), and corporate-counsel-friendly. By 2026 Apache 2.0 is the most-used open-source license in major repositories, by some counts surpassing GPL family licenses in active project share.

The other consequential 2003-era event was the GPL 3.0 drafting process, which started in 2005, finalised in June 2007, and produced a license that addressed software patents, anti-DRM provisions, and the “Tivoisation” issue (hardware that uses GPL software but refuses to run modified versions). The drafting was contentious, and a significant number of high-profile projects (notably the Linux kernel) chose to stay on GPL 2.0 rather than upgrade. GPL 3.0 is, in 2026, less widely adopted than its authors hoped, but it remains the default copyleft license for projects that want strong protections against patent litigation and DRM lock-in.

Apache Software Foundation: the BDFL-free governance template

The Apache Software Foundation (ASF) was incorporated as a non-profit in June 1999, growing out of the Apache HTTP Server project that had started in 1995. The foundation’s significance is governance: it produced the first widely-copied template for how an open-source project should be run without a benevolent dictator for life (BDFL).

The Apache way, as it became known, has several distinct components:

• Meritocracy. Contributors earn commit access by demonstrating sustained quality contributions. Committers are nominated by existing committers. PMCs (Project Management Committees) are responsible for project direction and consist of committers who have demonstrated broader project leadership.
• Consensus decision-making. Project decisions are made by Apache-style lazy consensus, with explicit voting (+1, 0, -1, with -1 requiring a justification) for contentious changes.
• Individual contributorship. ASF projects accept contributions from individuals, not from companies. A contributor’s employer is irrelevant to their standing in the project. This is operationalised through the Individual Contributor License Agreement (ICLA), which every committer signs.
• Trademark and asset stewardship. The ASF holds the trademarks and infrastructure for its projects, which prevents any single contributor or company from capturing the project’s brand.

The Apache way produced some of the most operationally durable open-source projects in the world: Apache HTTP Server, Tomcat, Cassandra, Kafka, Hadoop, Spark, Lucene, Solr. Many of them have outlasted their commercial sponsors, which is one of the explicit design goals.

The criticism of the Apache way is that the consensus decision-making is slow, the meritocratic gatekeeping can be opaque, and the individual-contributor model produces projects that are hard for companies to coordinate on. Several large companies (notably Databricks with Spark, and the various Hadoop vendors with the broader Hadoop ecosystem) eventually built parallel commercial governance structures alongside the Apache projects to move faster.

The ASF model remains, in 2026, the gold-standard template for projects that want to avoid corporate capture. It is also the template most often quoted, and least often actually implemented, by smaller foundations.

Eclipse Foundation 2004 + the IBM-led foundation playbook

The Eclipse Foundation was established in February 2004 as a spin-out from IBM, which had been the primary sponsor of the Eclipse IDE since 2001. The Eclipse foundation’s significance is that it was the first major open-source foundation engineered explicitly as a corporate consortium rather than an individual-contributor meritocracy.

The Eclipse template includes:

• Strategic, contributing and associate membership tiers, each with a fee structure and different governance rights. Strategic members get board seats; contributing members get committer rights; associate members get participation rights.
• Eclipse Public License (EPL), a weak-copyleft license designed to be commercially friendly while still requiring contribution of derived works back to the project.
• Corporate contributor license agreements alongside individual ones. The CLA acknowledges that the contributor may be acting on behalf of an employer.
• A development process documented as the Eclipse Development Process, which formalises release planning, IP review, and project lifecycle phases (proposal, incubation, mature, archive).

The Eclipse Foundation has produced and stewarded a wide range of projects: the Eclipse IDE itself, Jakarta EE (the rebranded Java EE after Oracle transferred stewardship in 2017), MicroProfile, the open-source Theia editor framework (used by Gitpod and others), and the Eclipse Modeling projects. The foundation moved its legal home from Delaware to Brussels in 2020, becoming a Belgian non-profit (AISBL) for European data protection and antitrust reasons.

The Eclipse model influenced the Linux Foundation and CNCF templates, which both adopted versions of the membership tier structure and the corporate-friendly CLA. It also normalised the idea that an open-source foundation could be funded primarily through corporate membership fees rather than through donations or services revenue.

Linux Foundation 2007: from kernel stewardship to ecosystem empire

The Linux Foundation was formed in January 2007 through a merger of the Open Source Development Labs (OSDL, founded 2000) and the Free Standards Group (FSG, founded 1998). Its founding purpose was narrow: provide neutral stewardship for the Linux kernel, employ Linus Torvalds and a small number of other senior maintainers, and protect the kernel from corporate capture.

What the Linux Foundation became is substantially larger than its original mandate. As of 2026 it hosts more than 1,000 active projects, including the Linux kernel, but also Node.js (after the io.js fork was reconciled in 2015), Hyperledger (blockchain projects, since 2016), the Cloud Native Computing Foundation (the largest sub-foundation, hosting Kubernetes), the LF AI & Data Foundation (since 2018), the OpenJS Foundation (since 2019), the Academy Software Foundation (since 2018), and a wide range of industry-vertical foundations.

The Linux Foundation business model is essentially a fee-for-service governance platform. Companies that want to neutrally steward an open-source project bring it to the LF, pay a setup fee, agree to a foundation-specific governance charter, and then pay annual membership fees. The LF provides the legal entity, the trademark holding, the IP review process, the conference and events apparatus (LF events are themselves a substantial revenue line), and the marketing infrastructure.

This model works for projects with corporate sponsors that want to share stewardship. It works less well for individual-maintainer projects or for projects without sufficient corporate interest to fund the foundation overhead. The Apache Software Foundation, in contrast, runs on a much smaller budget and accepts projects without the same level of upfront corporate sponsorship.

The Linux Foundation has been criticised for becoming, in effect, an arms dealer to the open-source-industrial complex. The criticism is partly fair: the LF will host projects for almost any combination of corporate sponsors, with the governance charter negotiated to fit, and the financial sustainability of the foundation depends on continued enterprise membership rather than on grassroots community support. The defence is that the alternative (each major project building its own foundation from scratch) is operationally inefficient and produces inconsistent governance quality.

CNCF 2015: how Kubernetes governance changed everything

The Cloud Native Computing Foundation was established in December 2015, as a Linux Foundation sub-foundation, with Kubernetes as its founding project. Google donated Kubernetes to CNCF as the seed contribution. The other founding members included Red Hat, IBM, Intel, Cisco, VMware and others. The foundation’s mandate was the cloud-native ecosystem (originally just “applications that scale on Kubernetes”), and the membership tiers followed the now-standard LF model.

CNCF’s significance is that it shipped a project lifecycle and graduation process that became the de facto industry standard for cloud infrastructure projects. The CNCF maturity model has three stages:

• Sandbox: early-stage projects that have been accepted into CNCF but have not yet demonstrated sustained adoption or contributor diversity.
• Incubating: projects that have demonstrated meaningful adoption, contributor base, and operational maturity. Most CNCF projects spend several years in incubation.
• Graduated: projects that have met the highest bar of adoption, contributor diversity, governance maturity, security disclosure process, and license compliance. As of 2026, graduated CNCF projects include Kubernetes, Prometheus, Envoy, etcd, Helm, Vitess, Linkerd, Argo, Cilium and others.

The CNCF graduation process is deliberately rigorous and includes a Technical Oversight Committee (TOC) review, security audit (often paid for by CNCF), contributor diversity analysis, and project governance review. The process has become a marketing asset in its own right: a “CNCF graduated” badge functions as a quality signal that vendors put on their landing pages.

The other consequential CNCF contribution is the technology landscape, an opinionated map of cloud-native projects that is maintained openly on GitHub and rendered on landscape.cncf.io. The landscape has had outsized influence on which projects get attention from infrastructure buyers, and it has been imitated by other industry verticals (the LF AI landscape, the OpenSSF landscape, the LFX landscape).

CNCF has also driven the integration between the open-source-foundation model and the commercial-supplier ecosystem. Most CNCF graduated projects have one or more commercial vendors selling managed versions: Kubernetes is sold by AWS (EKS), Google (GKE), Microsoft (AKS) and many others; Prometheus is sold by Grafana, Chronosphere, and others; Envoy underpins the service mesh products of multiple vendors. The dual-track of foundation-stewarded open source plus commercial managed services has become the dominant model for cloud-native infrastructure.

The six foundations that defined the modern governance landscape, compared on what they actually do, make the institutional ecology legible:

The 2018-2023 source-available license movement (MongoDB SSPL, Elastic license, HashiCorp BSL)

The most consequential governance event of the 2018-2026 period was the source-available license movement, which reopened the license wars that the OSI thought were closed in 2003.

The proximate cause was the rise of hyperscaler-managed open-source services. AWS, in particular, launched managed versions of MongoDB (DocumentDB, 2019), Elasticsearch (Amazon Elasticsearch Service, 2015, later renamed Amazon OpenSearch Service), and Redis (Amazon ElastiCache and later MemoryDB) without contributing meaningfully back to the upstream projects and without paying license fees, because the underlying licenses (AGPL for MongoDB, Apache 2.0 for Elasticsearch, BSD for Redis) permitted it.

The companies behind these projects responded by relicensing:

• MongoDB SSPL (Server Side Public License), introduced October 2018. SSPL is a copyleft variant that requires any service that uses MongoDB to be released under SSPL, including the service’s management code, monitoring code, backup tooling, and so on. The OSI explicitly declined to certify SSPL as open source in January 2019, on the grounds that it discriminated against fields of use.
• Elastic license changes (January 2021). Elastic moved Elasticsearch and Kibana from Apache 2.0 to a dual SSPL / Elastic License (ELv2) model. ELv2 is a source-available license that explicitly prohibits offering the software as a managed service to third parties. AWS responded by forking the last Apache 2.0 commit and creating OpenSearch (April 2021), which has since become an active Apache 2.0 project under AWS stewardship.
• HashiCorp BSL adoption (August 2023). HashiCorp moved Terraform, Vault, Consul, Nomad, Boundary, Waypoint, Packer and Vagrant from MPL 2.0 to Business Source License (BSL). BSL is a time-delayed source-available license that becomes open source (Apache 2.0 or similar) after a four-year embargo. The community responded by forking Terraform into OpenTofu (initially OpenTF), which was accepted into the Linux Foundation in September 2023 and continues as an MPL 2.0 project.
• Redis license change (March 2024). Redis Inc. relicensed Redis under a dual RSALv2 / SSPL model. The Redis community forked into Valkey, which was accepted into the Linux Foundation immediately and is endorsed by AWS, Google Cloud and others.

The arguments for source-available licensing are recognisable: the upstream maintainer captures more of the value, the freeloading-hyperscaler problem gets addressed, and the commercial sustainability of the project improves. The arguments against are equally recognisable: the OSI Open Source Definition exists for a reason, source-available licenses produce uncertainty for downstream users, and the relicensings have triggered forks that arguably weaken the original projects more than the hyperscaler competition did.

The pattern is not new. Similar arguments shaped the GPL 3.0 drafting in 2005-2007, the AGPL adoption debates of the late 2000s, and the various 2010-era Commons Clause and Confluent Community License experiments. What is new about 2018-2026 is the scale of the projects involved (MongoDB, Elasticsearch, Terraform, Redis are all multi-billion-dollar businesses) and the cleanness of the resulting forks (OpenSearch, OpenTofu, Valkey have all reached production-grade maturity within two to three years of forking).

2024-2026: open-source AI models, sustainability funding, the foundation model question

The 2026 unresolved governance question is open-source AI. The vocabulary is still being settled, and several distinct positions are competing:

• The OSI’s Open Source AI Definition (released October 2024). OSAID 1.0 defines “open source AI” as requiring access to the model weights, the training code, sufficient information about training data to recreate the model substantially, and the right to use, study, modify and distribute the model. Notably, OSAID 1.0 does not require the training dataset itself to be publicly redistributable, on the grounds that this would conflict with data protection law and copyright in many jurisdictions. The definition has been controversial: critics argue it lets companies call models “open source” without releasing the data, defenders argue that requiring redistributable data would make the definition unsatisfiable in practice.
• The Linux Foundation AI & Data Foundation (founded 2018, renamed 2021), which hosts projects like ONNX, PyTorch (since 2022), and various MLOps tooling. PyTorch’s move to LF AI & Data in September 2022 was one of the most consequential foundation transfers of the era, given that PyTorch is the dominant ML framework in research and a major one in production.
• The Hugging Face model commons, which is not a foundation but functions like one. Hugging Face hosts hundreds of thousands of models under various licenses and has effectively become the package manager for the open-source AI ecosystem, with all the governance implications that come with that role.
• The various model licenses (Llama Community License, OpenRAIL, MIT for some models, Apache 2.0 for others, and a long tail of model-specific licenses). None of them are OSI-approved as open-source licenses, except for the small number using MIT or Apache 2.0 unmodified.

The deeper question is whether the foundation-stewardship model that worked for source code in 1999-2024 will work for model weights in 2026-2030. The funding scales are different: training a state-of-the-art foundation model costs tens to hundreds of millions of dollars, which is more than any open-source foundation has historically raised. The reproducibility is also different: even if all weights and code are public, retraining requires compute that most foundation stewards cannot afford.

The parallel question, which several projects covered separately on this site face directly, is what happens to open-source business models in the AI era. The WordPress 2003-2026 retrospective on the GPL-licensed WordPress ecosystem and the broader SaaS pioneers playbook both touch on it. The shorter version is that 2026 has not figured this out yet, and the governance arguments that get settled in the next three years will shape open-source AI for the next twenty.

FAQ

What is OSI?

OSI is the Open Source Initiative, a non-profit founded in February 1998 by Bruce Perens and Eric Raymond. It maintains the Open Source Definition (a ten-point criteria set adapted from the Debian Free Software Guidelines) and certifies licenses as “open source” if they meet the definition. As of 2026 it has approved roughly 80 licenses and remains the de facto referee on what the term “open source” means. The OSI also publishes annual reports, runs the State of Source survey, and increasingly takes positions on policy issues such as open-source AI and software supply chain regulation.

What is the difference between open source and free software?

“Free software” is the term promoted by the Free Software Foundation (founded by Richard Stallman in 1985) and emphasises the user’s freedom to run, study, modify and redistribute the software. “Open source” is the term promoted by the Open Source Initiative (founded 1998) and emphasises the practical and business benefits of public source code. The license criteria overlap substantially: most FSF-approved free-software licenses are also OSI-approved open-source licenses, and vice versa. The disagreement is largely philosophical and partly political. In practice, projects that style themselves as “free software” tend to favour copyleft licenses (GPL family), while projects that style themselves as “open source” are more likely to use permissive licenses (MIT, Apache 2.0, BSD).

What is CNCF?

CNCF is the Cloud Native Computing Foundation, established in December 2015 as a sub-foundation of the Linux Foundation, with Kubernetes (donated by Google) as its founding project. As of 2026 it hosts roughly 200 projects across graduated, incubating and sandbox stages, and its annual KubeCon conference is the largest open-source infrastructure event in the industry. CNCF runs the most rigorous project graduation process of any major foundation, with security audits, contributor diversity analysis, and governance review as standard requirements.

Are source-available licenses open source?

By the Open Source Initiative’s definition, no. The OSI’s Open Source Definition requires, among other things, that the license not discriminate against fields of use, which most source-available licenses (SSPL, BSL, ELv2, Confluent Community License) do, typically by restricting the right to offer the software as a managed service. The software is publicly readable, modifiable and forkable, but the OSI does not certify these licenses as open source. The naming is genuinely contested in the industry: the companies adopting source-available licenses argue that the spirit of openness is preserved, while the OSI argues that fields-of-use restrictions are precisely what the Open Source Definition was created to prevent. The dispute remains unresolved in 2026 and has produced multiple high-profile forks (OpenSearch, OpenTofu, Valkey) where the open-source community chose to preserve OSI-aligned licensing rather than follow the upstream relicensing.