Open source software is software whose source code is published under a license that lets anyone use, study, modify and redistribute it. Nearly every company already runs on it. The license decides what you owe: permissive licenses ask for little more than attribution, while copyleft licenses can require you to publish your changes. The real business risks are license compliance, unmaintained code and vulnerable dependencies, not the fact that the code is public.
If your company has a website, a smartphone fleet, a cloud account or any custom software, it depends on open source. Audits of commercial codebases routinely find that most of the code inside a typical business application came from open-source components rather than from the vendor. Open source is less a technology choice than a supply chain every organization already has, managed or not.
This guide explains what the term means, how the license families differ, why some vendors have abandoned open licenses, what open source really costs, and how to write a simple policy that avoids legal and security surprises.
- “Open source” is a legal status defined by the license, not simply code you can see on the internet.
- Permissive licenses (MIT, Apache 2.0, BSD) are easy to use in commercial products; copyleft licenses (GPL, AGPL, LGPL) attach sharing obligations, usually triggered by distribution.
- Source-available licenses such as BSL and SSPL look similar but restrict commercial use and are not open source.
- A software bill of materials (SBOM) and a short approval policy are the two most effective controls a business can put in place.
What is open source software?
Every program starts as source code, the human-readable instructions programmers write in languages such as Python, Java or C. With proprietary software you receive only the runnable product and a license that forbids inspecting or changing it. With open source software, the source code is published and the license explicitly grants you the right to read, change and share it. If the distinction between programs and the machines they run on is new to you, our guide to hardware vs software covers the basics.
The term has a precise meaning. The Open Source Initiative (OSI), a non-profit founded in 1998, maintains the Open Source Definition, ten criteria a license must meet. The key ones:
- Free redistribution: anyone may give away or sell the software without royalties.
- Source code and derived works: the code must be obtainable, and you may modify it and distribute your changes.
- No discrimination: the license cannot say “not for commercial use” or exclude particular people or industries.
OSI publishes a list of approved licenses. If a vendor calls a product “open source” but its license bans competitors from using it, the product fails the definition, however public its code.
Does “free software” mean free of charge?
Not necessarily. The older term free software comes from the Free Software Foundation, founded by Richard Stallman in 1985, whose slogan is “free as in free speech, not as in free beer.” Its four freedoms are to run, study, change and redistribute the program. Price is not part of the definition: selling open source software is permitted, and Red Hat built a large business doing exactly that.
“Open source” was coined in 1998 as a business-friendly label for the same idea, and almost every license accepted by one group is accepted by the other, hence the neutral acronym FOSS. Do not confuse either with freeware, which is proprietary software given away at no cost: you cannot see the code, and the owner can start charging tomorrow.
Which famous products are open source?
Open source is not a niche for hobbyists. Much of the modern internet and a large share of enterprise IT runs on it:
- Linux, the kernel started by Linus Torvalds in 1991 (GPLv2). It runs most web servers and cloud virtual machines, all of the top supercomputers and countless embedded devices. See operating systems explained for how a kernel fits into a full OS.
- Android, whose core is the Android Open Source Project (AOSP), mostly Apache 2.0. Google’s apps and Play services on top are proprietary, which is how Google keeps commercial control of an open platform.
- Apache HTTP Server, a pioneering web server and the founding project of the Apache Software Foundation.
- Kubernetes, released by Google in 2014 and now governed by the Cloud Native Computing Foundation (CNCF), the standard way to run containers; see virtualization and containers.
- PostgreSQL, a community-developed relational database under its own permissive license, underneath many managed cloud databases; see databases explained.
- WordPress, the GPL-licensed content management system behind a very large share of websites.
- Firefox, released under the Mozilla Public License 2.0, a file-level “weak copyleft” license.
- Python, one of the most popular programming languages, under the permissive PSF License.
How are open-source projects governed and funded?
“Open” describes the license, not the decision-making. Who controls the roadmap affects how safe it is to depend on a project for ten years.
Foundation-governed projects
Neutral non-profits such as the Linux Foundation (home of the CNCF), the Apache Software Foundation and the Python Software Foundation hold trademarks and infrastructure, funded by member dues. They make it hard for any one company to take a project away from the community, so buyers read foundation governance as a sign of stability.
Company-led projects
A single vendor employs most developers and sets direction, as with MongoDB, Elasticsearch, Redis and Terraform. These move fast and offer professional support, but the company can change the license, as several have.
Community and individual maintainers
Many widely used libraries are maintained by a few volunteers in their spare time, with no contract and no obligation to fix a bug by Monday. That is where risk concentrates. Funding comes from donations, GitHub Sponsors, corporate grants and industry programs such as the Open Source Security Foundation (OpenSSF). On major projects, much of the work is done by engineers paid by companies that depend on them, because improving a shared base is cheaper than maintaining a private one.
What are permissive and copyleft licenses?
Most licenses fall into two families on a spectrum from “do almost anything” to “you may not even see the code.”
Permissive licenses
The MIT, BSD and Apache 2.0 licenses let you use the code in anything, including closed commercial products, provided you keep the copyright notice and license text. You need not publish your changes. Apache 2.0 adds an explicit patent license from contributors, which ends for anyone who sues over patents in the software, one reason large companies prefer it.
Copyleft licenses
Copyleft uses copyright law to keep software open: if you distribute a modified version or a work based on the code, you must release it under the same license with source. The GPL is the classic example; GPLv3 (2007) added patent terms. The AGPLv3 closes the “SaaS loophole”: if users interact with modified AGPL software over a network, you must offer them the source. The LGPL is a weaker form for libraries: proprietary apps may link to it, but changes to the library itself must be shared.
| License | Commercial use? | Must share changes? | Explicit patent grant? | Typical use |
|---|---|---|---|---|
| MIT | Yes | No; keep copyright notice | No | Small libraries, JavaScript packages, developer tools |
| Apache 2.0 | Yes | No; keep notices and mark modified files | Yes, with patent-retaliation clause | Enterprise and cloud projects (Kubernetes, Android) |
| GPLv3 | Yes | Yes, for the whole derived work, when you distribute it | Yes | Applications and tools meant to stay open (GNU utilities) |
| AGPLv3 | Yes | Yes, including when users access it over a network | Yes | Server software and web apps (e.g. Nextcloud, Mastodon) |
| LGPL | Yes | Only changes to the library itself, when distributed | LGPLv3 yes; LGPLv2.1 no explicit grant | Shared libraries linked by other programs (e.g. glibc) |
What the obligations mean for a company
The key idea for non-lawyers is the trigger. GPL obligations are generally triggered by distribution: shipping software to customers or embedding it in a device. Running GPL software on your own servers usually creates no duty to publish. The AGPL moves the trigger to network use by outsiders, which is why many SaaS companies ban it. Obligations fall into three buckets:
- Attribution: keep copyright notices and license texts, usually in an “open source notices” file.
- Source disclosure: for distributed copyleft code, provide the source, including your modifications.
- License compatibility: some licenses cannot be combined, which can leave you with a product you have no clean right to ship.
What worries acquirers is a product built on copyleft code its owners assumed was permissive. Fixing that later can mean rewriting components or publishing code regarded as a trade secret.
What are source-available licenses and why are vendors relicensing?
Since roughly 2018, several company-led projects have moved to source-available licenses. The code stays public, but the license restricts certain uses, most often offering the software as a competing cloud service:
- Business Source License (BSL/BUSL): vendor-defined limits on production use; each release converts to an open-source license after a “change date,” typically a few years later.
- Server Side Public License (SSPL): anyone offering the software as a service must release their entire service stack. OSI does not accept it.
Vendors argued that cloud providers were selling hosted versions of their products without contributing enough back. The community response has repeatedly been to fork the last open-source version into a foundation-governed project. OpenTofu (from Terraform) and Valkey (from Redis) are two high-profile examples, and some vendors have later added an OSI-approved license back as an option.
For a buyer, the lesson is that a license can change on the next version. Ordinary internal use is usually still permitted, but if you resell, host or embed the software, decide whether to stay, move to a fork or switch products.
Is open source cheaper than proprietary software?
The license is usually cheaper, often zero, but fees are one line of total cost of ownership (TCO). A fair three-to-five-year comparison includes:
- Staff time: installing, upgrading and patching move from the vendor to your team.
- Support: a paid subscription or in-house expertise.
- Infrastructure: a database cluster needs the same hardware whether the software is free or not; see what is a server.
- Integration and migration: connecting systems, training users and eventually moving off.
- Compliance and security tooling: scanners and review time.
Open source tends to win when skills are easy to hire, when you run at scale (where per-user or per-core fees would balloon) and when avoiding lock-in matters. Proprietary or managed products win when your team is small and the software is not core. A middle path is a managed cloud service; see cloud computing explained.
How do companies make money from open source?
Commercial open source is a mature business model with several common forms:
- Support subscriptions: customers pay for certified builds, patches and support; Red Hat Enterprise Linux is the textbook case.
- Open core: the core is open, while enterprise features such as single sign-on or audit logs are proprietary.
- Managed cloud services: the vendor runs the product for you, billed by usage.
- Dual licensing: free under copyleft, or under a paid commercial license for those avoiding copyleft terms.
With open core, check whether compliance features such as role-based access control sit in the paid tier; with subscriptions, check how long each version is supported.
What are the security and supply-chain risks of open source?
Public code is not inherently less secure. The problem is that most organizations do not know which open-source components and versions they run, or who maintains them.
Dependency vulnerabilities
Applications pull in libraries that pull in further libraries (transitive dependencies), often hundreds per application. The best-known illustration is Log4Shell (CVE-2021-44228), disclosed in December 2021 in Apache Log4j 2, a Java logging library embedded in a huge range of software. It allowed remote code execution, and many organizations spent weeks just finding where Log4j lived before they could patch.
Supply-chain attacks and abandoned projects
Attackers publish malicious look-alike packages, hijack maintainer accounts or slowly gain a project’s trust to insert a backdoor. And an abandoned library will never get a fix for its next flaw.
Software bills of materials
A software bill of materials (SBOM) lists every component in a product, with versions and licenses, in formats such as SPDX or CycloneDX. Governments and large buyers increasingly require them, and the EU’s Cyber Resilience Act is phasing in vulnerability-handling duties for digital products. An SBOM turns “are we affected?” into a search rather than a scramble; see also what is cybersecurity.
What does this mean for your business?
Managing open source well takes visibility, a few clear rules and an owner, not a legal department.
How to set an open-source policy
- Define license categories. For example: permissive approved by default; weak copyleft with conditions; GPL reviewed if distributed; AGPL and source-available need explicit approval.
- Require an inventory. Generate an SBOM for every product and major system. Most code platforms offer dependency scanning; our Git hosting platforms comparison covers which ones include it.
- Automate scanning. Software composition analysis in the build pipeline flags vulnerabilities and license conflicts before code ships.
- Assess project health. Check release activity, active maintainers, governance and commercial support before adopting a critical component.
- Set a patch window. Agree how fast critical dependency flaws must be fixed, e.g. days for internet-facing systems.
- Decide on contributions. State who approves outside contributions and releasing company code.
Cost drivers to watch
The biggest costs are upgrade engineering, support subscriptions and security tooling. Track open-source components alongside commercial software; an IT asset management platform can hold both. Outdated packages on endpoints and servers should be covered by your endpoint security and patching tools.
Questions to ask vendors and IT
- Can you provide an SBOM for this product, and how often is it updated?
- Which copyleft or source-available components does it contain, and how do you meet their obligations?
- If the upstream license changes, what happens to our contract?
Frequently Asked Questions
Can a company use open source software commercially?
Yes. Every OSI-approved license allows commercial use, and the definition forbids licenses that discriminate against business use. What differs is the conditions. Permissive licenses mainly require attribution, while copyleft licenses can require you to publish source code when you distribute software built on them. Always check the specific license of each component.
Do I have to publish my code if I use GPL software internally?
Generally no. GPL obligations are triggered when you distribute the software or a derived work to others, so running modified GPL software only inside your company usually creates no duty to publish. The AGPL is different: if outside users interact with your modified version over a network, you must offer them the source code.
Is open source software less secure than proprietary software?
Not inherently. Public code can be reviewed by many people, and popular projects often patch quickly. The larger risk is organizational: companies frequently do not know which components and versions they run, so they cannot patch them. An SBOM, automated dependency scanning and a defined patch window address most of that risk.
What is the difference between open source and source-available?
Both publish the code, but only open-source licenses meet the OSI definition, which guarantees rights to use, modify and redistribute for any purpose. Source-available licenses such as BSL or SSPL restrict certain uses, typically offering the software as a competing hosted service. Normal internal use is often allowed, but read the terms before reselling or hosting it.
What is an SBOM and why do customers ask for one?
A software bill of materials is a machine-readable list of every component in a product, with versions and licenses, often in SPDX or CycloneDX format. Customers and regulators ask for it so they can check license compliance and quickly find out whether a newly disclosed vulnerability, such as Log4Shell, affects the software they bought.
Discover more from Kurums | Business Intelligence
Subscribe to get the latest posts sent to your email.
