Open Source Software: Licenses, Economics, and Why It Powers the Internet

In 2005, a software engineer at a financial firm asked the Linux Foundation a question: "If we run Linux on millions of servers and contribute improvements back, do we owe anyone royalties?" The answer was no. The Linux kernel, released in 1991 under the GPL license, is owned by no one and maintained by thousands of contributors worldwide. The engineer's firm paid nothing for licensing. Yet Linux had cost billions to develop through collective labor. The economic paradox lies at the heart of open source: software that nobody owns, everybody uses, and nobody pays for licensing generates more economic value than proprietary alternatives. The mechanism is not altruism but legal license frameworks that permit modification, redistribution, and private use without vendor control. Understanding these frameworks explains why 96 percent of Fortune 500 companies run on open source infrastructure, why projects sustain without traditional venture funding, and why enterprises choose the "free as in freedom" model despite having capital to purchase proprietary alternatives.

What Is Open Source: Definition and Core Principles

Open source software — software whose source code is publicly accessible under a license that permits modification, redistribution, and private use without requiring payment to or permission from a central vendor. The source code is the human-readable instructions that programmers write; compiled or binary software is the machine-executable version that end users run. Open source publishes the source, allowing anyone to inspect, modify, and redistribute it.

The legal framework is the license. A license is not a contract but a copyright statement that grants specific permissions. Without a license, all rights are reserved by the copyright holder and modification is illegal. An open source license grants rights: the right to inspect source code, modify it, and redistribute it under defined conditions.

Three core principles distinguish open source from merely "publicly available" code:

Transparency. Source code is public. Anyone can read it, audit it, or verify claims about what it does. This enables the "many eyeballs" model: security vulnerabilities are found faster because more people review the code.

Modifiability. The license permits creation of derivative works. If you find a bug or need a feature, you can fix or add it yourself rather than waiting for a vendor's permission or next release.

Redistribution. You can share your modified version with others under the same license terms. This enables community-driven development and prevents one person or company from monopolizing improvements.

These three principles are the definition of open source according to the Open Source Initiative (OSI), a nonprofit established in 1998 to formalize open source licensing. The OSI maintains a list of approved licenses (150+ as of 2026) that meet these criteria. Not every "free" or "publicly available" code is open source: for example, source-available software published under restrictive terms (such as the "Elastic License," which forbids providing the software as a service) does not meet the OSI definition.

Source: Maurer, S.M. and Scotchmer, S. (2006), "Open Source Software: The New Intellectual Property Paradigm," NBER Working Paper 12148 — economic analysis of open source licensing and intellectual property frameworks.

Source: Open Source Initiative (2024), The Open Source Definition — the authoritative definition of open source software and approval criteria for OSI-compliant licenses.

The Three Dominant License Models

Open source licenses cluster into three families: copyleft, permissive, and proprietary-adjacent. These families differ in how they handle derivative works and redistribution.

Copyleft Licenses: GPL and AGPL

Copyleft — a class of open source licenses that require any derivative work or modified version to be distributed under the same license terms. The term is a play on "copyright"; copyleft uses copyright law to enforce openness rather than restrict it.

The GNU General Public License (GPL), first released in 1989, is the most widely used copyleft license. The GPL states: if you distribute modified source code or a compiled executable of GPL software, you must distribute the source code under the same GPL license. This is called "viral" licensing because the open source requirement propagates through derivative works.

The GPL has three main versions. GPLv2 (1991) is used by Linux and covers roughly 60 percent of open source projects. GPLv3 (2007) added provisions protecting against software patents and digital restrictions. AGPL (Affero General Public License, 2007) extends the GPL to software-as-a-service (SaaS): if you modify AGPL software and run it on a server without distributing it, you must still publish your modifications. This closes the "SaaS loophole" where a company could modify GPL software, run it on a server, and avoid publishing the source. The requirement to publish was not triggered because the software was not distributed to users.

GPL's trade-off: Copyleft protects users by guaranteeing that improvements remain open. But it creates a barrier for companies that want to build proprietary software on top. For example, Apple cannot use GPL code in macOS without opening the entire operating system source code. This constraint explains why Apple uses permissive licenses (BSD, MIT) for its open source projects.

Source: Free Software Foundation (2007), GNU General Public License Version 3 — the authoritative GPL terms and the rationale for the copyleft model.

Permissive Licenses: MIT and Apache

Permissive licenses grant the right to modify and redistribute without requiring derivative works to be open source. The software can be incorporated into closed-source proprietary software.

The MIT License (1988) is the shortest and simplest. It grants permission to do anything with the software, provided you include the license notice and disclaim liability. The MIT-licensed software can be used in proprietary software, commercial products, or closed-source services without restriction. The only obligation is attribution.

The Apache License 2.0 (2004) is more formal and longer (170 lines versus MIT's 20). It grants similar rights but adds explicit provisions for patents: if you use Apache-licensed software and it infringes a patent, you are granted permission to use that patent. This protects downstream users and companies from patent disputes. Apache also provides explicit indemnification: the licensor disclaims liability for patent infringement, making it safer for enterprises to use.

Permissive licenses' trade-off: They enable widespread adoption because there is no "viral" requirement. Companies use permissive-licensed software in proprietary products (e.g., Google uses Apache Lucene in proprietary search products). But permissive licenses do not guarantee that improvements benefit the community. If Company A forks permissive-licensed software, modifies it, and builds a proprietary product, Company B gets no access to those improvements. This creates "tragedy of the commons" scenarios where the original project may be abandoned while proprietary forks thrive.

License	Type	Patent Protection	Copyleft	Commercial Use	Common Users
GPLv2	Copyleft	No	Yes (strict)	Allowed	Linux, Python
GPLv3	Copyleft	Yes	Yes (strict)	Allowed	GNU tools
AGPL	Copyleft	Yes	Yes (SaaS included)	Allowed	Server software
MIT	Permissive	No	No	Allowed	React, Node.js, Rails
Apache 2.0	Permissive	Yes	No	Allowed	Hadoop, Kubernetes, Android
BSD	Permissive	No	No	Allowed	macOS, Netflix

Source: GitHub (2024), GitHub License Report — analysis of 30 million repositories showing that MIT (44%), Apache 2.0 (11%), and GPL (10%) account for 65% of licensed open source projects.

How Open Source Projects Sustain Themselves

The central question facing any open source project is survival: how does a project maintain quality and momentum when developers are unpaid? Four models sustain open source: corporate sponsorship, foundations, dual licensing, and developer communities.

Model 1: Corporate Sponsorship and Dedicated Teams

Large technology companies (Google, Amazon, Microsoft, Meta, Apple) contribute developers to open source projects full-time, paid by the company, not the project. Google sponsors the Kubernetes project (orchestration software for containerized applications) with a dedicated team of 20+ engineers. Amazon contributes to OpenSearch (a fork of Elasticsearch, used in distributed search). Microsoft maintains VS Code and contributes heavily to the Linux kernel.

The company's motivation is strategic, not philanthropic: using open source infrastructure reduces the cost of building proprietary products on top. For example, Google uses Linux, Apache, Kubernetes, and Python in its cloud infrastructure and search products. By contributing to these projects, Google ensures they align with its needs and remains high-quality. The company invests because it captures more value from its proprietary products than it contributes to the open source projects.

This model creates a risk: if a company is the dominant contributor, project governance can become opaque and decisions may favor the company's interests over the community. For example, Elasticsearch changed its license from AGPL to the "Elastic License," which restricts cloud-hosting use, after AWS forked the project (OpenSearch) and offered it as a managed service. The license change was Elastic's attempt to prevent AWS from monetizing Elasticsearch without Elastic capturing revenue.

Model 2: Foundations

A foundation is a nonprofit organization that owns and governs an open source project, receiving funding from corporate sponsors, grants, and donations. The foundation is independent of any single company, providing governance separation.

The Linux Foundation (founded 2000) manages Linux, the Kubernetes project, and 200+ other projects. It receives funding from Intel, IBM, Google, Microsoft, Amazon, and others. Linux Foundation members pay annual membership fees (ranging from $1,000 to $500,000 depending on company size) that fund development and community management.

The Mozilla Foundation (created 2003) governs Firefox and the Mozilla platform. It receives 97 percent of revenue from Google, which pays for Google as the default search engine in Firefox. This creates a conflict of interest: Mozilla's independence is constrained because it is financially dependent on Google. In 2023, Mozilla laid off 67 percent of its staff after revenue declined, illustrating the fragility of foundation-dependent models.

The Python Software Foundation (founded 2001) governs Python development and receives donations from companies (Microsoft, Google, Meta) and the community. Python's governance is transparent: language decisions are made by the community via Python Enhancement Proposals (PEPs) reviewed by elected "steering council" members.

Foundations provide stability and independence but can become bureaucratic. Projects in foundations move slower because decisions require consensus among diverse stakeholders (companies, developers, users). Smaller, faster-moving projects often stay independent and rely on volunteer effort or corporate sponsorship.

Source: Tirole, J. and Lerner, J. (2005), "The Economics of Technology Sharing: Open Source and Beyond," NBER Working Paper 11005 — economic analysis of open source foundations, governance structures, and sustainability models.

Source: Linux Foundation (2024), Annual Report — funding structure and governance model for 200+ open source projects managed by the Linux Foundation.

Model 3: Dual Licensing

Dual licensing means the project is available under two licenses: an open source license (e.g., GPL) for the community, and a proprietary license for companies.

For example, MySQL (a database) is available under the GPL and a proprietary license. Individual users and small businesses use the GPL version (free). Enterprises that want to use MySQL in closed-source products pay a licensing fee for the proprietary version. MySQL's creators (MySQL AB) were acquired by Sun Microsystems in 2008 for $1 billion, in part because the dual-licensing model proved profitable.

MongoDB (a database) uses a similar strategy: the community version is open source, but the proprietary "MongoDB Enterprise" version includes additional features and support. The company (MongoDB Inc., founded 2010) went public in 2019 and has a market capitalization exceeding $30 billion.

Dual licensing is controversial in open source communities because it can feel exploitative: the company builds proprietary features on top of community contributions, and companies must pay to avoid the GPL restriction. But dual licensing is one of the few open source business models that generates significant revenue without relying entirely on venture funding or corporate sponsorship.

Model 4: Developer Community and Volunteer Effort

Many successful open source projects rely primarily on volunteer developers who contribute part-time. For example, Blender (3D graphics software), used by studios like Pixar and Disney, is maintained largely by volunteers and supported by the Blender Foundation, a nonprofit funded by donations and sponsorships.

The vulnerability of volunteer-driven models is burnout: if the primary maintainer (often a single person or small team) loses motivation or time, the project can stall. In 2021, the maintainer of "event-stream," a popular JavaScript library used by hundreds of thousands of projects, abandoned the project after burnout. A malicious actor took over the package and injected cryptocurrency-stealing code. This incident led to discussions about funding small-package maintainers.

To address this, the GitHub Sponsors program and Open Collective platform allow individual developers to receive donations. Some developers earn $1,000 to $10,000 per month through Sponsors, making open source their full-time work.

The Economics: Why Open Source Powers Trillion-Dollar Industries

The economic case for open source is paradoxical: free software powers proprietary products worth trillions of dollars. Three mechanisms explain this:

Cost reduction. Building infrastructure from scratch is expensive. Linux development, if funded privately, would cost billions. Companies use open source infrastructure (Linux, Apache, Python, Kubernetes) instead of building proprietary alternatives. This transfers development cost to the open source community while the company invests in proprietary applications on top. The company captures value while paying a small fraction of the total development cost.

Speed to market. Using existing open source libraries and frameworks allows companies to build products faster. A company building a web service uses Apache, Python, and Kubernetes rather than developing in-house alternatives. This reduces time-to-market and risk of building the wrong thing. The company captures value through rapid iteration.

Ecosystem effects. Open source ecosystems (like Python's data science packages, Node.js modules, or Kubernetes extensions) attract users and developers. A large ecosystem makes the software more valuable because more libraries and tools are available. Companies that contribute to these ecosystems benefit from their growth. For example, Google benefits from Python's popularity in machine learning (TensorFlow, scikit-learn); this popularity drives adoption of Google's cloud machine learning services.

Company	Open Source Contribution	Proprietary Product	Captured Value
Google	Linux, Python, Kubernetes, Angular	Google Cloud, Search, Maps	$280B market cap (2026)
Amazon	Linux (AWS), Elasticsearch fork (OpenSearch)	AWS cloud services	$2.5T market cap (2026)
Microsoft	Linux, VS Code, Kubernetes	Azure cloud, Office 365	$3.4T market cap (2026)
Apple	BSD, LLVM, WebKit	macOS, iOS, App Store	$3.6T market cap (2026)
Meta	React, PyTorch, LLVM	Facebook, Instagram, WhatsApp	$1.3T market cap (2026)

Read next: How Blockchain Works Explained Simply — understand decentralized ledgers and consensus mechanisms. Semiconductor Chips: How They Work — the hardware foundation underlying open source deployment. History of Electricity: Faraday, Tesla, Edison — how infrastructure innovations enable technological ecosystems.

Why Enterprises Choose Open Source

Despite having capital to purchase proprietary software, enterprises choose open source for strategic reasons:

Avoiding lock-in. Open source prevents vendor lock-in. If you use proprietary software and the vendor goes bankrupt or raises prices, you are trapped. Open source allows you to maintain or fork the project independently.

Security and transparency. Open source enables code auditing. For financial firms and government agencies, transparency is critical. You can hire an auditor to review the code and verify there are no backdoors or vulnerabilities.

Developer preference. Developers prefer working with open source tools because they can fix bugs and add features without waiting for a vendor. This makes open source easier to recruit for.

Cost. Enterprise open source support contracts (e.g., Red Hat support for Linux, Canonical support for Ubuntu) are cheaper than proprietary software licensing because multiple companies can sell support for the same code.

These factors explain why Linux dominates enterprise servers (96.3 percent market share, 2026) despite Microsoft investing billions in Windows Server. Linux is free, transparent, and modifiable. Windows Server is closed and expensive.

Source: Statista (2026), Server Operating System Market Share — Linux holds 96.3% of server market share (including cloud); Windows Server <2%.

Famous Open Source Projects and Their Economics

Project	License	Founding	Dominant Use	Funding Model	Notable Stats
Linux	GPLv2	1991	OS kernel	Linux Foundation	30M lines of code
Apache	Apache 2.0	1995	Web server	Apache Foundation	50% of websites
Python	PSF	1989	Programming language	PSF + corporate sponsorship	17M developers
Kubernetes	Apache 2.0	2014	Container orchestration	Cloud Native Computing Foundation	$220B+ container market
React	MIT	2011	JavaScript UI library	Meta sponsorship	14M+ weekly npm downloads
Node.js	MIT	2009	JavaScript runtime	OpenJS Foundation	50M+ weekly downloads
PostgreSQL	PostgreSQL license (permissive)	1989	Relational database	Community + corporate sponsorship (EDB, AWS, Google)	100K+ users
Docker	Apache 2.0	2013	Container platform	Docker Inc. (venture capital)	13M+ images

The Future: Open Source Challenges and Trends

Open source faces emerging challenges:

Sustainability. Small-package maintainers are often unpaid. The "event-stream" incident and similar security breaches have highlighted that many critical infrastructure components depend on individuals who receive no compensation. Funding models for small-package maintainers remain underdeveloped.

License fragmentation. With 150+ OSI-approved licenses, enterprises struggle to manage license compliance. A codebase with dependencies using incompatible licenses (e.g., GPL and Apache) can create legal ambiguity.

Security. Open source's transparency enables both security auditing and exploitation. Malicious contributors can inject vulnerabilities. In 2024, backdoors in XZ Utils (used in Linux distributions) and Log4Shell (a critical Java logging library) demonstrated that open source projects can be compromised.

Concentration of control. Despite the open source ethos, governance is increasingly concentrated in large companies. GitHub (Microsoft), GitLab (private), and Gitea are the platforms where most open source is hosted. Dependence on these platforms creates centralization risk.

The field is moving toward formal security auditing, funding mechanisms for maintainers, and stronger governance structures. The National Science Foundation and European Union are funding open source infrastructure initiatives. The future likely involves more professional, well-funded projects and declining volunteer-dependent ones.

Source: Feller, J. et al. (2008), "Perspectives on Free and Open Source Software," MIT Press — comprehensive analysis of open source community dynamics, governance, and sustainability challenges.

Frequently Asked Questions

Q: Is open source always free as in price?
A: No. Open source is "free as in freedom" (you can modify and redistribute), but licenses do not constrain price. A vendor can sell open source software (e.g., Red Hat's support contracts for Linux) and charge money. The freedom is legal rights, not cost.

Q: Can I use open source software in a proprietary product?
A: Depends on the license. MIT and Apache licenses allow proprietary derivatives. GPL requires that derivative works be open source. Check the license before using.

Q: Who owns open source software if there's no company?
A: The original copyright holder (usually the creator or first contributor) owns the copyright. The license grants permission to others. If no license is specified, you cannot legally modify or redistribute.

Q: Can a company relicense open source software?
A: Only if they hold the copyright. For example, if you contributed to a GPL project without a copyright assignment agreement, you own the copyright to your contributions and the project cannot unilaterally change the license to proprietary (though they can re-license new versions).

Q: Why would a company contribute to open source if competitors can use it?
A: Because the company benefits more from the open source ecosystem than it loses to competitors. Google benefits from Python's popularity even though competitors use it, because the ecosystem makes Google's cloud services more valuable.

Q: Is open source used by large enterprises?
A: Yes, universally. 96% of Fortune 500 companies use open source. Linux dominates servers. Microsoft Azure uses Linux VMs more than Windows. Financial institutions run on open source databases (PostgreSQL, MySQL).

Conclusion

Open source is not a quirk of tech culture but the dominant software model for infrastructure. The legal framework of open source licenses (GPL's copyleft, MIT and Apache's permissive terms) enables developers to contribute without vendor control and enterprises to use software without lock-in. Projects sustain through corporate sponsorship (Google, Amazon, Microsoft), foundations (Linux Foundation, Mozilla), dual licensing (MySQL, MongoDB), and volunteer communities. The economics are clear: companies invest billions in proprietary applications built on top of open source infrastructure worth trillions. The paradox resolves when you recognize that free software does not mean free labor—it means free legal restrictions. The cost is paid through developer salaries, infrastructure, and time. The benefit is speed to market, ecosystem effects, and avoidance of lock-in. Open source is not altruism; it is a rational economic choice that has reshaped how the world builds software.